[PATCH] Password expiry with Privsep and PAM

[William R. Knox]

I can certainly see the use in forcing a password change no matter what
the access method - it becomes the only way to enforce password aging if
people use keys (password aging being a requirement for some security
audits). If I reset a password and require that it be changed, I don't
want the person to be able to log in without changing it.

			Bill Knox
			Senior Operating Systems Programmer/Analyst
			The MITRE Corporation

On Wed, 11 Dec 2002, Darren Tucker wrote:

> Date: Wed, 11 Dec 2002 06:50:36 +1100
> From: Darren Tucker <dtucker at zip.com.au>
> To: Ben Lindstrom <mouring at etoh.eviladmin.org>
> Cc: Jan-Frode Myklebust <janfrode at parallab.no>,
>      OpenSSH Devel List <openssh-unix-dev at mindrot.org>
> Subject: Re: [PATCH] Password expiry with Privsep and PAM
>
> Ben Lindstrom wrote:
> > On Tue, 10 Dec 2002, Jan-Frode Myklebust wrote:
> [snip]
> > > Unfortunately I haven't found any AIX library calls that helps here, so I
> > > think OpenSSH will have to implement these rules, or use the systems
> > > /bin/passwd which should do the right thing. BTW: why isn't the patch
> > > using /bin/passwd ?
> >
> >  /bin/passwd can be used for v1, but if one is to honor v2 specs password
> > change must be done before the interactive shell is started so it makes it
> > harder to handle password change via /bin/passwd unless you can come up
> > with a clean silver bullet that passes all information back to the user no
> > matter how badly written/formated the /bin/passwd is.
>
> As Ben said, using /bin/passwd in v2's (pre-session) PASSWD_CHANGEREQ
> requires writing expect-like functionality that would be very hard to
> get right across all platforms.
>
> > I know Darren wrote one to use /bin/passwd but after we both looked at it
> > we pretty much decided it was not something we wanted to handle, but the
> > more I think about this.. the more I'm starting to agree with Markus.  No
> > matter the additional risks of changing passwords after the tty for v1 and
> > v2 has been open it should be done that way.  This is just getting way to
> > complex to even manage in my head.
>
> Ironically, this is more or less where I started a couple of months ago
> on AIX.
>
> I posted a multi-platform patch along these lines a couple of weeks ago:
> http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103780221504047&w=2
> If you want me to rework it, let me know what needs changing (eg the
> port forward restrictions).
>
> Do we do away with do_pam_chauthtok too?  It does almost the same thing
> as /bin/passwd.
>
> > Then we just block non-interactive sessions with 'must change password'
> > commentary  (Public keys?!?).
>
> Good point. Can you justify forcing a password change if the password
> isn't used in the login? Maybe just a warning?
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>