http://bugzilla.mindrot.org/show_bug.cgi?id=613
Summary: sshd hanging
Product: Portable OpenSSH
Version: 3.6.1p2
Platform: ix86
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P2
Component: PAM support
AssignedTo: openssh-bugs at mindrot.org
ReportedBy: airwin at inf.bme.hu
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From airwin at inf.bme.hu 2003-07-07 18:54 ------- Created an attachment (id=353) --> (http://bugzilla.mindrot.org/attachment.cgi?id=353&action=view) server log This is the output of "sshd -ddd -p 2121". After the last line is printed there is no response from the daemon. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From dtucker at zip.com.au 2003-07-07 18:59 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From airwin at inf.bme.hu 2003-07-07 19:13 ------- 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 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From dtucker at zip.com.au 2003-07-07 19:30 ------- 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? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From airwin at inf.bme.hu 2003-07-07 19:55 ------- After clearing iptables the problem persists. Both Recv-Q and Send-Q are zero in netstat. For all connections. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From dtucker at zip.com.au 2003-07-07 20:07 ------- 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). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From airwin at inf.bme.hu 2003-07-07 20:42 ------- Created an attachment (id=354) --> (http://bugzilla.mindrot.org/attachment.cgi?id=354&action=view) 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613 ------- Additional Comments From dtucker at zip.com.au 2003-07-07 22:26 ------- 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 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=613
airwin at inf.bme.hu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From airwin at inf.bme.hu 2003-07-07 23:04 -------
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.