Bug 674443 - openssh in rawhide doesn't allow regular user logins
openssh in rawhide doesn't allow regular user logins
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan F. Chadima
Fedora Extras Quality Assurance
:
: 674633 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-01 17:08 EST by Kevin Fenzi
Modified: 2011-02-03 05:57 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-02 04:28:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kevin Fenzi 2011-02-01 17:08:52 EST
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@openssh.com 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.
Comment 1 Ricky Zhou 2011-02-01 19:43:21 EST
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.
Comment 2 Jan F. Chadima 2011-02-02 04:28:24 EST
repaired in openssh-5.6p1-28, please test
Comment 3 Kevin Fenzi 2011-02-02 11:17:07 EST
Yep. I can confirm that it is fixed in that version. :) 

Thanks for the quick fix.
Comment 4 Tomas Mraz 2011-02-02 15:49:28 EST
*** Bug 674633 has been marked as a duplicate of this bug. ***
Comment 5 Richard W.M. Jones 2011-02-03 05:57:04 EST
openssh-5.6p1-28.fc15.x86_64 fixes it for me.

Note You need to log in before you can comment on or make changes to this bug.