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

Darren Tucker
Tue, 28 Dec 2004 17:39:26 -0000

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.


_______________________________________________
Pam-list mailing list
Pam-list at redhat.com