Problems with PAM and PermitRootLogin without-password

Dan Yefimov dan at D00M.integrate.com.ru
Tue Nov 4 07:42:29 EST 2003


On Mon, 3 Nov 2003, Antonio Paulo Salgado Forster wrote:

> Hello all,
> 
> I was running some tests with openssh 3.7.1p2 and I noticed that
> PermitRootLogin without-password does not work when PAM is enabled. In
> fact, when PAM is enabled, PermitRootLogin will work as "yes" if  "
> without-password" is used, no matter what kind of authentication is used
> for root login.  Is that a bug,  I missed something in the configurations,
> or expected behavior? This is the output of a debugged session of ssh:
> 
> debug1: sshd version OpenSSH_3.7.1p2
> debug1: read PEM private key done: type RSA
> debug1: private host key: #0 type 1 RSA
> socket: Address family not supported by protocol
> debug1: Bind to port 80 on 0.0.0.0.
> Server listening on 0.0.0.0 port 80.
> debug1: Server will not fork when running in debugging mode.
> Connection from x.x.x.x port 2319
> debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1
> debug1: match: OpenSSH_3.4p1 pat
> OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
> debug1: permanently_set_uid: 74/74
> debug1: list_hostkey_types: ssh-rsa
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
> debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
> debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: KEX done
> debug1: userauth-request for user root service ssh-connection method none
> debug1: attempt 0 failures 0
> debug1: PAM: initializing for "root"
> debug1: PAM: setting PAM_RHOST to "x.x.x.x"
> debug1: PAM: setting PAM_TTY to "ssh"
> Failed none for root from x.x.x.x port 2319 ssh2
> Failed none for root from x.x.x.x port 2319 ssh2
> debug1: userauth-request for user root service ssh-connection method
> keyboard-interactive
> debug1: attempt 1 failures 1
> debug1: keyboard-interactive devs
> debug1: auth2_challenge: user=root devs=
> debug1: kbdint_alloc: devices 'pam'
> debug1: auth2_challenge_start: trying authentication method 'pam'
> Postponed keyboard-interactive for root from x.x.x.x port 2319 ssh2
> Postponed keyboard-interactive/pam for root from x.x.x.x port 2319 ssh2
> Accepted keyboard-interactive/pam for root from x.x.x.x port 2319 ssh2
> Accepted keyboard-interactive/pam for root from x.x.x.x port 2319 ssh2
> debug1: monitor_child_preauth: root has been authenticated by privileged
> process
> debug1: Entering interactive session for SSH2.
> debug1: server_init_dispatch_20
> debug1: server_input_channel_open: ctype session rchan 0 win 65536 max
> 16384
> debug1: input_session_request
> debug1: channel 0: new [server-session]
> debug1: session_new: init
> 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_channel_req: channel 0 request pty-req reply 0
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req pty-req
> debug1: Allocating pty.
> debug1: session_pty_req: session 0 alloc /dev/pts/1
> debug1: server_input_channel_req: channel 0 request shell reply 0
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req shell
> debug1: PAM: setting PAM_TTY to "/dev/pts/1"
> debug1: PAM: establishing credentials
> debug1: Setting controlling tty using TIOCSCTTY.
> debug1: Received SIGCHLD.
> debug1: session_by_pid: pid 17636
> debug1: session_exit_message: session 0 channel 0 pid 17636
> debug1: session_exit_message: release channel 0
> debug1: session_close: session 0 pid 17636
> debug1: session_pty_cleanup: session 0 release /dev/pts/1
> debug1: channel 0: free: server-session, nchannels 1
> Connection closed by x.x.x.x
> Closing connection to x.x.x.x
> debug1: PAM: cleanup
> 
This is not a bug. According to the manual of an earlier version enabling PAM 
support may bypass setting of 'PasswordAuthentication' parameter. When you set 
'PermitRootLogin without-password', you only disable password authentication for 
root, but keyboard-interactive authentication uses PAM. Depending on your PAM 
configuration this can lead to requesting the password from user being 
authenticated. To prevent this from happening I'd suggest you to disable 
challenge-response authentication because enabling it inherently enables 
keyboard-interactive authentication which is by default disabled.
-- 

    Sincerely Your, Dan.




More information about the openssh-unix-dev mailing list