Support for RFC4252 in sshd with PAM

[d***@infracentric.com]

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

[Darren Tucker]

Post by d***@infracentric.com
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).

[d***@infracentric.com]

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=***@mindrot.org> On
Behalf Of Darren Tucker
Sent: 29 September 2018 01:09
To: ***@infracentric.com
Cc: OpenSSH Devel List <openssh-unix-***@mindrot.org>
Subject: Re: Support for RFC4252 in sshd with PAM

Post by d***@infracentric.com
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.