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@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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
