pam_ldap, bugs and some SSL

Since I spent so much time in finding out why the hell sshd kept crashing when I turned on ldap-support, other people might as well profit from it.

This is what happened after I turned on ldap-support in /etc/nsswitch.conf and /etc/pam.d. According to auth.log:

Jun 6 13:59:12 proto sshd[27433]: fatal: buffer_put_cstring: s == NULL

messages also knew something:

Jun 6 13:59:12 proto kernel: pid 27435 (sshd), uid 0: exited on signal 11
Jun 6 13:59:12 proto sshd[27433]: fatal: buffer_put_cstring: s == NULL

An sshd segmentation fault when trying to log in. According to what I’ve found in bug-reports, it does this if ldap.conf or nss_ldap.conf does not exist. Only these did exist in my case. debugging-output from nss_ldap turned up nothing, pam_ldap doesn’t even support a debug-flag: “This option is recognized by pam_ldap but is presently ignored.” Says so in the man-page. Thank you.

The key to it was revealed by putting in “debug 5” into ldap.conf and starting sshd with debugging:

# /usr/sbin/sshd -d -d -d
[snip]
ldap_ndelay_off: 7
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
debug1: do_cleanup
Segmentation fault: 11

Well, it seems you need either to use ldaps://servername and not ldaps://IP in ldap.conf so SSL knows which certificate needs to be used, AND it needs a correct certificate. On the other hand, if I just use ldap://servername without SSL, then local ssh works again, however I seem to have a problem with all the ldap-services.

Some debugging of an sshd core-file reveals the following:

#928 0x0806820f in sshpam_thread (ctxtp=0x8079f80)
at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:469
Previous frame inner to this frame (corrupt stack?)

Comments are closed.