[Bug 2796] sshd should allow clients to explicitly request the password change

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Thu Nov 16 00:24:40 AEDT 2017


Tomas Mraz <t8m at centrum.cz> changed:

           What    |Removed                     |Added
                 CC|                            |t8m at centrum.cz

--- Comment #8 from Tomas Mraz <t8m at centrum.cz> ---
(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.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

More information about the openssh-bugs mailing list