ssh daemon fails to call pam when user does not exist in /etc/passwd

[Darren Tucker]

Damien Mascord wrote:
> It was in my unpatched sshd_config, but wasn't present in the (patched) 
> /usr/local/etc version.  Thanks for the heads up.
> 
> With or without the patch, I am able to login correctly.  It seems as 
> though a restart of ssh was needed to enable the new NSS methods for 
> some reason.  Not sure what the cause of the issue was, if I notice it 
> on a new installation, I will try and narrow this down, thanks for your 
> help.

Probably picked up at initialisation time by libc and not checked again.

> Since this is the case, I am assuming that PAM is required if alternate 
> NSS methods are in use ?   Is there any way around this?

Provide getpwnam and friends behave as sshd expects (ie the same as for 
a local account), no, PAM should not be required.  In your case, sshd 
thinks the account is expired because sp_expire == 0 (which sshd 
considers to mean that your account expired some time in 1970 :-), 
whereas sshd expects "-1" if account expiry is disabled.

It might be reasonable to check for zero too, *provided* that does not 
have a special meaning on some platform.  (sp_lstchg == 0 is used on 
many platforms to indicate a root-forced password change, but I don't 
know if sp_expire is used for something similar).

-- 
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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-shadow-zeroexpire.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040705/62576adc/attachment.ksh