Andreas Ntaflos <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
