LinuxPAM and sshd: changing conversation function doesn't work but claims to.

[Darren Tucker]

Hi.
	I'm one of the OpenSSH developers, and I've done some of the work on 
sshd's PAM interface recently.

	I've discovered some behaviour peculiar to LinuxPAM that I can't 
explain: changing the conversation function does not appear to work, 
even though the pam_set_item() call claims to succeed.  The previous 
conversation function is still called.

	Background: the PAM API is a poor fit for the SSH protocol, so the 
conversation function needs to do vastly different things at different 
points in the protocol.  Instead of one enormous multi-mode  function, 
sshd has what is probably a record number of different conversation 
functions (5, in the current development versions).

	One of these is a fairly generic "tty_conv" that interacts with the 
user directly on stdin/stdout and /dev/tty.  Since the user doesn't get 
a pty until quite late in the login process, this function is only used 
for pam_chauthtok() in some cases, and always after sshd has forked to 
set up for the user's shell.

	The code for the chauthtok looks like this (from OpenSSH 3.8.1p1's 
do_pam_chauthtok() in auth-pam.c):


   static struct pam_conv tty_conv = { pam_tty_conv, NULL };
[...]
   sshpam_err = pam_set_item(sshpam_handle, PAM_CONV,
           (const void *)&tty_conv);
   if (sshpam_err != PAM_SUCCESS)
           fatal("PAM: failed to set PAM_CONV: %s",
                 pam_strerror(sshpam_handle, sshpam_err));
   debug("PAM: changing password");
   sshpam_err = pam_chauthtok(sshpam_handle, PAM_CHANGE_EXPIRED_AUTHTOK);


	The conversation functions also have a debug() at the start announcing 
that they've been called and the number of messages passed.

	If I run the server[1] in debug mode with PAM enabled and privilege 
separation off, and connect with SSHv1 with an account that has an 
expired password, the code above will be called, and the debug messages 
will be sent to the client (since stdin/stdout is connected to the pty). 
  Here's the output from the client:

Password:
Response:
debug1: PAM: changing password
debug3: PAM: sshpam_null_conv entering, 2 messages
PAM: pam_chauthtok(): Authentication token manipulation error
debug1: do_cleanup
Connection to localhost closed.

	Despite pam_set_item claiming to succeed (it must have returned 
PAM_SUCCESS otherwise fatal() would have been called), tty_conv is *not* 
called by PAM, the previous conversation function is (which replies 
immediately with PAM_CONV_ERR and thus the pam_chauthtok fails).

	This is a Redhat 9 box with pam-0.75-48.  Similar behaviour has also 
been observed on Debian.  The same sshd code works OK on several other 
PAM platforms.

	I have not been able to replicate this behaviour in a minimal test 
case, but I'm hoping someone will be able to explain it.

	Thanks,
		-Daz.

[1] To reproduce with OpenSSH 3.8.1p1 built with PAM enabled:
# ./sshd -ddd -p 2022 -oUsePAM=yes -oUsePrivilegeSeparation=no
# ssh -1 -p 2022 testuser at localhost

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.