OpenSSH and pam_radius_auth.so - SSH

This is a discussion on OpenSSH and pam_radius_auth.so - SSH ; I am running RedHat EL3 with OpenSSH OpenSSH_3.6.1p2. I have configured the /etc/pam.d/sshd file as follows #%PAM-1.0 auth required pam_radius_auth.so debug account required pam_radius_auth.so session required pam_radius_auth.so What I am *expecting* is to be prompted for a password, and then ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: OpenSSH and pam_radius_auth.so

  1. OpenSSH and pam_radius_auth.so

    I am running RedHat EL3 with OpenSSH OpenSSH_3.6.1p2.

    I have configured the /etc/pam.d/sshd file as follows

    #%PAM-1.0
    auth required pam_radius_auth.so debug
    account required pam_radius_auth.so
    session required pam_radius_auth.so

    What I am *expecting* is to be prompted for a password, and then
    prompted for some second-factor authentication information, and then
    logged in (assuming all authentication information is valid). I used
    the same pam configuration for /etc/pam.d/sudo, and it worked exactly
    as expected.

    But for OpenSSH, this is not what is happening. When I try to ssh into
    the computer, I get

    # ssh tucker@10.4.148.25
    tucker@10.4.148.25's password:
    Permission denied, please try again.
    tucker@10.4.148.25's password:

    If I look at the /var/log/security file, I find

    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got user name
    tucker
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Sending RADIUS
    request code 1
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: DEBUG:
    getservbyname(radius, udp) returned 3911708.
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got RADIUS
    response code 11
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got response to
    challenge code 11
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got response to
    challenge code 11
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: Got response to
    challenge code 3
    Jan 10 11:30:36 dpiems sshd[23804]: pam_radius_auth: authentication
    failed
    Jan 10 11:30:36 dpiems sshd[23804]: Failed password for tucker from
    10.4.148.25 port 35617 ssh

    By looking at the logs on my RADIUS server, I can see that the password
    is being successfully authenticated, and then a second-factor challenge
    is being sent. It appears as if sshd is (1) not displaying the second
    factor authentication to the user, and (2) responding to the challenge
    with some other piece of information. This of course fails, and the
    RADIUS server tries again 2 more times before giving up.

    I then discovered the PAMAuthenticationViaKbdInt entry in the
    sshd_config file, and set it to yes (it was commented out previously)
    and restarted the sshd service. This made no difference. I have pasted
    the content of the sshd_config file below, just in case this is useful
    information.

    # $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $

    # This is the sshd server system-wide configuration file. See #
    sshd_config(5) for more information.

    # This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

    # The strategy used for options in the default sshd_config shipped with
    # OpenSSH is to specify options with their default value where #
    possible, but leave them commented. Uncommented options change a #
    default value.

    #Port 22
    Protocol 2
    #ListenAddress 0.0.0.0
    #ListenAddress ::

    # HostKey for protocol version 1
    #HostKey /etc/ssh/ssh_host_key
    # HostKeys for protocol version 2
    #HostKey /etc/ssh/ssh_host_rsa_key
    #HostKey /etc/ssh/ssh_host_dsa_key

    # Lifetime and size of ephemeral version 1 server key
    #KeyRegenerationInterval 3600 #ServerKeyBits 768

    # Logging
    #obsoletes QuietMode and FascistLogging
    #SyslogFacility AUTH
    SyslogFacility AUTHPRIV
    #LogLevel INFO

    # Authentication:

    #LoginGraceTime 120
    #PermitRootLogin yes
    #StrictModes yes

    #RSAAuthentication yes
    #PubkeyAuthentication yes
    #AuthorizedKeysFile .ssh/authorized_keys

    # rhosts authentication should not be used #RhostsAuthentication no #
    Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes #
    For this to work you will also need host keys in
    /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for
    protocol version 2 #HostbasedAuthentication no # Change to yes if you
    don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and
    HostbasedAuthentication #IgnoreUserKnownHosts no

    # To disable tunneled clear text passwords, change to no here!
    #PasswordAuthentication no PermitEmptyPasswords no

    # Change to no to disable s/key passwords
    #ChallengeResponseAuthentication yes

    # Kerberos options
    #KerberosAuthentication no
    #KerberosOrLocalPasswd yes
    #KerberosTicketCleanup yes

    #AFSTokenPassing no

    # Kerberos TGT Passing only works with the AFS kaserver
    #KerberosTgtPassing no

    # Set this to 'yes' to enable PAM keyboard-interactive authentication #
    Warning: enabling this may bypass the setting of
    'PasswordAuthentication' PAMAuthenticationViaKbdInt yes

    #X11Forwarding no
    X11Forwarding yes
    #X11DisplayOffset 10
    #X11UseLocalhost yes
    #PrintMotd yes
    #PrintLastLog yes
    #KeepAlive yes
    #UseLogin no
    #UsePrivilegeSeparation yes
    #PermitUserEnvironment no
    #Compression yes

    #MaxStartups 10
    # no default banner path
    Banner /etc/ssh/sshd_banner
    #VerifyReverseMapping no
    #ShowPatchLevel no
    # override default of no subsystems
    Subsystem sftp /usr/libexec/openssh/sftp-server


  2. Re: OpenSSH and pam_radius_auth.so

    In article <1168545415.674920.181610@i39g2000hsf.googlegroups. com> "Dave
    Isaacs" writes:
    >I am running RedHat EL3 with OpenSSH OpenSSH_3.6.1p2.


    That is a pretty ancient version, but it might work...

    >But for OpenSSH, this is not what is happening. When I try to ssh into
    >the computer, I get
    >
    > # ssh tucker@10.4.148.25
    > tucker@10.4.148.25's password:
    > Permission denied, please try again.
    > tucker@10.4.148.25's password:
    >
    >If I look at the /var/log/security file, I find

    [snip]
    > Jan 10 11:30:36 dpiems sshd[23804]: Failed password for tucker from
    >10.4.148.25 port 35617 ssh ^^^^^^^^


    This indicates that password authentication was attempted.

    >By looking at the logs on my RADIUS server, I can see that the password
    >is being successfully authenticated, and then a second-factor challenge
    >is being sent. It appears as if sshd is (1) not displaying the second
    >factor authentication to the user, and (2) responding to the challenge
    >with some other piece of information. This of course fails, and the
    >RADIUS server tries again 2 more times before giving up.


    Right, see my post the other day about the difference between password
    and keyboard-interactive authentication, and how sshd tries to map the
    non-interactiveness of password to the interactiveness of PAM.

    >I then discovered the PAMAuthenticationViaKbdInt entry in the
    >sshd_config file, and set it to yes (it was commented out previously)
    >and restarted the sshd service.


    This option doesn't exist in current versions (probably replaced by the
    combination of ChallengeResponseAuthentication and UsePAM), but you will
    most likely need it on. However as a general principle (and mentioned at
    the top of your file), as shipped the OpenSSH config files have the
    default settings, but commented out - i.e. uncommenting an option
    without changing it should be a no-op. If in doubt, consult the man page
    (and hope that your Linux distributor hasn't changed the code w/o
    changing the man page, which unfortunately is common among them).

    > This made no difference.


    If it made no difference *at all*, i.e. the log still says "Failed
    password", the most likely problem is that your SSH *client* isn't
    *attempting* keyboard-interactive authentication. The server can't force
    it to... The format of the prompt above is another hint in that
    direction:

    $ ssh -o PreferredAuthentications=password somehost
    per@somehost's password:

    $ ssh -o PreferredAuthentications=keyboard-interactive somehost
    Password:

    If your OpenSSH client is as old as the server, I'm not sure if it has
    the PreferredAuthentications option, otherwise you can obviously try the
    second variant above - and then update your ssh_config or
    ~/.ssh/config. Another possibility may be to disallow password
    authentication on the server - your sshd_config seems to indicate that
    PasswordAuthentication has the default value of 'no', but it's pretty
    mangled by your news-posting program, and the comment above it doesn't
    make sense - plus of course all the evidence from your failed attempts
    indicate that it is *not* disabled.

    --Per Hedeland
    per@hedeland.org


  3. Re: OpenSSH and pam_radius_auth.so

    Comments in-line below:

    Per Hedeland wrote:
    > In article <1168545415.674920.181610@i39g2000hsf.googlegroups. com> "Dave
    > Isaacs" writes:
    > >I am running RedHat EL3 with OpenSSH OpenSSH_3.6.1p2.

    >
    > That is a pretty ancient version, but it might work...
    >

    Well, this is the version that came with RH EL3. We are upgrading to
    EL4 soon, maybe I should wait. Or maybe I should compile my own,
    upgraded, version.

    > >By looking at the logs on my RADIUS server, I can see that the password
    > >is being successfully authenticated, and then a second-factor challenge
    > >is being sent. It appears as if sshd is (1) not displaying the second
    > >factor authentication to the user, and (2) responding to the challenge
    > >with some other piece of information. This of course fails, and the
    > >RADIUS server tries again 2 more times before giving up.

    >
    > Right, see my post the other day about the difference between password
    > and keyboard-interactive authentication, and how sshd tries to map the
    > non-interactiveness of password to the interactiveness of PAM.
    >


    Um, I can't find any post about this from "the other day." Could you be
    more specific please (such as a subject line)?

    >
    > > This made no difference.

    >
    > If it made no difference *at all*, i.e. the log still says "Failed
    > password", the most likely problem is that your SSH *client* isn't
    > *attempting* keyboard-interactive authentication. The server can't force
    > it to... The format of the prompt above is another hint in that
    > direction:
    >

    It made no difference *at all*.

    > $ ssh -o PreferredAuthentications=password somehost
    > per@somehost's password:
    >
    > $ ssh -o PreferredAuthentications=keyboard-interactive somehost
    > Password:
    >

    I will try these variations out tomorrow and report the results.

    Thanks for the info

    Dave I


  4. Re: OpenSSH and pam_radius_auth.so

    In article <1168573788.364355.262280@38g2000cwa.googlegroups.c om> "Dave
    Isaacs" writes:
    >
    >Comments in-line below:


    Thanks.:-)

    >Per Hedeland wrote:
    >>
    >> Right, see my post the other day about the difference between password
    >> and keyboard-interactive authentication, and how sshd tries to map the
    >> non-interactiveness of password to the interactiveness of PAM.
    >>

    >
    >Um, I can't find any post about this from "the other day." Could you be
    >more specific please (such as a subject line)?


    Sorry, it was posted two days before I wrote the above, and the
    (inherited) subject line was the rather informative "Re: Difference
    between password and keyboard-interactive", so I thought you should
    have found it already in the generally-recommended "read before you
    post" phase... Anyway, here's a direct link:

    http://groups.google.com/group/comp....8e9cf45949a6f1

    --Per Hedeland
    per@hedeland.org

  5. Re: OpenSSH and pam_radius_auth.so


    Per Hedeland wrote:
    > >
    > >Um, I can't find any post about this from "the other day." Could you be
    > >more specific please (such as a subject line)?

    >
    > Sorry, it was posted two days before I wrote the above, and the
    > (inherited) subject line was the rather informative "Re: Difference
    > between password and keyboard-interactive", so I thought you should
    > have found it already in the generally-recommended "read before you
    > post" phase... Anyway, here's a direct link:
    >
    > http://groups.google.com/group/comp....8e9cf45949a6f1
    >


    How odd. I did look and found nothing. Thanks for the link.

    Anyway, back to the problem at hand.

    In my sshd_config file I explicitly set

    PasswordAuthentication no

    This made all ssh attempts fail immediately with the message

    Permission denied (publickey,keyboard-interactive).

    So I re-commented out the PassworkAuthentication setting (it must
    default to yes), and then tried

    ssh -o PreferredAuthentications=keyboard-interactive
    tucker@localhost

    This also failed immediately, with the message

    Permission denied (publickey,password,keyboard-interactive).

    As for ssh clients, in my above attempts I used the ssh client on the
    machine (and just specify localhost as the hostname). The version as
    reported by 'ssh -v' is "OpenSSH_3.6.1p2, SSH protocols 1.5/2.0,
    OpenSSL 0x0090701f"

    I also tried PuTTY 0.57 and ssh version 4.3p2 from my Ubuntu desktop.
    The results do not appear to differ between clients.

    Thanks for your help

    Dave I


  6. Re: OpenSSH and pam_radius_auth.so

    In article <1168613239.137410.216370@v45g2000cwv.googlegroups. com> "Dave
    Isaacs" writes:
    >
    >Per Hedeland wrote:
    >>
    >> http://groups.google.com/group/comp....8e9cf45949a6f1
    >>

    >
    >How odd. I did look and found nothing. Thanks for the link.


    Googlegroups seems to have problems lately - it couldn't find that
    article based on Message-ID (the lookup method I typically use), and in
    another group in a similar situation, it couldn't find either my article
    or the one I had replied to, based on Message-ID *or* Subject line or
    anything else - and yet the article I had replied to was actually
    *posted* via Google. Though I don't know if the problems affect the
    "normal" read/post interfaces, I only ever use the search/lookup stuff.

    >In my sshd_config file I explicitly set
    >
    > PasswordAuthentication no
    >
    >This made all ssh attempts fail immediately with the message
    >
    > Permission denied (publickey,keyboard-interactive).
    >
    >So I re-commented out the PassworkAuthentication setting (it must
    >default to yes), and then tried
    >
    > ssh -o PreferredAuthentications=keyboard-interactive
    >tucker@localhost
    >
    >This also failed immediately, with the message
    >
    > Permission denied (publickey,password,keyboard-interactive).
    >
    >As for ssh clients, in my above attempts I used the ssh client on the
    >machine (and just specify localhost as the hostname). The version as
    >reported by 'ssh -v' is "OpenSSH_3.6.1p2, SSH protocols 1.5/2.0,
    >OpenSSL 0x0090701f"
    >
    >I also tried PuTTY 0.57 and ssh version 4.3p2 from my Ubuntu desktop.
    >The results do not appear to differ between clients.


    It seems to me that your server is offering keyboard-interactive, but
    immediately rejects any attempt to use it. In your sshd_config, you had
    a commented-out 'ChallengeResponseAuthentication yes' - this would imply
    that it's on by default, and it certainly is in current versions, but as
    a "just in case" you could try uncommenting it. Though if it was really
    set to 'no', sshd shouldn't offer keyboard-interactive at all.

    It would of course also be prudent to run sshd with debugging on, to see
    if that provides some clues as to why the keyboard-interactive attempts
    get rejected. But if it's something other than an obvious
    misconfiguration (and I rather doubt that at this point), it won't
    really help since no-one will be interested in hunting for bugs in that
    old version (well, maybe RH if you have a support contract).

    If it still doesn't work, I'd definitely suggest trying a current
    version of sshd. You don't have to replace the one you already have,
    just download the source tarball from openssh.org and build it - then
    you can run it with a different config file on a different port for
    testing.

    FWIW, I've had great success with pam_radius_auth (somewhat modified,
    but not relevant to sshd) and multi-challenge using a more recent
    OpenSSH version than yours (don't remember which exactly, but it was a
    3.x), on an older Linux (at least I believe RH 7.3 is older than EL 3,
    if not it's about the same era).

    --Per Hedeland
    per@hedeland.org

  7. Re: OpenSSH and pam_radius_auth.so


    Per Hedeland wrote:
    > In article <1168613239.137410.216370@v45g2000cwv.googlegroups. com> "Dave
    > Isaacs" writes:
    > >
    > >Per Hedeland wrote:
    > >>

    > It seems to me that your server is offering keyboard-interactive, but
    > immediately rejects any attempt to use it. In your sshd_config, you had
    > a commented-out 'ChallengeResponseAuthentication yes' - this would imply
    > that it's on by default, and it certainly is in current versions, but as
    > a "just in case" you could try uncommenting it. Though if it was really
    > set to 'no', sshd shouldn't offer keyboard-interactive at all.
    >

    I had tried that earlier. It made no difference. In fact, since
    nothing seemed to be making any difference I was starting to worry that
    I was editing the wrong config file. So I added a bogus config
    setting, and sshd failed to restart. So I am working with the correct
    config file.

    > It would of course also be prudent to run sshd with debugging on, to see
    > if that provides some clues as to why the keyboard-interactive attempts
    > get rejected. But if it's something other than an obvious
    > misconfiguration (and I rather doubt that at this point), it won't
    > really help since no-one will be interested in hunting for bugs in that
    > old version (well, maybe RH if you have a support contract).
    >

    I contacted RH support already, and they declined to help me since
    pam_radius_auth is involved and they don't support pam_radius_auth. My
    arguments that pam_radius_auth was incidental to the problem did not
    sway them :-(

    > If it still doesn't work, I'd definitely suggest trying a current
    > version of sshd. You don't have to replace the one you already have,
    > just download the source tarball from openssh.org and build it - then
    > you can run it with a different config file on a different port for
    > testing.
    >

    We are upgrading to EL 4 within the next year, so I am going to try the
    OpenSSH 3.9p1 that ships with EL 4.

    > FWIW, I've had great success with pam_radius_auth (somewhat modified,
    > but not relevant to sshd) and multi-challenge using a more recent
    > OpenSSH version than yours (don't remember which exactly, but it was a
    > 3.x), on an older Linux (at least I believe RH 7.3 is older than EL 3,
    > if not it's about the same era).
    >

    Well I am glad to hear that it *can* work. Thanks for the inspiration
    ;-)

    Dave I


  8. Re: OpenSSH and pam_radius_auth.so

    sword:
    > >

    > I will try these variations out tomorrow and report the results.
    >

    Success! Well, kind of...

    I upgraded to RedHat EL4, which comes with OpenSSH 3.9p1, recompiled
    pam_radius_auth.so just in case, and tested again.

    The challenge response worked! The second-factor challenge was
    received on the client, and the response was validated at the server.

    Unfortunately, once the user was authenticated, he got kicked out
    immediately. The console show the message

    Read from remote host xx.xx.xx.xx: Connection reset by peer
    Connection to xx.xx.xx.xx closed.

    So something still is wrong. I think, however, I am over the pam
    authentication hurdle.

    If anybody has any suggestions on my latest problem, help would be
    greatly appreciated.

    Thanks for the help getting this far.

    Dave Isaacs


  9. Re: OpenSSH and pam_radius_auth.so

    In article <1168897289.689701.187330@a75g2000cwd.googlegroups. com> "Dave
    Isaacs" writes:
    >
    >I upgraded to RedHat EL4, which comes with OpenSSH 3.9p1, recompiled
    >pam_radius_auth.so just in case, and tested again.
    >
    >The challenge response worked! The second-factor challenge was
    >received on the client, and the response was validated at the server.


    Great!:-)

    >Unfortunately, once the user was authenticated, he got kicked out
    >immediately. The console show the message
    >
    > Read from remote host xx.xx.xx.xx: Connection reset by peer
    > Connection to xx.xx.xx.xx closed.


    "The console"? Do you mean that the client displays this message
    (presumably wherever you're running it, which just happened to be on the
    console)? If so, I think it's likely that the sshd process crashed (not
    the main daemon, but (one of) the process(es) forked to handle the
    session). In that case, running the server in debug mode, and/or with
    core dumps enabled and doing a stack backtrace on the core dump, may
    give some clues.

    --Per Hedeland
    per@hedeland.org

  10. Re: OpenSSH and pam_radius_auth.so

    >
    > "The console"? Do you mean that the client displays this message
    > (presumably wherever you're running it, which just happened to be on the
    > console)? If so, I think it's likely that the sshd process crashed (not
    > the main daemon, but (one of) the process(es) forked to handle the
    > session). In that case, running the server in debug mode, and/or with
    > core dumps enabled and doing a stack backtrace on the core dump, may
    > give some clues.
    >

    By console, I meant the client. I should have been more specific.

    I tried debug mode for sshd, and found the following in the logs

    debug1: auth2_challenge_start: trying authentication method 'pam'
    Postponed keyboard-interactive for tucker from ::ffff:10.4.148.59
    port 1195 ssh2
    Postponed keyboard-interactive/pam for tucker from
    ::ffff:10.4.148.59 port 1195 ssh2
    debug1: PAM: num PAM env strings 0
    Postponed keyboard-interactive/pam for tucker from
    ::ffff:10.4.148.59 port 1195 ssh2
    Accepted keyboard-interactive/pam for tucker from
    ::ffff:10.4.148.59 port 1195 ssh2
    debug1: monitor_child_preauth: tucker has been authenticated by
    privileged process
    Accepted keyboard-interactive/pam for tucker from
    ::ffff:10.4.148.59 port 1195 ssh2
    PAM: pam_open_session(): Authentication service cannot retrieve
    authentication info.
    debug1: do_cleanup
    debug1: PAM: cleanup
    debug1: do_cleanup
    debug1: PAM: cleanup

    At that point sshd exited (I was running it in the foreground).

    This appears to point to a problem in my pam.d/sshd configuration. If
    you recall, my pam.d/sshd file contained

    #%PAM-1.0
    auth required pam_radius_auth.so debug
    account required pam_radius_auth.so
    session required pam_radius_auth.so

    I then changed this to be

    #%PAM-1.0
    auth required pam_radius_auth.so debug
    auth required pam_nologin.so
    account required pam_stack.so service=system-auth
    password required pam_stack.so service=system-auth
    session required pam_stack.so service=system-auth
    session required pam_loginuid.so

    which, except for the pam_radius_auth.so line, is what was in the file
    before I started messing with it.

    My ssh logins are now successful.

    I realize this isn't a PAM forum, but I must ask: is this a proper
    configuration for my pam/d.ssh file? One thing I think is wrong (or at
    least unnecessary) is the password line, since password management is
    now handled by my remote RADIUS server.

    Thanks again for all the help!

    Dave Isaacs


+ Reply to Thread