Bug 426050 - sshd fails without nscd when using LDAP
Summary: sshd fails without nscd when using LDAP
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss_ldap
Version: 5.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-18 01:02 UTC by Joshua Daniel Franklin
Modified: 2018-10-19 22:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-02 20:34:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
My /etc/ldap.conf (823 bytes, text/plain)
2007-12-18 19:56 UTC, Joshua Daniel Franklin
no flags Details

Description Joshua Daniel Franklin 2007-12-18 01:02:21 UTC
Description of problem:
With sshd 4.3p2-24.el5, if nscd is off and user information comes from LDAP,
sshd fails to find account information. This may be a glibc nss bug that sshd is
tickling, not sure. In any case downgrading openssh fixes it, as does starting
nscd. I'm running into this on both i386 and x86_64 if you're curious. A plain
ldapsearch, getent passwd, etc. works. It's also been separately reported here
http://bugs.centos.org/view.php?id=2532 

Version-Release number of selected component (if applicable):
openssh-server-4.3p2-24.el5

How reproducible:
Every time.

Steps to Reproduce:
1. /etc/init.d/nscd stop
2. ssh host.tld # from a remote host
  
Actual results:
Connection to myhost.domain.tld closed by remote host.

In /var/log/secure:

Dec 17 15:31:35 myhost sshd[19537]: Postponed publickey for joshuadf from
w.x.y.z port 34973 ssh2
Dec 17 15:31:36 myhost sshd[19536]: pam_ldap: could not open secret file
/etc/ldap.secret (No such file or directory)
Dec 17 15:31:37 myhost sshd[19536]: Accepted publickey for joshuadf from w.x.y.z
port 34973 ssh2
Dec 17 15:31:37 myhost sshd[19536]: pam_unix(sshd:session): session opened for
user joshuadf by (uid=0)
nss_ldap: could not search LDAP server - Server is unavailable
Dec 17 15:31:05 myhost sshd[19507]: fatal: login_get_lastlog: Cannot find
account for uid 1234


Expected results:
successful ssh login

Additional info:

Comment 1 Tomas Mraz 2007-12-18 09:31:04 UTC
I'm sorry I cannot reproduce the problem here. I'm running this openssh version
with authentication against a LDAP server through pam_ldap and everything works
fine even without nscd.

Can you rebuild the openssh src.rpm with %define nss 0 and try whether it helps?


Comment 2 Joshua Daniel Franklin 2007-12-18 17:55:29 UTC
Sure, I'll try that. By the way, do you have "bind_policy soft" in /etc/ldap.conf?

Comment 3 Tomas Mraz 2007-12-18 19:38:49 UTC
I've tried both with bind_policy soft and hard and still cannot reproduce it.


Comment 4 Joshua Daniel Franklin 2007-12-18 19:51:20 UTC
OK, it works with '%define nss 0' in the SPEC. I rebuilt from this srpm:
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/openssh-4.3p2-24.el5.src.rpm
Toggling back to offical el5 the problem comes back.

Comment 5 Joshua Daniel Franklin 2007-12-18 19:56:05 UTC
Created attachment 289929 [details]
My /etc/ldap.conf

Comment 6 Tomas Mraz 2007-12-18 20:47:45 UTC
So the NSS suport is the culprit.

Although sshd doesn't call any function from NSS library it still has to link to
it because some .c files which call NSS are shared with the ssh client.

It seems like just the linking to NSS causes some conflicts with the nss_ldap or
openldap library itself.

I'm ccing maintainers of NSS, nss_ldap and openldap if they have some ideas on
how to debug/fix this.


Comment 7 Joshua Daniel Franklin 2007-12-19 21:17:41 UTC
From spamgl 2007-12-19 20:15 at CentOS bugzilla:

"I have seen the same problem when trying to authenticate against our main
openldap server, v2.2.13-6.4e (Centos 4.4). However when I modify /etc/ldap.conf
to point at our backup ldap server, openldap v2.2.13-4 (Centos 4.3), users can
authenticate.

Turning on nscd, on the affected client, allows us to authenticate against our
main openldap (v2.2.13-6.4e) server."

Comment 8 Tomas Mraz 2007-12-19 21:37:42 UTC
Could you try to strace the old openssh and new openssh servers when trying to
authenticate against the ldap server? Of course please ensure that you do not
release security relevant info in the attached logs as this is a public
bugzilla. (such as private keys of the server, passwords/password hashes, or
ldap secret)


Comment 9 Joshua Daniel Franklin 2007-12-20 00:44:51 UTC
I'm sorry I had other priorities today and I'm leaving on holiday
tomorrow so I will probably not be able to get to this for a couple 
weeks.

The CentOS bugzilla has this very interesting note from spamgl:
"For another work-around, we've found that turning off SSL in ldap.conf on the
client and contacting the LDAP server unencrypted also works on our main LDAP
server (v2.2.13-6.4e)."

Also you are of course welcome to make this high priority but 
enabling nscd is a pretty easy workaround. In fact I normally
have nscd enabled but had disabled it temporarily to debug 
something else.

Comment 10 Tomas Mraz 2007-12-20 08:50:32 UTC
I've finally reproduced the problem here. The problem is caused by sharing the
TCP connection to the LDAP server between parent and child processes and NSS
linking to pthread library.

The question is how to fix it.


Comment 11 Tomas Mraz 2007-12-20 16:30:17 UTC
This is another incarnation of bug 154314, it is fixed by the patch to nss_ldap.



Note You need to log in before you can comment on or make changes to this bug.