Audit Linux Password Files Safely with pwck

pwck checks the local account files for broken records without touching anything, as long as you keep it in read-only mode. The installed package here is Ubuntu's passwd version 1:4.13+dfsg1-4ubuntu3.2, providing shadow-utils 4.13 behaviour.

• Allow about 10 minutes for a routine check.
• You need a shell and read access to the account files; a complete default check normally needs elevated privileges because /etc/shadow is restricted.
• Do not run the sudo commands below against a production machine for the first time during an incident without checking the output carefully.

Before you start: know what pwck can change

pwck verifies the format and relationships in /etc/passwd and, when shadow checks are enabled, /etc/shadow. It checks field counts, unique names, user and group identifiers, primary groups, home directories and login shells. Shadow checks include matching entries, field counts, duplicate shadow names and password-change dates.

Some findings are interactive: for a malformed or uncorrectable line, the program can ask whether to delete it. The read-only option prevents updates and is the safe starting point. The command does not repair a damaged record for you; warnings commonly point towards usermod or another account-management decision.

1. Run a complete read-only check

Run this as an administrator:

sudo pwck --read-only

With no file arguments, this uses /etc/passwd and /etc/shadow. A clean run ends without a finding and returns exit status 0. A machine can still have legitimate warnings, especially service accounts whose home directories are intentionally absent. Read every line before deciding what action is appropriate.

To make the result easy to consume in a script, print the status immediately:

sudo pwck -r
status=$?
echo "pwck exit status: $status"

• Status 2 means one or more bad password entries.
• Status 3 means the password files could not be opened, which is different from a clean check.
• Status 4 means the files could not be locked.
• Status 5 and 6 mean update and sort failures.
• Status 1 is invalid syntax.

Treat every non-zero value as a result to investigate, not as proof an account should be deleted.

2. Reduce routine noise only after the first check

The quiet option reports errors only and suppresses warnings that do not need user action:

sudo pwck --read-only --quiet

Use this form for a monitoring check only once you have already reviewed the normal output on that host. Quiet mode changes what is displayed, not the underlying database. Keep the exit status, because a command that prints little can still return 2 or 3.

Do not combine -q with a vague assumption that silence means the database is perfect. It only means no reportable error was printed under the selected output policy.

3. Decide whether each finding is real

A missing home directory may be harmless for a service account, but it may indicate a broken deployment for a human login. Compare the account's purpose, ownership and expected shell with your system's records before changing it. A missing primary group, duplicate name or malformed field deserves more care than a stale path used by a disabled service.

The /etc/login.defs settings can affect warnings. This installation sets NONEXISTENT to /nonexistent, letting that value represent an intentionally absent home directory. Password ageing settings such as PASS_MAX_DAYS, PASS_MIN_DAYS and PASS_WARN_AGE also influence account policy. Inspect them without editing:

grep -E '^(NONEXISTENT|PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE)' /etc/login.defs

These settings do not turn a malformed account line into a valid one. They explain some policy-related output, so capture them alongside the check when documenting a finding.

4. Use alternate files for a controlled investigation

The command accepts a password file and, optionally, a shadow file. Useful for a staged or chrooted system, but easy to check only half of by accident. Name both files when you intend to validate a pair:

sudo pwck --read-only /srv/recovery/etc/passwd /srv/recovery/etc/shadow

Only absolute paths are accepted for --root. With a root directory, configuration files are taken from that directory and any changes would apply there:

sudo pwck --read-only --root /srv/recovery

Check the directory really is the intended system image before running this. A typo can point the command at a different tree, and a missing file can produce exit status 3 rather than a useful integrity result.

5. Treat sorting as a separate, state-changing operation

--sort sorts entries in /etc/passwd and /etc/shadow by UID. It is not a read-only report: sorting changes files and can create operational surprises for tooling that compares files or expects a stable order.

Warning: do not use --sort as a casual repair. If an approved maintenance procedure requires sorting, take a verified backup, record the current checksums and arrange a recovery path before running:

sudo pwck --sort

The manual states that -r and -s cannot be combined. If a sort is interrupted or fails, stop and restore only from the backup you verified for this purpose. Never paste an account line from an unrelated host into either file.

Common traps

• Plain pwck as an unprivileged user can fail to open /etc/shadow. Use sudo pwck -r for the complete host check.
• Only naming the password file is not a substitute for naming the matching shadow file in a recovery tree. State explicitly which files you are checking.
• --badname permits names that do not conform to the usual standards. It does not repair a malformed record, and it can hide a naming problem from a check. Use it only when the naming exception is documented.
• A warning about a directory or shell is not permission to delete the user. Check service ownership, scheduled jobs and application configuration first.

Done means

• Read-only check run: you ran sudo pwck --read-only against the intended account files.
• Exit status investigated: you recorded it and looked into every non-zero result.
• Real problems separated out: intentional service-account settings distinguished from malformed or mismatched entries.
• Quiet output used correctly: only after understanding the host's normal warnings.
• No unapproved changes: you did not use --sort or accept a deletion prompt without an approved backup and recovery plan.