Account files and attributes

Before you read. There is no user database on a Linux machine. No service to query, no binary format, nothing to corrupt in an interesting way.

There are four text files, and you can read three of them right now without any privilege at all.

If /etc/passwd is world-readable, why is that not a catastrophe?

Because the passwords are not in it, and have not been since the early nineties. The fourth file is where they went, and the arrangement (one file everyone can read, one file only root can) is a small, elegant piece of design worth understanding rather than memorising.

Some words you will need

hash

A one-way function. You can check a guess against it; you cannot reverse it.

salt

Random data mixed into each hash so identical passwords produce different results.

locked

The password cannot match anything. Other login methods still work.

expired

The account itself is closed. Nothing works.

NSS

Name Service Switch: the layer that decides whether "user jordan" is answered from a file, LDAP, or elsewhere.

What breaks without this

You cannot answer “does this person still have access”. Which is the question that actually gets asked, and it needs all four files plus the login records.

A malformed line locks everyone out. These are text files parsed on every login, and one bad entry can break authentication for the whole machine.

You misread an audit. Locked, expired, nologin, and no-password-set look similar and mean four different things.

/etc/passwd, world-readable on purpose

jordan:x:1000:1000:Jordan Ellis:/home/jordan:/bin/bash

It has to be world-readable. Every ls -l turns a UID into a name, every ps shows an owner, and every program that displays a username reads this file. Restricting it would break all of that.

Which is exactly why the password cannot be in it. In early Unix it was, field two held the hash, and world-readable hashes meant anyone could take the file away and attack it offline at their leisure. Shadow passwords split the file in two: the parts everything needs stay readable, and the secret moves somewhere only root can go.

Field seven decides whether the account is for a person. /usr/sbin/nologin gives an account that owns files and runs services and cannot be logged into interactively. Most entries in /etc/passwd are that.

/etc/shadow, and what a hash looks like

A password is set, then the account is locked with passwd -l, then expired with chage -E 0. The shadow entry is printed after each step.

# Debian 13 (trixie), x86_64
$ useradd -m jordan >/dev/null 2>&1; echo 'jordan:notarealpassword' | chpasswd; echo '--- the shadow entry ---'; grep '^jordan' /etc/shadow; echo '--- now lock it ---'; passwd -l jordan >/dev/null 2>&1; grep '^jordan' /etc/shadow | cut -c1-40; echo '--- and expire the account outright ---'; chage -E 0 jordan; chage -l jordan | grep -i 'account expires'
--- the shadow entry ---
jordan:$y$j9T$kPrG5D21P2aNr55UsgWQV0$UHM9LbkJSEDLgXk3T3.OtP5u9AFTdeT4vnZ9bL97JgD:20673:0:99999:7:::
--- now lock it ---
jordan:!$y$j9T$kPrG5D21P2aNr55UsgWQV0$UH
--- and expire the account outright ---
Account expires						: Jan 01, 1970

An exclamation mark, prepended. The hash is untouched underneath it, which is what makes passwd -u an exact reversal. It also means the lock works by making the stored string impossible for the hashing function to ever produce, no input hashes to something starting with !, rather than by any explicit “locked” flag.

And Jan 01, 1970 is not an error. Field 8 is a count of days since the epoch, so -E 0 means day zero, which prints as the epoch itself. Any date in the past expires the account; zero is just the bluntest way to write one.

Nine colon-separated fields. The first two carry nearly all the meaning:

chage -l prints all of that as readable dates and is what to use. Field 3 being a day count is why chage -E 0 displays as Jan 01, 1970, day zero.

Reading the hash

$y$j9T$kPrG5D21P2aNr55UsgWQV0$UHM9Lbk... is three $-separated parts:

• y, the algorithm. y is yescrypt, the current default on Debian and Fedora. 6 is SHA-512, still the default on the RHEL family. 1 is MD5 and is a finding.
• j9T$kPrG5D21P2aNr55UsgWQV0, parameters and the salt.
• UHM9Lbk..., the hash itself.

The salt is stored in plain sight and that is correct. Its job is not to be secret; it is to be different for every account, so that two people with the same password get different hashes, and so an attacker cannot precompute one table that works against everybody. Without a salt, identical hashes in the file would reveal identical passwords at a glance.

Verification never reverses anything: the system takes the password offered, mixes in the stored salt, runs the same function, and compares.

Locking prepends a !. Look at the second capture: the hash is intact and now begins !$y$.... No password can ever produce a string starting with !, so nothing matches, and unlocking is simply removing the character, which is why passwd -u restores the original password rather than clearing it.

* in the field means “no password login was ever possible”, which is what service accounts have. An empty field means no password is required at all, which is a serious finding and worth checking for: sudo awk -F: '$2 == "" {print $1}' /etc/shadow.

/etc/group and /etc/gshadow

deploy:x:1001:jordan,alex

Name, a password marker, GID, and a comma-separated member list. Those members are the supplementary members, somebody whose primary group this is does not appear here, because /etc/passwd already says so. That asymmetry is why id is the reliable answer and grep is not.

/etc/gshadow holds group passwords and administrator lists. Group passwords are a rarely-used feature that lets someone newgrp into a group they are not a member of, and they are generally considered a bad idea.

sudo pwck -r        # read-only, report problems
sudo grpck -r

Who is here, and who was

w is the one to run first on a machine behaving oddly. It gives you logged-in users, their idle time, what they are running, and the load average in one screen, which frequently answers “why is this slow” before you have asked anything else.

lastb is the security one and needs root. A large number of failed attempts for one account, or attempts for accounts that do not exist, is a brute-force attempt in progress and is visible nowhere else.

lastlog finds accounts that exist and have never been used, which is the list an auditor asks for and which is usually longer than anyone expects.

These read binary logs (wtmp, btmp, lastlog) rather than text, which is why you need the commands rather than cat. On a systemd machine journalctl _COMM=sshd covers similar ground with more detail and honest timestamps.

sudo awk -F: '{print $2}' /etc/shadow | cut -d'$' -f2 | sort | uniq -c

Across distributions

The file formats are identical, which is why an /etc/passwd line can be moved between distributions. The hash format cannot be assumed portable in the other direction: a $y$ hash needs a libcrypt that supports yescrypt, and an older RHEL release will not authenticate against it.

Prove it

To answer “can this person get in”:

# Does the account exist, and via which source
getent passwd jordan

# Is the password usable
sudo grep '^jordan:' /etc/shadow | cut -c1-30

# Is the account expired
sudo chage -l jordan

# Is there a key, which is the route people forget
sudo ls -l /home/jordan/.ssh/authorized_keys 2>/dev/null

# Are they logged in right now
who | grep jordan

All five, not one. Each covers a different route, and the common mistake is stopping after the second.

What trips people up

1. Locked is not closed

! in front of the hash stops password authentication and nothing else. SSH keys still work.

chage -E 0 expires the account, which stops everything. Remove authorized_keys as well.

2. Editing the files directly

One malformed line can break authentication for every account on the machine.

vipw and vigr lock and validate. pwck -r and grpck -r check afterwards. And keep a second session open while you work.

3. grep instead of getent

On a domain-joined machine the account is not in /etc/passwd at all, and grep finding nothing looks like the account does not exist.

getent passwd name goes through NSS and answers for every configured source.

4. A number where a name should be

ls -l showing 1001 instead of a name means no passwd entry exists for that UID, usually a deleted account, or files restored from a machine whose UIDs differed.

find / -uid 1001 finds them all. Decide deliberately who should own them, before the next useradd claims that UID and inherits the lot.

5. Assuming the shadow file is a complete picture

It covers local accounts only. LDAP, SSSD, and Kerberos accounts have no entry in it, and their password policy lives somewhere else entirely.

getent passwd and /etc/nsswitch.conf tell you which sources are in play.

Work it through

An auditor asks for a list of every account on a server that can log in interactively. Somebody hands over wc -l /etc/passwd, which says 42.

Reason it out before reading on.

42 is wrong and enormously so, because most entries in /etc/passwd are not people. Service accounts need an identity to own files and run processes; they are not login accounts.

First cut: the shell. An account whose shell is /usr/sbin/nologin or /bin/false cannot get an interactive session:

getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $7}'

That usually reduces 42 to a handful.

Second cut: the UID. System accounts live below UID_MIN from /etc/login.defs, conventionally 1000:

getent passwd | awk -F: '$3 >= 1000 && $3 != 65534 {print $1}'

65534 is nobody and is excluded deliberately.

Third cut: is the password usable?

sudo awk -F: '$2 !~ /^[!*]/ {print $1}' /etc/shadow

Entries starting ! are locked and * were never usable.

Fourth (and this is the one that makes the answer honest), keys:

sudo find /home /root -name authorized_keys -not -empty 2>/dev/null

An account with a locked password and a key is a login account, and none of the first three checks would have caught it.

Fifth: is /etc/passwd even the whole story? grep -E '^(passwd|shadow):' /etc/nsswitch.conf. If it lists sss or ldap, local files are a fraction of the accounts that can authenticate, and the real answer lives in the directory.

Now the point worth extracting. “Can this account log in” is not one question and no single file answers it. Shell, UID range, password state, key presence, and account expiry are five independent things, any one of which can be the deciding factor, and they can disagree.

The habit worth taking: when asked about access, check the keys. It is the route that no field in /etc/passwd or /etc/shadow mentions, which is exactly why it gets missed, and it is the one most administrators actually use.

Try it

Optional, on any machine.

1. getent passwd | wc -l, then the shell and UID filters above. Compare the three numbers.
2. getent passwd root and name all seven fields.
3. sudo grep '^root:' /etc/shadow | cut -d: -f2 | cut -c1-4 and identify the algorithm from the prefix.
4. sudo awk -F: '{print $2}' /etc/shadow | cut -d'$' -f2 | sort | uniq -c.
5. w, then who, then last | head. Note what each adds.
6. sudo lastb | head if there is anything in it.
7. sudo pwck -r and sudo grpck -r, and read what they check.

Verification step. You have it when you can produce a defensible list of interactive accounts on an unfamiliar machine, and say why each excluded entry was excluded.

Check yourself

References

• passwd(5) - Linux man-pages project. Accessed 2026-08-07.
• shadow(5) - Linux man-pages project. Accessed 2026-08-07.
• group(5) - Linux man-pages project. Accessed 2026-08-07.
• crypt(5) - Debian Project. Accessed 2026-08-07.
• nsswitch.conf(5) - Linux man-pages project. Accessed 2026-08-07.
• pwck(8) - Linux man-pages project. Accessed 2026-08-07.

Every block above with a distribution and architecture header was captured by running the command on a Debian 13 (trixie) container. Blocks without one are illustrative.