Occasionally, we're noticing that sshd is core dumping on our IRIX 6.5.18f machine. The only time we've really noticed it is when users are logging in with putty from offsite (although I'm not really sure it's a client issue). The user manages to log in, sshd apparently core dumps, but the user is not logged out, the privilege separated user is still running their own personal sshd spawn, and the parent is 1, so the root owned sshd process is gone. wtmp is not updated, so the only way you can tell the user is logged in is by listing their processes. The end user doesn't notice that anything happened...and this doesn't ALWAYS happen, but I can't correlate any system event and this. It will happen when the system is first started, and it will happen when it's busier.
Created attachment 309 [details] dbx output
There was some host information I cut out of the dbx report, which may actually be helpful in determining the problem. The line that displays the host (item 6) First core: 6 record_login(pid = 13759, ttyname = 0x1014a22c = "/dev/ttyq7", user = 0x101520d8 = "user1", uid = ####, host = 0x101522a8 = "pcp01711145pcs.nrockv01.md.`omcast.net", addr = 0x7fff24b0, addrlen = 16) ["/usr/local/src/security/openssh-3.6.1p1/sshlogin.c":72, 0x1002be58] Second core: 6 record_login(pid = 182438, ttyname = 0x1014a22c = "/dev/ttyq39", user = 0x101520d8 = "user2", uid = ####, host = 0x10152358 = "toronto-hse-ppp3760148.symp`tico.ca", addr = 0x7fff24b0, addrlen = 16) ["/usr/local/src/security/openssh-3.6.1p1/sshlogin.c":72, 0x1002be58] For some reason, the 29th character of the hostname is messed up. The first hostname should be .comcast.net, the second hostname should be sympatico.ca
Ok. One more note for today. I think after looking through the source code and stuff that the actual problem may lie in verify_reverse_mapping. We had this option enabled in sshd_config, we disabled it and are currently monitoring for the core dumps. If we don't see any, that may be the root of this problem....hopefully it will point someone in the right direction towards fixing it.
doesn't look like the bug made it to the mailing list archive. did anyone see it?
*** This bug has been marked as a duplicate of 585 ***
Mass change of RESOLVED bugs to CLOSED