SSH, REQUIRES_PWCHANGE and policies problem

[Andreas Ntaflos]

On 2011-09-02 01:11, Russ Allbery wrote:
> The problem from SSH's perspective is that since it's doing an
> authentication, not a password change, it doesn't know that the password
> change failed.  All that PAM can tell it is that the authentication
> failed, not why (in this case a forced and failed password change).  So it
> starts the authentication over again, which just presents a new password
> change prompt again.
> 
> But even if ssh knew it was a failed password change, it wouldn't know
> why.  What you need is for the agent that's attempting the password change
> to tell the user the error message that it got back from the password
> change service.  The Kerberos library has that information; I'm not sure
> how it handles it.

I see, thanks for explaining. I don't think anything can be done about
this now.

> 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.

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?

>> I don't know anything about the Kerberos library internals but when
>> using the normal "passwd" program with the PAM stack described in my
>> previous message I indeed get informed of the policy violation:
> 
> This is a much different case, since this calls the password change
> functionality directly and therefore the PAM module is in control of all
> the prompting and gets the error message itself.  It's an entirely
> different code path than forced password change during initial
> authentication.

Ok, I thought so, thanks for explaining, again :)

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20110902/5db6aee0/attachment.bin