On my system (i686, Linux From Scratch) I have upgraded several software. Now the OpenSSH daemon is not working. Symptom: after connection the deamon hangs (in sleeping state). If the client is killed, the forked server process remains "stuck". I changed to glibc-2.3.2 and Linux-PAM-0.77 and also recompiled openssh-3.6.1p2.
Created attachment 353 [details] server log This is the output of "sshd -ddd -p 2121". After the last line is printed there is no response from the daemon.
Do you have a firewall, NAT or packet filter between client and server? Try "ifconfig eth0 mtu 576" and see if you can reproduce your problem.
There is a simple packet filter on the server, no NAT. The rules were not changed. After the ifconfig command sshd prints even fewer lines. The last lines are: debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: monitor_read: checking request 10 debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering
The things I mentioned are notorious for hanging sessions caused but MTU problems (not just SSH although that seems to be more sensitive to problems). When it's in the hung state, can you do "netstat -an" and check the values in the Recv-Q and Send-Q columns? Also, can you reproduce the problem without the packet filter?
After clearing iptables the problem persists. Both Recv-Q and Send-Q are zero in netstat. For all connections.
OK, it looks like it's proably not MTU. One other thing to check: can you do the netstat on the client too?. You can try strace'ing a session which might give a better idea exactly where it's hanging (I suggest you use -D for no-daemon rather than the debug options as it will keep the output volume down). strace -f /path/to/sshd -D -p [portno] Warning: There will be a lot of output, and the trace will contain your password if you're using password auth, so blank it out (or change it for the test then change it back).
Created attachment 354 [details] sshd strace output Here is the strace output. Looks like sshd is hanging in rt_sigsuspend(). Just discovered: if I connect from localhost, the login is successfull.
Did some digging and there are similar reports relating to glibc/libpthreads. This appears to be a glibc bug #1305 (against glibc-2.2.4). What version of glibc do you have? Is sshd linked against pthreads and if so can you compile without it? My guess is pthreads messes up select() somehow. See also: http://bugs.gnu.org/cgi-bin/gnatsweb.pl?database=glibc&pr=1305 http://gcc.gnu.org/ml/gcc/2001-12/msg00814.html http://sources.redhat.com/ml/libc-alpha/1999-09/msg00078.html
I have come to similar conclusions, too. Searching the web for rt_sigsuspend gives lots of problems but no solution. My glibc is 2.3.2, the kernel is 2.4.21. They are really not old. Ssh configure hasn't got option to choose a threading model, so I checked sshd. It is not linked against libpthread. The trace shows it is a dependency of libnss_lwres. So I disabled lwres in nsswitch.conf and rejoice, sshd is now working. This is clearly not an sshd bug. Marking invalid. Thanks for helping, Darren.
Mass change of RESOLVED bugs to CLOSED