[Bug 147] New: ssh dies if it gets SSH_MSG_USERAUTH_PASSWD_CHANGEREQ

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=147

           Summary: ssh dies if it gets SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
           Product: Portable OpenSSH
           Version: 3.0p1
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P4
         Component: ssh
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: Darren.Moffat at Sun.COM


This was discovered while testing against Vandyke at Connectathon 2002.

The protocol requires that both the client and server understand that passwords
can expire. A server can send to the client SSH_MSG_USERAUTH_PASSWD_CHANGEREQ,
if the users password has expired 

draft-ietf-secsh-userauth-15.txt: Section 5 says:

   Normally, the server responds to this message with success or
   failure.  However, if the password has expired the server SHOULD
   indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
   In anycase the server MUST NOT allow an expired password to be used
   for authentication.

OpenSSH sshd is compilant with MUST NOT part but doesn't do the SHOULD.  If PAM
is used on platforms that support it then the correct thing happens since
pam_chauthtok is run later on and if that fails the session is disconnected
using fatal(). This doesn't need to be changed but it would be nice if it
worked as per the draft.  Similarly A client may also send a new password in the 
SSH2_MSG_USERAUTH_REQUEST, OpenSSH's sshd current ignores this and log's not 
supported.

Currently an OpenSSH client receiving SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ from
a server will die because that packet is not expected.

I have a partial solution for the client side support of recieving a
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ but it needs further testing and cleanup.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.