>Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account using the >'passwd -l ...' command to lock the users password. However, the user can >still access the system via ssh. Whilst I could do other things such as >moving their .ssh directory, removing their account home directory, etc, >etc, is there some 'nicer' way to inform ssh that the account is now locked >and thus to not allow them to login?The pam_unix.so module doesn't check for *LK* in pam_acct_mgmt since it was assuming that pam_authenticate() had been called already - in those cases it would fail. If however you are using publickey authentication rather than going through PAM with a password pam_acct_mgmt is called without first going to pam_authenticate(). This has been fixed in the new pam modules for Solaris 9 where pam_unix_account.so does an explicit check for *LK* so it is now safe to call pam_acct_mgmt() if pam_authenticate() wasn't called. I would say that this is a bug in pam_unix.so on Solaris 2.6 onwards, you should log a call with Sun Enterprise Services. I would recommend stating the bug as follows: pam_sm_acct_mgmt() in pam_unix.so.1 does not check for the users password being the lockstring (*LK*). This has already been fixed in Solaris 9 pam_unix_account.so and I would like a similar fix applied to pam_unix.so.1 for Solaris 7 onwards. -- Darren J Moffat
I do still see this behavior on Linux as well though. What is the list recommendation for that case, if any? On Wed, 2002-05-22 at 15:12, Darren Moffat wrote:> >Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account > using the > >'passwd -l ...' command to lock the users password. However, the > user can > >still access the system via ssh. Whilst I could do other things > such as > >moving their .ssh directory, removing their account home directory, > etc, > >etc, is there some 'nicer' way to inform ssh that the account is > now locked > >and thus to not allow them to login? > > The pam_unix.so module doesn't check for *LK* in pam_acct_mgmt since > it > was assuming that pam_authenticate() had been called already - in > those > cases it would fail. If however you are using publickey > authentication > rather than going through PAM with a password pam_acct_mgmt is > called > without first going to pam_authenticate(). > > This has been fixed in the new pam modules for Solaris 9 where > pam_unix_account.so does an explicit check for *LK* so it is now > safe > to call pam_acct_mgmt() if pam_authenticate() wasn't called. > > I would say that this is a bug in pam_unix.so on Solaris 2.6 > onwards, > you should log a call with Sun Enterprise Services. I would > recommend > stating the bug as follows: > pam_sm_acct_mgmt() in pam_unix.so.1 does not check for the > users > password being the lockstring (*LK*). This has already been > fixed > in Solaris 9 pam_unix_account.so and I would like a similar > fix > applied to pam_unix.so.1 for Solaris 7 onwards. > > -- > Darren J Moffat-- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020523/f4b7f450/attachment.bin
On Wed, May 22, 2002 at 01:12:07PM -0700, Darren Moffat wrote:> >Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account using the > >'passwd -l ...' command to lock the users password. However, the user can > >still access the system via ssh. Whilst I could do other things such as > >moving their .ssh directory, removing their account home directory, etc, > >etc, is there some 'nicer' way to inform ssh that the account is now locked > >and thus to not allow them to login? > > The pam_unix.so module doesn't check for *LK* in pam_acct_mgmt since it > was assuming that pam_authenticate() had been called already - in those > cases it would fail. If however you are using publickey authentication > rather than going through PAM with a password pam_acct_mgmt is called > without first going to pam_authenticate(). > > This has been fixed in the new pam modules for Solaris 9 where > pam_unix_account.so does an explicit check for *LK* so it is now safe > to call pam_acct_mgmt() if pam_authenticate() wasn't called.What else is special besides "*LK*" (I'm wondering about "NP")? How exactly does ``passwd -sa'' determine LK status? Are there issues with/without /etc/shadow (I see pwconv(1M) for example)?
>What else is special besides "*LK*" (I'm wondering about "NP")?*LK* is explicitly checked for in pam_unix_account in S9. NP is used for some of the default accounts - I need to work out why (I think it is just history) they use NP rather than *LK*.>How exactly does ``passwd -sa'' determine LK status? Are there >issues with/without /etc/shadow (I see pwconv(1M) for example)?I've just discovered that passwd -sa is a tad broken - I'll log a bug and get it fixed. If there is no password it prints NP else if password filed is non zero but less than 13 print LK else print PS (meaning there is a password). -- Darren J Moffat