openssh bugs - Oct 2017 - [Bug 2796] New: sshd should allow clients to explicitly request the password change

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

            Bug ID: 2796
           Summary: sshd should allow clients to explicitly request the
                    password change
           Product: Portable OpenSSH
           Version: 7.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: z.pekar at gmail.com

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!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

ab231 <z.pekar at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |z.pekar at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
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.

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> ---
(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.

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

--- Comment #3 from ab231 <z.pekar at gmail.com> ---
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..)?

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

--- Comment #4 from Darren Tucker <dtucker at zip.com.au> ---
(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.

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

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

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

--- Comment #6 from Darren Tucker <dtucker at zip.com.au> ---
(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?

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

--- Comment #7 from Darren Tucker <dtucker at zip.com.au> ---
(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).

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=2796

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.