OpenSSH, PAM and pam_radius_auth
I'm trying to get RADIUS authentication to work on one of our systems, but keep running into problems. For some reason it seems that the account system does not allow the user to login, and once the user has been authenticated, it drops the connection by not allowing sshd to establish credentials for the user. It seems that OpenSSH first tries to authetnicate the user with an empty password (""), because if I set an empty password both in the local /etc/passwd, and on the RADIUS server, sshd is able to establish credentials for the user. Note that even with a non-empty password the authentication works, the daemon gets and OK from the radius server. There's a user with that given name in /etc/passwd. Anyone ideas about what could be wrong here? Here's the debug output from OpenSSH: debug1: userauth-request for user orbit-admin service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "orbit-admin" debug1: PAM: setting PAM_RHOST to "192.168.99.111" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth_send_banner: sent debug1: PAM: password authentication failed for orbit-admin: Authentication failure Failed none for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: userauth-request for user orbit-admin service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug1: keyboard-interactive devs debug1: auth2_challenge: user=orbit-admin devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/ttyp1 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM: setting PAM_TTY to "/dev/ttyp1" debug1: PAM: establishing credentials PAM: pam_setcred(): Authentication service cannot retrieve user credentials debug1: do_cleanup debug1: PAM: cleanup debug1: session_pty_cleanup: session 0 release /dev/ttyp1 My system-auth file: auth sufficient pam_radius_auth.so debug auth sufficient pam_unix.so likeauth nullok debug auth required pam_deny.so account required pam_unix.so password sufficient pam_unix.so nullok use_authtok md5 password required pam_deny.so session required pam_unix.so Versions: pam_radius-1.3.17 openssh-4.5p1
You have posted a question to the freeradius list and included a debug from - OpenSSH??? Don't you think that freeradius debug would be more helpful? Ivan Kalik Kalik Informatika ISP Dana 8/1/2008, "Johan Rydberg" <johan.rydberg@edgeware.tv> piše:
I'm trying to get RADIUS authentication to work on one of our systems, but keep running into problems. For some reason it seems that the account system does not allow the user to login, and once the user has been authenticated, it drops the connection by not allowing sshd to establish credentials for the user.
It seems that OpenSSH first tries to authetnicate the user with an empty password (""), because if I set an empty password both in the local /etc/passwd, and on the RADIUS server, sshd is able to establish credentials for the user.
Note that even with a non-empty password the authentication works, the daemon gets and OK from the radius server. There's a user with that given name in /etc/passwd.
Anyone ideas about what could be wrong here?
Here's the debug output from OpenSSH:
debug1: userauth-request for user orbit-admin service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "orbit-admin" debug1: PAM: setting PAM_RHOST to "192.168.99.111" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth_send_banner: sent debug1: PAM: password authentication failed for orbit-admin: Authentication failure Failed none for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: userauth-request for user orbit-admin service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug1: keyboard-interactive devs debug1: auth2_challenge: user=orbit-admin devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/ttyp1 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM: setting PAM_TTY to "/dev/ttyp1" debug1: PAM: establishing credentials PAM: pam_setcred(): Authentication service cannot retrieve user credentials debug1: do_cleanup debug1: PAM: cleanup debug1: session_pty_cleanup: session 0 release /dev/ttyp1
My system-auth file:
auth sufficient pam_radius_auth.so debug auth sufficient pam_unix.so likeauth nullok debug auth required pam_deny.so account required pam_unix.so password sufficient pam_unix.so nullok use_authtok md5 password required pam_deny.so session required pam_unix.so
Versions:
pam_radius-1.3.17 openssh-4.5p1 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
tnt@kalik.co.yu skrev:
You have posted a question to the freeradius list and included a debug from - OpenSSH??? Don't you think that freeradius debug would be more helpful?
As I stated, authentication in respect to RADIUS works just fine, therefor here's not need for the debug output from pam_radius_auth. I post to the freeradius list because the pam_radius_auth PAM module is part of the FreeRADIUS project, and there's a great chance that people on that list have used pam_radius_auth in the past. If you have any other questions related to where and why I post things, please take it in a private mail. ~j
Hi Johan, Its good to hear that you reached up a level where Radius is working fine. But we are unable to break the jinx, and I am getting the following error when trying to telnet to the box. The installation and configuration of pam radius module went fine. Could you please help in this regards. Error we are getting Jan 8 13:57:27 ada-delegate1 login: [ID 801593 auth.error] pam_radius_auth: Fai led looking up IP address for RADIUS server radius1 (errcode=12) Jan 8 13:57:27 ada-delegate1 login: [ID 801593 auth.error] pam_radius_auth: Fai led looking up IP address for RADIUS server 10.213.31.186 (errcode=12) Jan 8 13:57:27 ada-delegate1 login: [ID 801593 auth.error] pam_radius_auth: All RADIUS servers failed to respond. I dont see any other debug messages apart from the above msg available in the /var/adm/messages Thank you Regards Sobanbabu Bakthavathsalu ________________________________________ From: freeradius-users-bounces+sobanbabu_b=infosys.com@lists.freeradius.org [freeradius-users-bounces+sobanbabu_b=infosys.com@lists.freeradius.org] On Behalf Of Johan Rydberg [johan.rydberg@edgeware.tv] Sent: 08 January 2008 12:43 To: freeradius-users@lists.freeradius.org; pam-list@redhat.com Subject: OpenSSH, PAM and pam_radius_auth I'm trying to get RADIUS authentication to work on one of our systems, but keep running into problems. For some reason it seems that the account system does not allow the user to login, and once the user has been authenticated, it drops the connection by not allowing sshd to establish credentials for the user. It seems that OpenSSH first tries to authetnicate the user with an empty password (""), because if I set an empty password both in the local /etc/passwd, and on the RADIUS server, sshd is able to establish credentials for the user. Note that even with a non-empty password the authentication works, the daemon gets and OK from the radius server. There's a user with that given name in /etc/passwd. Anyone ideas about what could be wrong here? Here's the debug output from OpenSSH: debug1: userauth-request for user orbit-admin service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "orbit-admin" debug1: PAM: setting PAM_RHOST to "192.168.99.111" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth_send_banner: sent debug1: PAM: password authentication failed for orbit-admin: Authentication failure Failed none for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: userauth-request for user orbit-admin service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug1: keyboard-interactive devs debug1: auth2_challenge: user=orbit-admin devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for orbit-admin from 192.168.99.111 port 39102 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/ttyp1 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM: setting PAM_TTY to "/dev/ttyp1" debug1: PAM: establishing credentials PAM: pam_setcred(): Authentication service cannot retrieve user credentials debug1: do_cleanup debug1: PAM: cleanup debug1: session_pty_cleanup: session 0 release /dev/ttyp1 My system-auth file: auth sufficient pam_radius_auth.so debug auth sufficient pam_unix.so likeauth nullok debug auth required pam_deny.so account required pam_unix.so password sufficient pam_unix.so nullok use_authtok md5 password required pam_deny.so session required pam_unix.so Versions: pam_radius-1.3.17 openssh-4.5p1 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***
Sobanbabu Bakthavathsalu wrote:
Hi Johan,
Its good to hear that you reached up a level where Radius is working fine. But we are unable to break the jinx, and I am getting the following error when trying to telnet to the box. The installation and configuration of pam radius module went fine. Could you please help in this regards.
Error we are getting Jan 8 13:57:27 ada-delegate1 login: [ID 801593 auth.error] pam_radius_auth: Fai led looking up IP address for RADIUS server radius1 (errcode=12)
So.... fix DNS so that it has a name to IP mapping for that host. Or, add that name to IP mapping into /etc/hosts. The module can't do anything if you tell it to use "radius1" as a RADIUS server, and the don't tell it where "radius1" is on the network. Alan DeKok.
Hi Alan, So.... fix DNS so that it has a name to IP mapping for that host. Or, add that name to IP mapping into /etc/hosts. The module can't do anything if you tell it to use "radius1" as a RADIUS server, and the don't tell it where "radius1" is on the network.
We have entry in the /etc/hosts file for radius1 server, but the pam_auth module is having issues in reading it. You have seen the error, even if we give the IP address, it tries to resolve it to IP again.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***
Sobanbabu Bakthavathsalu wrote:
We have entry in the /etc/hosts file for radius1 server, but the pam_auth module is having issues in reading it. You have seen the error, even if we give the IP address, it tries to resolve it to IP again.
Hmm... I think it may be necessary also to add an entry to /etc/hosts for the *local* machine hostname -> IP mapping. Alan DeKok.
Johan Rydberg wrote:
It seems that OpenSSH first tries to authetnicate the user with an empty password (""), because if I set an empty password both in the local /etc/passwd, and on the RADIUS server, sshd is able to establish credentials for the user.
PAM does weird things. OpenSSH does weird things. See bugs.freeradius.org. There a number of issues relating to the PAM module, including patches that may help here. I recall something related to "try_first_pass". I haven't spent much time looking at PAM recently. All I recall from using it a few years ago is that I spent a LOT of time fighting with it, and had great difficulty trying to make it do anything. The complete and total lack of debugging information helped, too.
PAM: pam_setcred(): Authentication service cannot retrieve user credentials
That likely means that the user doesn't have a UID/GID/etc in /etc/passwd. The PAM RADIUS module doesn't set UID or GID. I tried to see if it was possible, and was told: a) No, it wasn't possible b) Yes, it was possible, and it was documented c) Yes, it was possible, but only the PAM authors knew how to make it work Getting conflicting answers from the same set of people made me unsubscribe from the PAM list. :( Alan DeKok.
Hello Will this still expand with 2.0.0-beta ? %{config:client[%{Packet-Src-IP-Address}].shortname} I'm using 2.0.0-pre2 and it's working, but I am seeing some warnings with 2.0.0-beta about not being able to expand/find it.
Duane Cox wrote:
Hello
Will this still expand with 2.0.0-beta ?
%{config:client[%{Packet-Src-IP-Address}].shortname}
I've just committed a fix that will expand the contents of %{config:...}. So if you still have an old-style client definition, it should now work.
I'm using 2.0.0-pre2 and it's working, but I am seeing some warnings with 2.0.0-beta about not being able to expand/find it.
In 2.0.0-beta, you can do: %{client:shortname}, which means "the client that this request came from". It's much simpler than the above method. Alan DeKok.
Thank you sir, and now the million dollar question, how soon until we see a -rc1 ? -----Original Message----- From: freeradius-users-bounces+duanec=mail.illicom.net@lists.freeradius.org [mailto:freeradius-users-bounces+duanec=mail.illicom.net@lists.freeradius.or g] On Behalf Of Alan DeKok Sent: Tuesday, January 08, 2008 10:43 AM To: FreeRadius users mailing list Subject: Re: variables with 2.0.0-beta Duane Cox wrote:
Hello
Will this still expand with 2.0.0-beta ?
%{config:client[%{Packet-Src-IP-Address}].shortname}
I've just committed a fix that will expand the contents of %{config:...}. So if you still have an old-style client definition, it should now work.
I'm using 2.0.0-pre2 and it's working, but I am seeing some warnings with 2.0.0-beta about not being able to expand/find it.
In 2.0.0-beta, you can do: %{client:shortname}, which means "the client that this request came from". It's much simpler than the above method. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
Alan DeKok -
Duane Cox -
Johan Rydberg -
Sobanbabu Bakthavathsalu -
tnt＠kalik.co.yu