[Bug 423] Workaround for pw change in privsep mode (3.5.p1)

[Frank Cusack]

On Fri, Nov 08, 2002 at 11:00:05AM +0100, Michael Steffens wrote:
> Darren Tucker wrote:
> > Michael Steffens wrote:
> > 
> >>And, if the PAM stack for sshd is really configured to prompt for
> >>multiple different passwords, authentication will always fail...
> > 
> > 
> > So by rights, PAM authentication should always be done via
> > keyboard-interactive? If you do that, you can throw the pam_chauthok
> > stuff in there too?
> >
> 
> Yes and no :)

Just yes, really.  The PAM framework demands the type of exchange that
only keyboard-interactive offers.  The way the "password" authentication
method interacts with PAM is a kludge.

> If keyboard-interactive would work in privsep mode (it doesn't, at
> least for me)

It does not because PAM in general requires root privs and in privsep
mode the PAM code runs in the unpriv part.  The correct fix IMHO is
to move the PAM code into the priv part.  I don't know if this is
feasible, but from a security standpoint should be pretty good.  The
PAM code is a small part to look at and any bugs are going to be in
the PAM libs, not openssh.

> and if it would be also available for protocol 1, which it isn't,

Not so fast there. :-)  Look in the bugs db for a TISviaPAM patch.  This
uses the ssh1 TIS auth method to do the same thing that kbdint does.

> it could be the general PAM authentication channel.
> 
> But it's main purpose (may be wrong there) seems to be providing a
> full PAM conversation to the client without a local TTY, analogously
> to the INITIAL_LOGIN mode with do_pam_conversation().
> 
> For pam_chauthok() this is not relevant, because it is to be called
> after successful authentication with session and TTY established.

Not necessarily.

PAM has two ways to make you change your password (during authentication).

1) in the call to pam_authenticate(), the module can determine that your
   password is expired and force a password change.
2) in the call to pam_acct_mgmt(), the module can determine that your
   password is expired and return PAM_AUTHTOK_EXPIRED.  Then the application
   must drive the password change.  In ssh, all of this would (could) happen
   during the "single" kbdint exchange.

I don't think (1) is likely.  During (2), it's up to the app to call
pam_chauthtok().  In openssh, this would happen while still in the
authentication exchange.

> So I doubt that keyboard-interactive is the appropriate place to
> throw pam_chauthok in.

It is the correct place.

But it still won't work with privsep on.  The PAM code needs to run
privileged.

/fc