Red Hat Bugzilla – Bug 119353
ssh cannot authenticate against ldap
Last modified: 2007-11-30 17:10:39 EST
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 <email@example.com> that I found while googling. I'll quote his
email, as it explains the problem exactly:
------ clip here -------
RE: problems with ldap and ssh
Subject: RE: problems with ldap and ssh
From: L Nehring <firstname.lastname@example.org>
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/
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.
------ clip here -------
Version-Release number of selected component (if applicable):
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.
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.
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
Tested locally against Active Directory backended LDAP server using
MS SFU. Successful. Not tested in situations where LDAP server
Does it happen for you with the current FC3 openssh-3.9p1 ?
No response, tested - works for me on FC3.