5.1p on RHEL 3 and password expiration

[Darren Tucker]

Stephen Harris wrote:
> [ Sorry for the length of this; I felt it better to provide potentially
>   too much info, rather than not enough.  I've probably missed something
>   that's important, though! ]
> 
> I have an odd problem with 5.1p on RHEL3 if "UsePAM yes" and
> "UsePrivilegeSeparation no" is set.  The code detects that the user
> password is aged (according to shadow) but then fails to let me change
> the password:
> 
[...]
> If I do "UsePAM no" _or_ "UsePrivilegeSeparation yes" then the password
> change process works...

This works because the password change is done by invoking 
/usr/bin/passwd, rather than by calling pam_chauthtok (the latter won't 
work in this case because when UsePrivilegeSeparation=yes, we have long 
since given up root privs).

[...]
> The error message received looks very similar to a problem Darren had
> with LinuxPAM back in 2004 about setting the conversation, but I can't
> find if this was ever resolved
>   http://osdir.com/ml/pam/2004-06/msg00028.html

I think this was fixed in later versions of LinuxPAM but I also suspect 
the fix was never backported.

You can check with the testcase I posted back then (which passes on my 
fedora 8 box):
http://www.zip.com.au/~dtucker/openssh/wrong-conv-function.c

> Of course the RedHat provided OpenSSH3.6 package (with their gazillion
> patches) works just fine; allows the password to be changed and doesn't
> force a logout/login again.
> 
> Any ideas?

You could disable PasswordAuthentication and require Protocol 2 with 
keyboard-interactive authentication, which will probably work since it 
does both authentication and password change through the same 
conversation function).

> I'm trying to standardise on a single version of OpenSSH over
> all my platforms (Solaris 8,9,10, RHEL 2.1,3,4) and people are looking
> at me pretty funny when my replacement package can't perform as well as
> the OS provided one!  (Of course it works fine on RHEL2.1, RHEL4 and
> Solaris, but we have a large RHEL3 footprint)

It would be possible to hack around in sshd, however I don't think it's 
worth the effort since it's demonstrably a (since fixed) LinuxPAM bug.

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