Strange behaviour w/ Solaris9 + pam_ldap + openssh 3.7.1p2

[Rich Bishop]

Darren Tucker wrote:

>Rich Bishop wrote:
>  
>
>>I have a Solaris 9 system which is using Sun's pam_ldap to access user &
>>group information in a Netscape 4.16DS. This was working fine until I
>>upgraded ssh on the box. However, now I'm using 3.7.1p2 with pam support
>>I have the following problem:
>>
>>If a user (local or ldap)  enters the correct password everything works
>>fine. Entering a wrong password results in the sshd process becoming
>>unresponsive, until it eventually times out as set by LoginGraceTime in
>>sshd_config. Normally, sshd should prompt for a password a number of
>>times before closing the connection. Running sshd in debug mode under
>>truss shows it going into a sleep state.
>>
>>I've done some searching on this - I found
>>http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=106743975716923&w=2
>>on the sshd-devel list but there are no follow ups as yet. I've been in
>>touch with the original poster, but he hasn't resolved the problem. I'd
>>be happy to provide any debugging information that would be useful in
>>diagnosing the problem.
>>    
>>
>
>It sounds like the PAM authentication thread is crashing (or possibly
>deadlocking) for some reason.  If it's crashing, you can provide some
>useful diagnostics thusly:
>
>1) Check if sshd left a core in /
>1a) otherwise, turn on core dump saving with coreadm (sorry, can't provide
>more detail at the moment).
>1b) run sshd until the problem occurs.
>2) If ssh produces a core, feed it to gdb and provide a backtrace. In the
>build directory, run gdb ./sshd /path/to/core and at the gdb prompt, type
>"bt".
>
>Save the core dump and copy of sshd from the build dir (it has the
>debugging symbols) in case more info is required.
>
>You could also try a current snapshot as there have been several
>PAM-related fixes since the 3.7.1p2 release.
>
>Also, possibly related:
>http://bugzilla.mindrot.org/show_bug.cgi?id=740
>
>  
>
I get the same behaviour from the latested snapshot After a little 
messing around I got a coredump I could use. Here's the backtrace (from 
release 3.7.1p2):

#0  0x00030e54 in sshpam_thread_conv (n=1, msg=0xffbfb1a4, 
resp=0xffbff210, data=0x0)
    at auth-pam.c:168
#1  0xfeb24ecc in __get_authtok () from /usr/lib/security/pam_ldap.so.1
#2  0xfeb22678 in pam_sm_authenticate () from 
/usr/lib/security/pam_ldap.so.1
#3  0xff382e04 in run_stack () from /usr/lib/libpam.so.1
#4  0xff38310c in pam_authenticate () from /usr/lib/libpam.so.1
#5  0x00030fc8 in sshpam_thread (ctxtp=0x7a138) at auth-pam.c:230
#6  0x00030d3c in pthread_create (thread=0x7a138, attr=0x0, 
thread_start=0x30f4c <sshpam_thread>,
    arg=0x0) at auth-pam.c:89
#7  0x00031350 in sshpam_init_ctx (authctxt=0x7a138) at auth-pam.c:367
#8  0x0002b778 in mm_answer_pam_init_ctx (socket=5, m=0xffbff528) at 
monitor.c:825
#9  0x0002aea0 in monitor_read (pmonitor=0x70018, ent=0x68fb4, 
pent=0xffbff5ac) at monitor.c:413
#10 0x0002ab0c in monitor_child_preauth (pmonitor=0x70018) at monitor.c:299
#11 0x0001a404 in privsep_preauth () at sshd.c:595
#12 0x0001b584 in main (ac=7884, av=0x7) at sshd.c:1472

Let me know if there's anything more I can provide (although I'll be 
away for Thankgiving weekend after today).

Regards,

Rich