openssh-server-5.6p1-26.fc15.x86_64 in default config, root users can login, but regular users can't. Setting: UsePrivilegeSeparation no lets everything work again. From the server: Accepted publickey for kevin from 10.1.1.1 port 54265 ssh2 debug1: monitor_child_preauth: kevin has been authenticated by privileged process mm_request_receive: read: Connection reset by peer debug1: do_cleanup debug1: temporarily_use_uid: 500/500 (e=0/0) debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism debug1: restore_uid: 0/0 debug1: SELinux support enabled debug1: PAM: establishing credentials User child is on pid 5450 debug1: PAM: establishing credentials debug1: permanently_set_uid: 500/500 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions want_reply 0 debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: session 0 debug1: getpeername: Socket operation on non-socket debug1: do_cleanup debug1: PAM: cleanup debug1: PAM: closing session debug1: PAM: deleting credentials debug1: session_pty_cleanup: session 0 release /dev/pts/3 syslogin_perform_logout: logout() returned an error debug1: audit_event: unhandled event 12 debug1: do_cleanup Non interactive sessions work fine, it's only interactive ones that hit this. Happy to provide more info or help debugging.
I think this bug is introduced in openssh-5.6p1-audit5.patch. The patch adds a function packet_destroy_all which is called in privsep_postauth. packet_destroy_all eventually calls packet_destroy_state, which zeros out active_state. However, mm_record_login eventually calls getpeername(packet_get_connection_in(), ...) which expects active_state->connection_in to be valid. I think this is what causes the getpeername error in the above log.
repaired in openssh-5.6p1-28, please test
Yep. I can confirm that it is fixed in that version. :) Thanks for the quick fix.
*** Bug 674633 has been marked as a duplicate of this bug. ***
openssh-5.6p1-28.fc15.x86_64 fixes it for me.