/etc/shadow password quiz
Aaron Toponce
/etc/master.passwd for you BSD hackers) it became clear to me that there is
some confusion about the definitions of each field. Specifically, with how
to mark an account inactive versus just disabling the password logins.
Here's the motivation. If you pull up your shadow file, you'll probably
notice something like the following:
daemon:*:14834:0:99999:7:::
libuuid:!:14834:0:99999:7:::
bitlbee:!!:14849:0:99999:7:::
To get you caught up to speed, the fields are colon-delimited, and the
second field marks the location of the password. Usually, the format of the
password is something like this:
$1$u.rv01JI$.A0WsFuZO.Mg1EvGVJlPI0
However, we see '*', '!' and '!!' in its place. So, I'm curious: what is
the difference, if any between '*', '!' and '!!' in the password field of
the shadow file? Further, what is the proper way to expire an account?
CHALLENGE: Even after setting the password field to say '*', I can still
authenticate with SSH keys using the account. How can I prevent even SSH
from letting a user in?
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
Aaron Toponce
> After having a discussion in ##unix on Freenode about /etc/shadow (or
> /etc/master.passwd for you BSD hackers) it became clear to me that there is
> some confusion about the definitions of each field. Specifically, with how
> to mark an account inactive versus just disabling the password logins.
I think I gave adequate time to answer, so I'm guessing this is territory
untreaded. So, here's the answer:
Short answer: no, there is no difference betwenn '*', '!', '!!' or even ''.
An invalid password is an invalid password. Any character that does not
produce an appropriate hash, or follow the syntax for crypt() in the shadow
file remains invalid.
Long answer: The appropriate way to expire a password is by using the
'usermod' command with the '-e' switch. For example, let's say I setup an
account for myself. By default, you would see something like the following
in your /etc/shadow file (on GNU/Linux- BSD would be your
/etc/master.passwd and the fields would be slightly different):
aaron::14834:0:99999:7:::
Notice the 2nd column, where the password is stored is blank, and
attempting to login right now would fail, as no valid password would be
found. So, I set a password with 'passwd aaron' as root, and end up with
something like this:
aaron:$1$1scFC3Jn8Bx.j/358X2kKwWUG2bucm/::14834:0:99999:7:::
Now, the 'aaron' user should be able to login with his password. However,
suppose the user for that account is put on probation, or moves to another
project, or we wish for him to rotate his password, orwhatever- we have
reason to suspend his account (without removing it). How do we do it?
Well, we could manually change his password to '*', '!', '!!' or ''.
Certainly, that would prevent him from logging in. Or would it? What if he
had an SSH key for his account? OpenSSH will use the key as the
authentication mechanism, rather than the password stored in the shadow
file. So, even though we've "expired" his password, he can still login.
So, how do we expire his password appropriately, so OpenSSH won't allow the
authentication? As already mentioned, use 'usermod -e YYYY-MM-DD aaron'
where 'YYYY-MM-DD' is the date we wish the account to be expired. So,
something like this would be perfectly reasonable:
usermod -e 2011-01-01 aaron
If you now check in the shadow file, you would see something like this:
aaron:$1$1scFC3Jn8Bx.j/358X2kKwWUG2bucm/::14834:0:99999:7::14975:
Notice the '14975' at the end of the string? This represents the number of
days since the UNIX epoch (Jan 1, 1970) since the account has been expired.
Now, any attempts to login, even with OpenSSH will fail, showing the
password has expired.
It should also be noted that 'passwd -d aaron' will completely blank the
password out of the shadow file (at least for GNU/Linux operating systems).
Further, 'passwd -f' specifies when the account should go permanently
disabled after the password expires, 'passwd -L' will lock the password,
putting a '!' infront of the password (effective disabling it) and 'passwd
-U' will unlock the password removing the '!'.
(There is a difference between expired passwords and disabled accounts. Why?)
Now, here's something interesting that I stumbled on when the string of the
password was '*', '!' and '!!', at least with Fedora (I have not verified
for other GNU/Linux operating systems). For each invalid password, run the
command 'passwd -S aaron' (that is a captial 's'), and notice the output:
valid: aaron PS 2009-02-19 0 99999 7 -1 (Password set, MD5 crypt.)
'*': aaron LK 2009-02-19 0 99999 7 -1 (Alternate authentication scheme in use.)
'!': aaron LK 2009-02-19 0 99999 7 -1 (Password locked.)
'!!': aaron LK 2009-02-19 0 99999 7 -1 (Password locked.)
'': aaron NP 2009-02-19 0 99999 7 -1 (Empty password.)
Apparently, there is some sort of convention being used so when the
password field in the shadow file is a single asterisk '*', it displays
that an alternate authentication scheme is in use. If the password is
valid, even if is expired, it shows the hash about the password itself
(being MD5 in this case). '!' and '!!' say the password is "locked", and no
password displays such.
Thought it was interesting at any event. Hopefully, you guys do too. I
don't know why this convention exists, but it's interesting nonetheless.
Further, this convention doesn't exist on BSD, and in fact 'passwd -S' (as
well as many other switches I might have used here) is an invalid swtch on
the BSDs.
FYI.
(I think I might blog this, actually. :) )
Clint Savage
> I think I gave adequate time to answer, so I'm guessing this is territory
> untreaded. So, here's the answer:
The territory wasn't untreaded, just figured others might have never
come across this topic before.
> Short answer: no, there is no difference betwenn '*', '!', '!!' or even ''.
> An invalid password is an invalid password. Any character that does not
> produce an appropriate hash, or follow the syntax for crypt() in the shadow
> file remains invalid.
>
..snip..
>
> Apparently, there is some sort of convention being used so when the
> password field in the shadow file is a single asterisk '*', it displays
> that an alternate authentication scheme is in use. If the password is
> valid, even if is expired, it shows the hash about the password itself
> (being MD5 in this case). '!' and '!!' say the password is "locked", and no
> password displays such.
>
> Thought it was interesting at any event. Hopefully, you guys do too. I
> don't know why this convention exists, but it's interesting nonetheless.
..snip..
> (I think I might blog this, actually. :) )
Okay, before you start blogging this topic, though I agree it's a good
topic to blog. What about this part of the question. I noted a while
back that when you performed locking of passwords using passwd vs
usermod, you got different results. For example,
# passwd -l kynalya
Locking password for user kynalya.
passwd: Success
# grep kynalya /etc/shadow
kynalya:!!$6$HcGO8REU$7Kv8amsLHGhIbDX6OTx9icz8l014X9y/UbIki7on4SGKXwLW5Hg9XG4z6RNxLrSXOrL6gXG4CpPVtX/IRXqXh0:14948:0:99999:7:::
You might notice there are two bangs (!!) before the password. But
when you do the lock with usermod:
# usermod -L kynalya
# grep kynalya /etc/shadow
kynalya:!$6$HcGO8REU$7Kv8amsLHGhIbDX6OTx9icz8l014X9y/UbIki7on4SGKXwLW5Hg9XG4z6RNxLrSXOrL6gXG4CpPVtX/IRXqXh0:14948:0:99999:7:::
It only gets one bang (!) before the password.
While I know that ! is as good as !!, it seems inconsistent to me. I
did some preliminary research into this issue a long while back and
found no rhyme or reason for the inconsistency. Do you, or anyone on
this list, have a reason for this?
On this note, it's important to state that to revert the locked
password locked with password -l kynala, which has two bangs (!!),
'usermod -U kynalya' would actually have to be run twice to unlock the
password..
# usermod -U kynalya
[root@x201 ~]# grep kynalya /etc/shadow
kynalya:!$6$HcGO8REU$7Kv8amsLHGhIbDX6OTx9icz8l014X9y/UbIki7on4SGKXwLW5Hg9XG4z6RNxLrSXOrL6gXG4CpPVtX/IRXqXh0:14948:0:99999:7:::
# usermod -U kynalya
# grep kynalya /etc/shadow
kynalya:$6$HcGO8REU$7Kv8amsLHGhIbDX6OTx9icz8l014X9y/UbIki7on4SGKXwLW5Hg9XG4z6RNxLrSXOrL6gXG4CpPVtX/IRXqXh0:14948:0:99999:7:::
Try this at home. Unless I have an odd version of Linux, but I am
pretty sure I don't. Fedora isn't odd in this way.
Cheers,
Clint
Aaron Toponce
> What about this part of the question. I noted a while
> back that when you performed locking of passwords using passwd vs
> usermod, you got different results. For example,
>
> # passwd -l kynalya
> Locking password for user kynalya.
> passwd: Success
> # grep kynalya /etc/shadow
> kynalya:!!$6$HcGO8REU$7Kv8amsLHGhIbDX6OTx9icz8l014X9y/UbIki7on4SGKXwLW5Hg9XG4z6RNxLrSXOrL6gXG4CpPVtX/IRXqXh0:14948:0:99999:7:::
>
> You might notice there are two bangs (!!) before the password. But
> when you do the lock with usermod:
On my Debian GNU/Linux unstable box:
# useradd foo
# grep foo /etc/shadow
foo:!:15069:0:99999:7:::
# passwd foo
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
# grep foo /etc/shadow
foo:$6$wcLta7Mk$kIMTjAU8KpBEEAxTbyige4s7VimYFCnNkWMxKl3EB4E0uTnx46Nj1KnbLuHsOA/BBQ9/4rPaUkTKZ4ZHX26Dw1:15069:0:99999:7:::
So far, nothing out of the ordinary, except I noticed that on my Fedora 14
sysstem, after creating the user, the password field in the /etc/shadow
file was blank. Here, on Debian Sid, it contains a singe bang '!'.
Continuing:
# passwd -l foo
passwd: password expiry information changed.
# grep foo /etc/shadow
foo:!$6$wcLta7Mk$kIMTjAU8KpBEEAxTbyige4s7VimYFCnNkWMxKl3EB4E0uTnx46Nj1KnbLuHsOA/BBQ9/4rPaUkTKZ4ZHX26Dw1:15069:0:99999:7:::
As documented, and 'passwd -u foo' unlocks as expected. Continuing...
# usermod -L foo
# grep foo /etc/shadow
foo:!$6$wcLta7Mk$kIMTjAU8KpBEEAxTbyige4s7VimYFCnNkWMxKl3EB4E0uTnx46Nj1KnbLuHsOA/BBQ9/4rPaUkTKZ4ZHX26Dw1:15069:0:99999:7:::
Again, as documented with 'usermod -U foo' unlocking as it should.
So, in the case of the two bangs '!!' on your Fedora machine, I wonder if
it's a bug (feature?) or a regression, because I can't replicated it here.
Further on Debian, regardless of the contents of the password in the
/etc/shadow file, none of the conventional outputs are printed with 'passwd
-S foo', like on my Fedora box. '', '*', or '!'. Curious why:
# passwd -S foo
foo L 04/05/2011 0 99999 7 -1
If this isn't bad enough, I noticed that 'passwd -e' and 'usermod -e' are
inconsistent. 'usermod -e' requires a date in the form of YYYY-MM-DD as an
argument, while 'passwd -e' automatically sets the date to 1970-01-01.
What's up with that? Nevermind 'passwd -l' and 'passwd -u' versus 'usermod
-L' and 'usermod -U'.
Ugh. It's times like this that make me want to run a BSD.
Anyway, good times.
Jacob Albretsen
I'm late to the party....
> CHALLENGE: Even after setting the password field to say '*', I can still
> authenticate with SSH keys using the account. How can I prevent even SSH
> from letting a user in?
My experience: On accounts such as "nagios" (if you don't use checking with
ssh) or some other account that has "!!" in the password field, you can prevent
an OpenSSH login with keys by using /etc/security/access.conf. However, given
the right config in the sudoers config file, you can still sudo to the account.
The other thing I've come across, if you use Tectia SSH servers and the
account has "!!" in the password field, it won't let a user in even if the user
has keys set up.
--
Jacob Albretsen
ja...@xmission.com
http://blog.knine.net/
Jacob Albretsen
I'm late to the party....
> CHALLENGE: Even after setting the password field to say '*', I can still
> authenticate with SSH keys using the account. How can I prevent even SSH
> from letting a user in?
My experience: On accounts such as "nagios" (if you don't use checking with