From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; H010818) Description of problem: After updating openssl (bug #86112) sshd no longer allows users to log in. Version-Release number: OpenSSH_3.4p1
Created attachment 91853 [details] Log of connection attempt using ssh -v Added an example login attempt as an attachment.
I started having this problem after up2date upgraded openssh et al to 3.4p1-4 (from 3.4p1-2). Note that my system configuration did NOT change during this upgrade. Prior to the upgrade, OpenSSH worked as expected. After the upgrade, attempting to login with a non-root account resulted in the behavior described above (SSH encryption negotiated, then a disconnect before keyboard-interactive authentication, with an error like "sshd(pam_unix): authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=jrluser.domain.com user=foobar" in /var/log/messages and nothing in /var/log/secure). Note also that my system is configured to use Kerberos 5 authentication. If I disable Kerberos authentication with authtool, without restarting the SSH server, the new version of OpenSSH starts working properly again (i.e. prompting me for the user's password instead of unceremoniously disconnecting the connection). Of course, I can't log in to any of my user accounts now, as credentials are stored at the KDC, so this workaround has limited utility. I'm seeing the exact same problem in Red Hat Linux 9 with openssh version 3.5p1- 6.9, where when I have Kerberos 5 authentication enabled, ssh clients are disconnected, bypassing keyboard-interactive authentication.
The connection is disconnected because the SSH server is crashing with a segmentation fault. I'm seeing the same error on both Red Hat Linux 8 (openssh- server-3.4p1-4) and Red Hat Linux 9 (openssh-server-3.5p1-6.9). I am attaching debugger output for both versions in the hope that it will prove useful to the package maintainer. If you're playing along at home, enable Kerberos 5 authentication and use the following commands to start sshd under gdb: # gdb `which sshd` (gdb) run -ddd -p 2022 Now log into this special instance with the following command (typed in another virtual console or xterm on the same system): # ssh -p 2022 user@localhost GDB will intercept the SIGSEGV and leave you at the (gdb) prompt, where you can enter the command "backtrace" to see where you are in the stack.
Created attachment 93452 [details] GDB output for sshd (Red Hat Linux 8, openssh-server-3.4p1-4)
Created attachment 93453 [details] GDB output for sshd (Red Hat Linux 9, openssh-server-3.5p1-6.9)
RHL 8.0 is no longer supported.