[PATCH] Password expiry with Privsep and PAM

Darren Tucker dtucker at zip.com.au
Wed Dec 11 10:24:34 EST 2002

Peter Stuge wrote:
> On Wed, Dec 11, 2002 at 06:50:36AM +1100, Darren Tucker wrote:
> > 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.
> Would it really?

In my opinion, yes.  Feel free to prove me wrong.  You might want to
start with my crude implementation of it:


> Remember that this project has a lot of good people coming
> from different platforms.  Also keep in mind that the PASSWD_CHANGEREQ
> protocol is the single smallest denominator, severly limiting what needs to
> be supported.  I'm thinking all that can be expected is for sshd to handle
> cases where passwd wants either the old or the new password, sshd doesn't
> have any other information at that time and no real way to get any either,
> unless the protocol is extended, right?

I think you're underestimating the amount of weirdness out there hiding
in /bin/passwd. Consider this example from HP-UX in a trusted

trustedhpux# passwd testuser
Changing password for testuser
Last successful password change for testuser: NEVER 
Last unsuccessful password change for testuser: Tue Dec 10 23:06:13 2002

Do you want (choose one letter only): 
        pronounceable passwords generated for you (g) 
        a string of letters generated (l) ?
        to pick your passwords (p) ?

Enter choice here: p
New password: 
Password too short - must be at least 6 characters
New password: 
Password must contain at least two alphabetic characters and
at least one numeric or special character.
New password: 
Re-enter new password: 
Passwd successfully changed

> Two scenarios become possible:
> 1. openssh implements all neccessary local password changing stuff - PITA
> overhead but when done a lot lower "instance" overhead, the PASSWD_CHANGEREQ
> becomes more lightweight.  However, openssh might have to deal with vendor
> quux's broken system yet another time.
> 2. openssh uses passwd because of law of least resistance, this is the
> simplest path to go.  When vendor xyzzy ends up having a passwd that
> requires more capabilities than sshd has while in PASSWD_CHANGEREQ they can
> either fix their passwd or try to convince us that we should switch to (1).

Having had a go at implementing both, I think (2) will end up bigger,
uglier and flakier that the sum of (1).

> Set up an easy scheme to add support for platforms with (2) and I think it'd
> happen pretty quickly.

What you're talking about is implementing a subset of "expect". For
comparison oldest, smallest expect I could find is still a couple of
hundred KB compressed.

Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

More information about the openssh-unix-dev mailing list