UNIX: The /etc/shadow File in Depth
-
In the "old" days, decades ago, UNIX systems kept user passwords stored, in plain text, in the /etc/passwd file (hence its name.) This, for very obvious reasons, was not at all good. But there was no simple solution to this as any change to an encrypted password system would break backwards compatibility with the /etc/passwd file and with any tools that depended on it. The solution was to make a new file, the /etc/shadow file that would "shadow" the /etc/passwd file and provide a place for a new encrypted password along with some additional password controls. So while having a separate file is a bit bizarre today, it has an historic context that makes it make sense. No functionality is lost and the additional complexity is nominal. (Linux and most UNIX use this file. BSD, however, uses /etc/master.passwd instead.)
UNIX History Lesson: The shadow password system was first introduced in the mid-1980s by Sun's SunOS UNIX system and by 1990 was widely copied and essentially ubiquitous in UNIX systems. So the shadow concept has been a part of Linux since inception.
Unlike the /etc/passwd and /etc/group files, /etc/shadow is protected and normal users cannot see its contents. This provides an additional level of security for it. There is no need for users to see what /etc/shadow contains, but other files are useful to see what accounts are available, groups exists and who are members of them.
Let's look at a few selected lines of /etc/shadow, notice that this is a colon delimited file:
syslog:*:16613:0:99999:7::: jennifer:$6$Rmov1cd9$m5Z0JoE3fK6UvEpojvUQP1AOQV6zVoijFVKyyqRRPWJHu9Qu3dQDIVroRCwkadbLeuj98sK0rn/n2WlwlnHr7.:16772:0:99999:7:::The format of the file is...
- username
- password (or password info)
- date of last password change
- days until change allowed
- days before change required
- days warning for expiration
- days before account inactive
- date when account expires
- reserved
Here, in our first line, the user is syslog and in the second line the user is jennifer. Make note that it is the username, not the UID that matches users to their /etc/shadow entry.
In the second field we see a major difference. For syslog we just see an "*". This denotes that the account is locked and cannot use a password for authentication. This is common for accounts that have no need for a log in (like a system account here) or for users who only log in via some other means such as keys (which we will learn about later.) We would not want a password here if there was no password authentication allowed for the account. For the jennifer account we see an encrypted password in this field, instead.
We we learn later how dates are stored in UNIX systems, so the numbers here in the date fields may seem a bit odd.
In the third field we have the date of the last password change. This affects nothing, just provides info to the system.
The fourth field tells us how long before another change is allowed. Generally you will see this as a 0 as this is often unused. With 0 the user can change their password immediately.
The fifth field offers us how long until a change to the password must be made (in the example here 99999 is the rough equivalent of never needs to be changed.)
The six field is for expiration warning times. Many of the later fields can be ignored and left blank. The colons separating the blank fields must be retained, however.
The seventh field is the number of days before the account becomes inactive.
The eighth field is the date when the account expires.
The nine field is reserved and unused.
Typically we use nothing more in this file that the username and password fields to determine how an account is being treated. It is rather uncommon to look at the /etc/shadow file manually. It is extremely common for most fields to go unused.
If we rarely look at the /etc/shadow file, one might inquire as to how it is created or altered, especially as the password field requires encryption. The answer is the
pwconvcommand. Of course, most user creation tools will manage /etc/shadow for us automatically behind the scenes. But if we create a user manually by editing the /etc/passwd file by hand of course they will not get an entry in the /etc/shadow field. Since editing the /etc/passwd file by hand or by script is not uncommon, we need to learn thepwconvcommand (literally means "password convert" - meaning to convert from old style passwords in /etc/passwd to modern ones in /etc/shadow.)All we need to do, after editing /etc/passwd is run the command like this:
# pwconvObviously root level permissions are needed for this command given the nature of what it does.
Recommended Exercise:
- Create a user by hand in /etc/passwd
- Look at /etc/shadow and notice that they have no entry
- Use pwconv to make the user ready for a password
- Look at /etc/shadow again and notice that they have a passwordless entry
- Use passwd as root to create their initial password
More on the asterisk, exclamation point and double exclamation point in the password field:
In all three cases, these are simple "bad" passwords that don't work and function to lock an account. Under the hood, that's all that they do. In practice, though, an asterisk (*) is supposed to denote a service account that was never given a password so has been unable to login since creation. And exclamation point (!) or a double (!!) are two different tools' ways of denoting that a password used to exist but that the account has since become locked. In some cases the ! will be followed by the old password, but not always.
Part of a series on Linux Systems Administration by Scott Alan Miller
-
Quick thing, you may also see an exclamation mark before an encrypted password in the password field. This will also lock the account, but if you're not paying attention it can be missed.
So this would mean Jennifer could not log in also:
jennifer:!$6$Rmov1cd9$m5Z0JoE3fK6UvEpojvUQP1AOQV6zVoijFVKyyqRRPWJHu9Qu3dQDIVroRCwkadbLeuj98sK0rn/n2WlwlnHr7.:16772:0:99999:7::: -
@stacksofplates thanks. That's good info that I incorporated in. There is a rare !! as well, which is locking from a different tool
-
Man, I did just sneak in after /etc/shadow became standard in the 90s.
-
@travisdh1 said in UNIX: The /etc/shadow File in Depth:
Man, I did just sneak in after /etc/shadow became standard in the 90s.
I was just before it.
-
@scottalanmiller said in UNIX: The /etc/shadow File in Depth:
@travisdh1 said in UNIX: The /etc/shadow File in Depth:
Man, I did just sneak in after /etc/shadow became standard in the 90s.
I was just before it.
I was way after.
-
@stacksofplates said in UNIX: The /etc/shadow File in Depth:
@scottalanmiller said in UNIX: The /etc/shadow File in Depth:
@travisdh1 said in UNIX: The /etc/shadow File in Depth:
Man, I did just sneak in after /etc/shadow became standard in the 90s.
I was just before it.
I was way after.
Is this where I yell "Get off my lawn you young whippersnapper!"?
-
@travisdh1 said in UNIX: The /etc/shadow File in Depth:
@stacksofplates said in UNIX: The /etc/shadow File in Depth:
@scottalanmiller said in UNIX: The /etc/shadow File in Depth:
@travisdh1 said in UNIX: The /etc/shadow File in Depth:
Man, I did just sneak in after /etc/shadow became standard in the 90s.
I was just before it.
I was way after.
Is this where I yell "Get off my lawn you young whippersnapper!"?
It's certainly where I do.
