Recover Linux account passwords from matched records

Needs: Correct passwd/shadow pairing or known hash format; account identity and a feasible recovery strategy

Shell commands

# Baseline
unshadow passwd.copy shadow.copy > linux.hash
john --wordlist=wordlist.txt --rules=Jumbo linux.hash
john --show linux.hash

Verify → Tie the recovered password to the correct user and validate an allowed login/sudo transition.

If it fails → Mismatched snapshots or locked/expired accounts can defeat use even after recovery; inspect account state. More detail ↓

If → then

A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
sudo -l grants an operation under a more useful identity → Use an allowed sudo operation to cross a privilege boundary
Needs: Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it
A new Linux foothold or an identity/privilege change → Establish Linux state and choose an escalation candidate
Needs: A working command channel and accurate effective identity, group, mount and process context

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Recover Linux account passwords from matched records

USE WHEN: Readable password verifiers and account metadata
STARTING ACCESS: A credential artifact with a recorded source and possible account context
RESULT: A recovered local account password with a justified privilege/reuse test

Recognize the clue

Inspect permission-backed account backups or privileged read results; associate shadow verifiers with the matching passwd metadata.

file passwd.txt shadow.txt
head -n 3 passwd.txt
head -n 3 shadow.txt

SYNTHETIC EXAMPLE OUTPUT

passwd: USER:x:USER_ID:GROUP_ID:...:/home/USER:/bin/bash
shadow: USER:$ALGORITHM$SALT$VERIFIER:...

Means: The matching account name and verifier prefix identify an offline password-recovery candidate.

Confirm: Confirm snapshots, hash format and account state; a locked field or absent salt is not a normal usable verifier.

After validation: A complete supported verifier and feasible candidate space exist: recover, then validate the matching account.
Ruled out in this context: The password field is locked with no usable verifier: reject recovery from that field.
Still inconclusive: Mismatched backups or unknown account scope require source consistency checks.

Troubleshooting: Mismatched snapshots or locked/expired accounts can defeat use even after recovery; inspect account state.

Additional prerequisite checks

unshadow passwd.txt shadow.txt > linux.hashes
john --wordlist=WORDLIST linux.hashes

Preserve username, UID, shell and lock markers. A recovered password does not override SSH settings, su policy or a disabled account.

Why it works

The verifier encodes algorithm and salt; passwd metadata maps it to a user. Reading a verifier does not itself change UID or authorize sudo.

Worked example · hypothetical

Observation: a backup exposes account metadata and shadow records. Test: combine the matched pair and recover one selected account. Illustrative output: a password is shown for a local user. Interpretation: validate that local identity and inspect its rights.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗