RE: Support for RFC4252 in sshd with PAM

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxxxx> On
Behalf Of Darren Tucker
Sent: 29 September 2018 01:09
To: david.hubbard@xxxxxxxxxxxxxxxx
Cc: OpenSSH Devel List <openssh-unix-dev@xxxxxxxxxxx>
Subject: Re: Support for RFC4252 in sshd with PAM

On Fri, 28 Sep 2018 at 23:34, <david.hubbard@xxxxxxxxxxxxxxxx> 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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux