From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.7 Description of problem: I was unable to get ssh to authenticate to an ldap server. I fixed it by setting "PAMAuthenticationViaKbdInt yes" in sshd_config, following a suggestion by Lance Nehring <nehring> that I found while googling. I'll quote his email, as it explains the problem exactly: http://www.openldap.org/lists/openldap-software/200312/msg00040.html ------ clip here ------- RE: problems with ldap and ssh To: openldap-software Subject: RE: problems with ldap and ssh From: L Nehring <nehring> Date: Mon, 01 Dec 2003 19:45:44 -0700 User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/ 20031007 Here's an answer that I finally found after having that same trouble as Rolandas Juodzbalis in his post on this list way back on Mon, 9 Jul 2001 10:11:12 +0300 (EEST). I've spent several hours searching Google, RedHat, OpenLDAP, and OpenSSH for an answer but only found posts with similar questions and no answers. In a nutshell: I'm running RedHat 9 using OpenLDAP 2.0.27 and Pam 0.75 for the client. The LDAP server is running OpenBSD 3.4 and OpenLDAP 2.0.27. After configuring the client to use LDAP authentication by running RedHat's `authconfig`, the client's SSH daemon would _only_ successfully authenticate users via LDAP that also happened to be in the /etc/passwd file. For users that were not known locally, the client was asking the LDAP server for a uid=NOUSER and getting a negative response. Other mechanisms using PAM authentication such as "su - someuser" worked okay, but when using SSH the client was not asking for the correct user from the LDAP server. It has turned out to be a SSH configuration issue where sshd has trouble using PAM with a default setting in the "/etc/ssh/sshd_config" file. By setting the parameter "PAMAuthenticationViaKbdInt" to "yes", the sshd can now communicate with PAM well enough to ask the LDAP server for the correct account. The sshd_config man page says that doing this bypasses the SSH "PasswordAuthentication" setting, but that default is "yes" anyway, so in my case I didn't create a security problem. Hopefully this information can help save someone else a little time. Lance http://www.newparticles.com/ ------ clip here ------- Version-Release number of selected component (if applicable): openssh-3.6.1p2-19 How reproducible: Always Steps to Reproduce: 1. Turn on ldap authentication on a machine "client1" by running: authconfig --kickstart --useshadow --enablemd5 --enableldap --enableldapauth --ldapserver ldap.example.com --ldapbasedn dc=example,dc=com --enablecache 2. From another machine, do "ssh fred@client1" where "fred" is present in the ldap database running on ldap.example.com Actual Results: The client will use the username "NOUSER" when connecting to the ldap server (this can be seen easily by using ethereal to watch the connection). Unsurprisingly, the server doesn't give any useful information for NOUSER. Expected Results: The client should be using the correct username "fred", rather than "NOUSER" when communicating with the LDAP server. Additional info: Other commands that use the same PAM stack can authenticate ok, so it appears to be just ssh that is broken. I tested su and passwd, and they both worked fine. The problem can be fixed/worked-around by setting "PAMAuthenticationViaKbdInt yes" in sshd_config.
Easy fix: Change the order of the pam_ldap and pam_unix lines in each clause of the file /etc/pam.d/system-auth so that the LDAP lookup takes places *before* the local UNIX lookup. Could cause problems if the LDAP server goes away, however, so be careful. It might break the ability to login locally at all if it does. Tested locally against Active Directory backended LDAP server using MS SFU. Successful. Not tested in situations where LDAP server unreachable (yet).
Does it happen for you with the current FC3 openssh-3.9p1 ?
No response, tested - works for me on FC3.