david.hubbard at infracentric.com
2018-Sep-28 13:23 UTC
Support for RFC4252 in sshd with PAM
Hi I'm trying to integration a Java application using SSHJ <https://github.com/hierynomus/sshj> client-side - into OpenSSH 7.4. This is fine, except where I get to a password expiry situation. Looking at RFC4252 <https://www.ietf.org/rfc/rfc4252.txt> (which is supported by SSHJ) I don't see any SSH_MSG_USERAUTH_PASSWD_CHANGEREQ [60] messages getting passed from OpenSSH. SSHJ expects these to allow prompting for new password. The only references to SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ in the OpenSSH Portable code are in "sshconnect2.c" - which I believe is client-side. So is RFC4252 supported for sshd (server-side) ? I have compiled OpenSSH Portable <https://github.com/openssh/openssh-portable> (v 7.8) on Centos 7 (using PAM) and got into debug mode In sshd_config I have UsePAM yes PasswordAuthentication yes ChallengeResponseAuthentication no AuthenticationMethods password I can see two phases where authentication is applied - the first. debug3: mm_request_receive entering debug1: do_pam_account: called debug2: do_pam_account: auth information in SSH_AUTH_INFO_0 debug3: PAM: sshpam_passwd_conv called with 1 messages debug3: PAM: do_pam_account pam_acct_mgmt = 12 (Authentication token is no longer valid; new one required) debug3: sshpam_password_change_required 1 debug3: mm_request_send entering: type 103 Accepted password for dhubbard2 from 192.168.13.1 port 50263 ssh2 debug1: monitor_child_preauth: dhubbard2 has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 26 debug3: mm_request_receive entering debug3: mm_get_keystate: GOT new keys debug3: mm_auth_password: user authenticated [preauth] However all I can see from the "password_change_required" is code in auth-pam.c to set the auth token to PAM_CHANGE_EXPIRED_AUTHTOK, but no RFC4252 style communication. Then later. debug2: ## DH: userauth_finish [preauth] debug3: auth2_update_methods_lists: updating methods list after "password" [preauth] debug2: authentication methods list 0 complete [preauth] debug2: ## DH: about to do_pam_account [preauth] debug3: mm_do_pam_account entering [preauth] debug3: mm_request_send entering: type 102 [preauth] debug3: mm_request_receive_expect entering: type 103 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_do_pam_account returning 1 [preauth] debug2: ## DH: done do_pam_account - no message [preauth] debug3: send packet: type 52 [preauth] i.e. no recognition of the expiry and no comms. Am I missing something - like a config setting? Thanks in advance David
On Fri, 28 Sep 2018 at 23:34, <david.hubbard at infracentric.com> wrote:> Looking at RFC4252 <https://www.ietf.org/rfc/rfc4252.txt> (which is > supported by SSHJ) I don't see any SSH_MSG_USERAUTH_PASSWD_CHANGEREQ [60] > messages getting passed from OpenSSH. SSHJ expects these to allow prompting > for new password. > > The only references to SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ in the OpenSSH > Portable code are in "sshconnect2.c" - which I believe is client-side.Correct. The problem is that the semantics of password changing via PASSWD_CHANGEREQ ("here's the old password and new password, make it so") can't be implemented with PAM's interface ("I'll send you arbitrary messages and you send me arbitrary replies until I'm happy"). It is possible using the keyboard-interactive method (RFC4256) and PAM password changing is implemented there. I experimented with various password expiry handling methods in the past and ultimately gave up on PASSWD_CHANGEREQ. There is to my knowledge no standard or common API that can implement the change part (short of implementing everything including things like password history and complexity rules yourself, all of which are system specific). -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
david.hubbard at infracentric.com
2018-Sep-30 12:56 UTC
Support for RFC4252 in sshd with PAM
Darren hi Thanks - that assures me that I wasn't missing something obvious. Plus your reasoning makes perfect sense - I was starting to wonder what I'd need to implement client-side to handle if/when I managed to get a PASSWD_CHANGEREQ response - e.g. complexity, dictionary and previous password checks - all of which (as you say) are system specific and should be defined server-side from an admin POV. If the spec was open for input/revision (probably one for others) I might be suggesting that the expiry interchange mechanism should be defined at a more granular level (e.g. number of password user entries, success/fail feedback, max number of retries) As the SSHJ library has session based support, I believe I can add some handling to work with the "passwd" functionality at the command line level, which the SSH session drops into on password expiry. For ref: the SSHJ ticket I raised on this is at https://github.com/hierynomus/sshj/issues/453. Thanks again David -----Original Message----- From: openssh-unix-dev <openssh-unix-dev-bounces+david.hubbard=infracentric.com at mindrot.org> On Behalf Of Darren Tucker Sent: 29 September 2018 01:09 To: david.hubbard at infracentric.com Cc: OpenSSH Devel List <openssh-unix-dev at mindrot.org> Subject: Re: Support for RFC4252 in sshd with PAM On Fri, 28 Sep 2018 at 23:34, <david.hubbard at infracentric.com> wrote:> Looking at RFC4252 <https://www.ietf.org/rfc/rfc4252.txt> (which is > supported by SSHJ) I don't see any SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > [60] messages getting passed from OpenSSH. SSHJ expects these to > allow prompting for new password. > > The only references to SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ in the > OpenSSH Portable code are in "sshconnect2.c" - which I believe isclient-side. Correct. The problem is that the semantics of password changing via PASSWD_CHANGEREQ ("here's the old password and new password, make it so") can't be implemented with PAM's interface ("I'll send you arbitrary messages and you send me arbitrary replies until I'm happy"). It is possible using the keyboard-interactive method (RFC4256) and PAM password changing is implemented there. I experimented with various password expiry handling methods in the past and ultimately gave up on PASSWD_CHANGEREQ. There is to my knowledge no standard or common API that can implement the change part (short of implementing everything including things like password history and complexity rules yourself, all of which are system specific). -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev