Description of problem: When Kerberos 5 authentication is configured (i.e. via authconfig), sshd's connection-specific child process segfaults (SIGSEGV) when a non-root user attempts to log onto the system. It doesn't matter of the non-root user authenticates locally or via Kerberos 5. The parent sshd instance is unaffected and continues to field connection attempts on port 22. I observed similar behavior on Red Hat Linux 8 after updating openssh-server from 3.4p1-2 to 3.4p1-4. From the perspective of the client, the connection is dropped before the user is prompted for a password. The problem can be duplicated by running sshd in debug mode (the "-d" option to sshd) under GDB. A GDB transcript that includes a backtrace is attached to this bug report. Version-Release number of selected component (if applicable): openssh-server-3.5p1-6.9 How reproducible: Every time Steps to Reproduce: 1. Run authconfig and enable Kerberos 5 authentication. 2. A reboot is NOT required. 3. Restarting sshd is NOT required. 4. Use the ssh client to attempt to log into a non-root account, e.g. ssh user@localhost. 5. It does not matter if the account authenticates via Kerberos 5 or locally via /etc/shadow. 6. To return to normal operations, re-run authconfig and disable Kerberos 5 authentication. Actual results: After the connection encryption is negotiated, the ssh client will lose contact with the sshd server child instance and report "Connection closed by <NAME OR ADDRESS>", e.g. "Connection closed by 127.0.0.1". When running sshd in debug mode under GDB, one will observe a segfault (signal SIGSEV) in malloc_consolidate() from /lib/libc.so.6. Expected results: The user should have been authenticated as customary for ssh, via the pam_krb5 or pam_unix modules. Obviously, the segfault in malloc_consolidate() should not occur. Additional info: The relevant error as reported when running sshd under GDB in debug mode (sshd's debug messages are prefixed with "debug3"): debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering Program received signal SIGSEGV, Segmentation fault. 0x40239e38 in malloc_consolidate () from /lib/libc.so.6 A backtrace at this point shows the following: #0 0x40239e38 in malloc_consolidate () from /lib/libc.so.6 #1 0x402395a5 in _int_malloc () from /lib/libc.so.6 #2 0x40238830 in malloc () from /lib/libc.so.6 #3 0x401ac6d2 in krb5_sendto_kdc () from /usr/kerberos/lib/libkrb5.so.3 #4 0x40195213 in krb5_get_renewed_creds () from /usr/kerberos/lib/libkrb5.so.3 #5 0x40196440 in krb5_get_init_creds () from /usr/kerberos/lib/libkrb5.so.3 #6 0x40197894 in krb5_get_init_creds_password () from /usr/kerberos/lib/libkrb5.so.3 #7 0x404f5a8f in pam_sm_authenticate () from /lib/security/../../lib/security/pam_krb5.so #8 0x40027c09 in pam_fail_delay () from /lib/libpam.so.0 #9 0x40027d93 in _pam_dispatch () from /lib/libpam.so.0 #10 0x400169b2 in pam_sm_chauthtok () from /lib/security/pam_stack.so #11 0x40015d1e in pam_sm_authenticate () from /lib/security/pam_stack.so #12 0x40027c09 in pam_fail_delay () from /lib/libpam.so.0 #13 0x40027d93 in _pam_dispatch () from /lib/libpam.so.0 #14 0x40029868 in pam_authenticate () from /lib/libpam.so.0 #15 0x0805439a in chroot () #16 0x0805469d in chroot () #17 0x08055119 in chroot () #18 0x0805f531 in chroot () #19 0x0805ed00 in chroot () #20 0x0805e9a5 in chroot () #21 0x0804d055 in chroot () #22 0x0804e1b4 in chroot () #23 0x401e15cd in __libc_start_main () from /lib/libc.so.6
Created attachment 93464 [details] GDB output for sshd (Red Hat Linux 9, openssh-server-3.5p1-6.9)
There are other open bugs about this as well... bug 101361 bug 101183 This one affects my workplace, so I'm keeping close tabs on it. :)
*** This bug has been marked as a duplicate of 101183 ***
On a Red Hat 7.3 server this is still an issue, tested with openssh-server- 3.1p1-14, the session is disconnected immediately after entering the user name. When using the root account, there is a time-out before the password dialog appears (behavior by design I believe). Tested on (two different servers) Red Hat 9.0 openssh-3.5p1-11, after entering the user account the password prompt never shows up (time out follows after a while). Root account behavior same as on the Red Hat 7.3 server.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.