The /etc/passwd and /etc/shadow Files
Every local user account on a Linux system is recorded in two plain-text database files that work together: /etc/passwd holds account metadata (username, UID, GID, home directory, login shell) and is world-readable by design, while /etc/shadow holds the actual hashed passwords and password-aging policy and is tightly restricted to root (and the shadow group) precisely because it contains sensitive credential material. This split exists for a practical reason — many tools (like ls -l showing owner names, or id) need to read basic account metadata constantly, but there's no reason those lookups should ever expose password hashes, so the sensitive data was split into a separate, locked-down file decades ago as a security hardening measure.
Cricket analogy: Like a scoreboard visible to every spectator showing player names and team but never their private training notes, the coach's locked notebook of tactical secrets is restricted to the coaching staff only, just as /etc/shadow is restricted to root.
/etc/passwd: account metadata
Each line in /etc/passwd is a colon-separated record with seven fields: username, password placeholder, UID, GID, GECOS (a free-text comment field, historically for full name/contact info), home directory, and login shell. The password field is almost always just 'x' on modern systems, signaling that the real hash lives in /etc/shadow instead — a lingering 'y' or an actual hash string here would indicate a very old or non-shadow-enabled system. A login shell of /usr/sbin/nologin or /bin/false is used for service accounts that should never get an interactive login.
Cricket analogy: Like a player registry card listing name, squad number, and team but with the password to the online player portal replaced by a placeholder note pointing to the real system, and a support-staff entry marked with no playing privileges.
$ cat /etc/passwd | head -5
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
jsmith:x:1001:1001:Jane Smith,,,:/home/jsmith:/bin/bash
# Field breakdown for jsmith:
# username:password:UID:GID:GECOS:home_dir:shell
# jsmith :x :1001:1001:Jane Smith,,,:/home/jsmith:/bin/bash
# List every account with an interactive shell (a rough 'who can log in' check)
grep -E '/(bash|sh|zsh)$' /etc/passwd | cut -d: -f1/etc/shadow: password hashes and aging
/etc/shadow contains one colon-separated line per account with nine fields: username, encrypted password hash, date of last password change, minimum days between changes, maximum password age, warning period before expiry, inactivity grace period, account expiration date, and a reserved field. The hash field itself encodes the algorithm used — a leading $6$ means SHA-512, $5$ means SHA-256, and $y$ or $2b$ variants indicate yescrypt or bcrypt on newer systems — followed by a salt and the hash. An account with ! or * in place of the hash has password login disabled entirely (common for service accounts), while an empty hash field means no password is required at all, a serious misconfiguration.
Cricket analogy: Like a sealed envelope containing a player's biometric lock code where the wax seal color indicates which security vendor made it, a retired player's entry marked with an X can never log back into the portal, while a blank envelope would dangerously mean anyone could walk in unchecked.
# /etc/shadow requires root to read
sudo cat /etc/shadow | head -3
root:$6$randomsalt$longhashstring...:19700:0:99999:7:::
jsmith:$6$anothersalt$anotherhash...:19723:1:90:7:14::
# View and set password aging policy with chage
sudo chage -l jsmith # list current aging settings
sudo chage -M 90 -W 7 jsmith # max 90 days, warn 7 days before expiry
sudo chage -d 0 jsmith # force password change at next login
# Lock and unlock an account without deleting it (prepends ! to the hash)
sudo usermod -L jsmith
sudo usermod -U jsmith
# Verify shadow file permissions (should be restricted)
ls -l /etc/shadow
# -rw-r----- 1 root shadow 1823 Jul 8 09:12 /etc/shadowThis wasn't always split. Very old Unix and early Linux systems stored password hashes directly in the world-readable /etc/passwd file. That became a real security problem once offline dictionary/brute-force cracking tools got fast enough that anyone with read access to /etc/passwd could feasibly crack weak hashes without ever touching the live system. 'Shadow passwords' (the /etc/shadow split) were introduced specifically to close that hole by moving hashes into a file only root can read.
Never manually edit /etc/passwd or /etc/shadow with a plain text editor while other processes might be reading/writing them — use vipw and vipw -s (or the higher-level useradd/usermod/passwd/chage tools) instead. These lock the files during editing and validate structure, preventing corruption that could otherwise leave the system unable to authenticate any user, including root, if a field gets malformed or a line gets misaligned.
- /etc/passwd stores account metadata (username, UID, GID, GECOS, home dir, shell) and is world-readable by design.
- /etc/shadow stores password hashes and aging policy, and is restricted to root/the shadow group for security.
- An 'x' in /etc/passwd's password field means the real hash lives in /etc/shadow, not in this file.
- Hash prefixes like $6$ (SHA-512), $5$ (SHA-256), or $y$ (yescrypt) identify the hashing algorithm used in /etc/shadow.
- chage manages password aging policy (expiry, warning period, minimum/maximum age); usermod -L/-U locks/unlocks accounts.
- Always edit these files via vipw/vipw -s or higher-level tools (useradd, passwd, chage), never a raw text editor, to avoid corruption and lockouts.
Practice what you learned
1. Why is /etc/shadow restricted to root while /etc/passwd remains world-readable?
2. What does an 'x' in the password field of /etc/passwd indicate?
3. Which command should be used to safely edit /etc/passwd directly, if a manual edit is truly necessary?
4. In /etc/shadow, a hash beginning with $6$ indicates which hashing algorithm was used?
5. What does `sudo usermod -L jsmith` do to the account jsmith?
Was this page helpful?
You May Also Like
Users, Groups, and sudo
Learn how Linux organizes access through users and groups, how to create and manage them, and how sudo grants temporary elevated privileges safely and auditably.
File Permissions Explained (rwx)
Understand the Linux permission model — read, write, and execute bits for owner, group, and others — and how ls -l output maps to those permissions.
SSH and Remote Access
Understand SSH's client-server model, key-based authentication, port forwarding, and configuration practices for securely administering remote Linux systems.
Linux & Shell Scripting Interview Questions
A curated set of frequently asked Linux and Bash interview questions with model answers, spanning fundamentals, scripting, and troubleshooting scenarios.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics