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.
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 `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.