SSH, REQUIRES_PWCHANGE and policies problem

[Russ Allbery]

Andreas Ntaflos <daff at pseudoterminal.org> writes:
> On 2011-09-02 01:11, Russ Allbery wrote:

>> A workaround would be to set defer_pwchange in the PAM options, which I
>> believe ssh will handle correctly and which will restore control over
>> the messaging to the PAM module.  However, read the caveats for that
>> option in the pam_krb5 man page before using it.

> With defer_pwchange SSH indeed informs the user better but has the tiny
> usability issue that the old password needs to be entered twice, once
> for the SSH login and once for the password change. I can certainly live
> with this.

Ah, yes.  There isn't a good way to deal with that, I think, because the
password stack pulls the old password from a PAM data item that's not set
by the auth stack.  Hm.  Maybe the auth stack should store the user's old
password in OLDAUTHTOK if defer_pwchange was set.  I'll take a look at
that.

> But I am not sure I understand the caveats correctly. The man page says:
> "Due to the security risk of widespread broken applications, be very
> careful about enabling this option."

> Which are such broken applications? We use a shell server that does SSH
> and not much else where new users need to log in to change their
> generated default password. Users can then terminal-hop to other servers
> in our infrastructure. Is it safe to enable defer_pwchange there?

Yes, if the only application that's doing PAM authentication is ssh, it
should be fine.  There are screen savers that ignore the return status of
pam_acct_mgmt, and I'm sure there are other servers that use PAM to
process passwords (IMAP servers and the like), but if you're not running
anything other than ssh and login, I think you're safe.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>