sshd should allow clients to explicitly request the password change, as written here ( https://winscp.net/eng/docs/task_change_password ): "SSH protocol allows changing an account password. But many SSH servers, notably the OpenSSH, does not actually allow that." While it is less important for ssh sessions, because passwd command can be used - it is crucial for the cases when users can login only with sftp clients (and are denied shell access). In such situations there is now way for a client to initiate a password change. If you decide to implement this - sftp client should be enhanced as well to allow explicitly request the password change. Thank you!
I spent a long time looking into this a long time ago (bug #14!). The SSH protocol has a mechanism for this called SSH_MSG_USERAUTH_PASSWD_CHANGEREQ (RFC 4252 section 8). Unfortunately I know of no usable standard interface that implements the required semantics. I've looked at: - PAM. pam_chauthtok() requires that it can interact directly with the user, but during PASSWD_CHANGEREQ it can't. You could potentially have a blind conversation function that responds, but it could be getting "enter new password" twice, maybe with "enter old password" before that. It could even be asking "enter message to be broadcast to all users" for all it knows. It does use this during keyboard-interactive when it can interact. - execing /bin/passwd. That's what it does when it gets to a tty and your password is still expired. - directly manipulating password files. There's lots of problems with this. While getpwent and friends provide a standard way to read them, there's no equivalent standard API for writing them. The files and their formats vary by platform (eg passwd, shadow, master.passwd and probably others), and even if you could this would not implement the system's password complexity rules. I did consider wrapping /bin/passwd somehow but that would be fragile. - some platforms-specific interfaces. The only one I recall is AIX's putuserpw() which would actually work, but I don't know of any others offhand.
(In reply to ab231 from comment #0) > If you decide to implement this - sftp client should be enhanced as > well to allow explicitly request the password change. sftp invokes ssh(1) and that already implements the required logic: https://github.com/openssh/openssh-portable/blob/master/sshconnect2.c#L934 The problem is implementing it reliably on the server side.
Hi Darren, and thank you for the quick response! So will you give it a try with the ideas you've listed (PAM and/or AIX, etc..)?
(In reply to ab231 from comment #3) > So will you give it a try with the ideas you've listed (PAM and/or > AIX, etc..)? No, I've already tried them (the attempts are at https://www.dtucker.net/openssh/old.html). pam_chauthtok() is not reasonably/reliably usable in the way you ask and the AIX interface or something similar is not widely available enough to make it worthwhile implementing support for.
The only mechanism that could be fairly reliable but convoluted and not completely universal would be to have some special PAM module - let's call it pam_ssh_authtok. The admin would be required to add the module as the first one into the password PAM stack. This module would get the new password from the sshd either via the conversation function or via some other out of band mechanism. Then it would set the PAM_AUTHTOK (and maybe also PAM_OLDAUTHTOK). Following PAM modules in the stack would then do the actual password change.
(In reply to Tomas Mraz from comment #5) > The only mechanism that could be fairly reliable but convoluted I could imagine that working if all went well (although it assumes more support from the platform than I could reasonably assume) but how would it work in the case were the client's proposed new password does not comply with the system's password policy?
(In reply to Tomas Mraz from comment #5) > from the sshd either via the conversation function This is problematic for the reason I described above: at the required point in the protocol there's no mechanism to interact with the user, so the conversation function would have to make (possibly unwarranted) assumptions about what each prompt means. > or via some other out of band mechanism. Then it would set > the PAM_AUTHTOK (and maybe also PAM_OLDAUTHTOK). I'd love for sshd be able to set PAM_AUTHTOK and PAM_OLDAUTHTOK via pam_set_item() but by my read of the original RFC the're not exposed to applications and a quick test with LinuxPAM backs this up. (aside: it seems like they don't even exist in the XSSO spec because they're misspelled: http://pubs.opengroup.org/onlinepubs/008329799/pam_set_item.htm#tagcjh_07_18).
(In reply to Darren Tucker from comment #6) > (In reply to Tomas Mraz from comment #5) > > The only mechanism that could be fairly reliable but convoluted > > I could imagine that working if all went well (although it assumes > more support from the platform than I could reasonably assume) but > how would it work in the case were the client's proposed new > password does not comply with the system's password policy? If the password did not comply, the password change would fail. Sshd would have to check the pam_chauthtok return value and terminate the connection. Again, it would not be perfect. (In reply to Darren Tucker from comment #7) > (In reply to Tomas Mraz from comment #5) > > from the sshd either via the conversation function > > This is problematic for the reason I described above: at the > required point in the protocol there's no mechanism to interact with > the user, so the conversation function would have to make (possibly > unwarranted) assumptions about what each prompt means. The special PAM module would have to put something somewhat unique to the prompt and the sshd conversation function would have to recognize it. Any non-recognized queries would mean failure or fallback to the old exec passwd mechanism. Ugly, I know. > > > or via some other out of band mechanism. Then it would set > > the PAM_AUTHTOK (and maybe also PAM_OLDAUTHTOK). > > I'd love for sshd be able to set PAM_AUTHTOK and PAM_OLDAUTHTOK via > pam_set_item() but by my read of the original RFC the're not exposed > to applications and a quick test with LinuxPAM backs this up. Yes, these would be set by a special pam module that would be required in the stack for the mechanism to work. Again ugly.