Cracking Linux Passwords with John the Ripper

A Beginner's Walkthrough

A hands-on lab in Kali Linux, using a test account created purely for this demo. All hashes and passwords shown below have been blacked out — never post real hashes or passwords, even ones from throwaway lab accounts.

⚠ Do this only on systems you own or are explicitly authorized to test (like your own Kali VM). Running this against someone else's machine or account without permission is illegal.

Where Linux actually stores your password

Every Linux system keeps user account info in two separate files:

• /etc/passwd — public info about every account: username, user ID, home folder, login shell. Anyone can read this file.

• /etc/shadow — the actual password hashes. Only the root user can read this one, which is why it's the file attackers really want.

Splitting the two like this is a security feature: even if /etc/passwd leaks, there's no password data in it.

Step 1 — Confirm this for yourself

As a normal user, trying to read /etc/shadow fails. Switch to root with sudo su, and it opens right up.

Notice the format of each line in /etc/shadow:

username:password_hash:last_changed:min:max:warn:::

Most system accounts (daemon, bin, sync, etc.) show * in the password field — that just means the account can't log in with a password at all, so there's nothing to crack there.

Now compare that to /etc/passwd, which has no hash at all — just an x placeholder telling the system "look in /etc/shadow for the real hash":

Step 2 — Check what John the Ripper can crack

Before doing anything else, it's worth knowing what hash formats John supports.

Running john — list=formats prints every algorithm it understands — MD5, bcrypt, scrypt, NTLM, and dozens more.

Step 3 — Create a test account

To keep this demo safe and self-contained, a brand-new user was created instead of touching any real account:

useradd pranju passwd 1234

When prompted, a password was typed in (typed characters never show on screen in the terminal — that's normal, not a bug).

Checking /etc/shadow again now shows this new account with its own hash appended at the bottom of the file — that's the value we're going to try to crack later. (The hash itself, and the real hash for the kali account sitting nearby, are blacked out below — never share real password hashes publicly, even from a lab VM.)

Step 4 — Combine passwd + shadow with unshadow

John the Ripper can't read /etc/passwd and /etc/shadow separately — it needs them merged into one file. That's exactly what the unshadow tool does:

unshadow /etc/passwd /etc/shadow > hash.txt

This produces hash.txt, containing every account's username and hash in one line each, ready for John to chew on.

Step 5 — Identify the hash type

Not every hash looks the same — a hash starting with $y$ (yescrypt), $6$ (SHA-512), or $1$ (MD5) needs to be cracked differently. Before running John, it helps to confirm what you're dealing with. A quick way to do this is an online hash identifier: paste in the hash and it tells you the likely algorithm and confidence level.

In this case, the tool flagged it as yescrypt with high confidence — which lines up with modern Kali/Debian systems, since yescrypt has been the default password hashing algorithm since 2022.

Step 6 — Edit hash.txt

Once the hash.txt is successfully created, we will only keep the newly added user id's hash value and remove other.

Step 6 — Crack it with a wordlist

With the hash type confirmed, John the Ripper was pointed at hash.txt using the classic rockyou.txt wordlist (a huge list of real, leaked passwords, included by default in Kali):

john hash.txt — format=crypt — wordlist=/usr/share/wordlists/rockyou.txt

Within a few seconds, John found a match for the pranju account and printed the cracked password next to the username.

That's the whole loop: a weak password, found in a common wordlist, cracked almost instantly. This is exactly why "1234", "password", "qwerty", and anything else sitting in a leaked-password list should never be used on a real account.

The 4 steps

If you strip away all the explanation, the actual attack is just four commands:

1 UNSHADOW

Merge /etc/passwd + /etc/shadow → unshadow /etc/passwd /etc/shadow > hash.txt

2 SAVE HASH

hash.txt now holds the crackable hash

3 IDENTIFY

Confirm the hash algorithm (yescrypt, MD5, SHA-512, bcrypt, etc.)

4 CRACK

Run John with a wordlist → john hash.txt — wordlist=rockyou.txt

Why this matters

This isn't really about John the Ripper — it's about what happens the moment a password exists in a common wordlist. rockyou.txt alone has over 14 million real passwords leaked from a single 2009 breach, and it's still enough to crack accounts today. The fix has nothing to do with fancy hashing algorithms and everything to do with picking a password (or better, a passphrase) that was never used anywhere else.

But there's a catch worth calling out honestly: this attack only worked because we already had root. To read /etc/shadow in the first place, an attacker needs local root access (or a separate vulnerability that grants it) — either through physical/console access, a misconfigured service, a stolen SSH key, or privilege escalation from a lower-privileged foothold. So the real defense isn't just "pick a better password" — it's making sure nobody gets to this point at all, and limiting the damage if they do.