Account in /etc/passwd but not /etc/shadow

jeriryan · 07-18-2011, 02:21 PM

I have an account in /etc/passwd with two exclamation points on it:
user:!!:...From what I understand, the !!'s mean that the password is in /etc/shadow. But there is no entry in /etc/shadow for that username. So my question is, is this account essentially locked out for login since no password is in /etc/shadow? I've tried logging in without entering a password and am unable to, but I don't think that is an exhaustive test. I'm not trying to fix it, just want to know if the account is essentially not "login-able" in it's current state.

T3RM1NVT0R · 07-18-2011, 02:44 PM

Hi there,

Not sure how two !! came in /etc/passwd. I have never seen that in /etc/passwd but I have seen one ! in /etc/shadow which denotes that the account is locked.

As you said that account is not in /etc/shadow which is quite unusual. To be sure what you can do is disable the user login by editing /etc/passwd and putting nologin as follows:

test:x:1002:1002::/home/test:/bin/nologin

And you cannot login without password using any user account. An account is considered as locked if it does not have any password if I am not wrong.

tommylovell · 07-18-2011, 03:08 PM

To add to what T3RM1NVT0R said, 'x' denotes an entry is in the shadow file. See 'man -s 5 passwd' and 'man -s 8 pwconv'.

An '*' in the /etc/passwd entry prevents login, too. As does '!' and '!!'.

Code:

[root@athlon ~]# grep tommy /etc/passwd
tommy:*:500:100:tommy:/home/tommy:/bin/bash

[root@athlon ~]# ssh -l tommy localhost 
The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is 01:18:92:02:cb:1b:85:c6:16:1a:6a:93:d5:1e:1f:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
tommy@localhost's password: 
Permission denied, please try again.
tommy@localhost's password: 
Permission denied, please try again.
tommy@localhost's password: 
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

In the "old days", omitting the second field (stanza) would give you a password-less login, but that no longer works. I think that pam controls all of the login processing now.

Reuti · 07-19-2011, 01:10 PM

Quote:

Originally Posted by tommylovell

In the "old days", omitting the second field (stanza) would give you a password-less login, but that no longer works. I think that pam controls all of the login processing now.

Yes, you have to use nullok therein for pam_unix2.so for the auth rule and allow it in sshd_config too.

anomie · 07-25-2011, 09:05 AM

Quote:

Originally Posted by jeriryan

I'm not trying to fix it, just want to know if the account is essentially not "login-able" in it's current state.

It should probably be cleaned up at some point so you (or a future sysadmin) doesn't have to puzzle over it again.

Most likely got to this state by someone editing the files manually. If you have to do that, always use vipw(8).