Ubuntu/Barebones to JtR

From a barebones Ubuntu cloud instance to John the Ripper absolutely obliterating passwords. Updated for the 2026 era - bleeding-jumbo git builds, GPU cracking, the whole nine yards.

Why We're Doing This

Sometimes you need a dedicated cracking box. Maybe you've got a pile of NTLM hashes from an engagement, maybe you snagged a WPA2 handshake and want to throw real hardware at it, or maybe you just want a clean cloud instance that does one thing and does it fast. A fresh Ubuntu 26.04 LTS (Resolute Raccoon, baby) instance is a perfect blank canvas.

This page walks you through going from "I just SSH'd in and there's nothing here" to "john is chewing through hashes at an alarming rate." The old version of this page was from 2015 and referenced John 1.8.0.6-jumbo-1 from a zip file. We've come a long way.

Spinning Up the Instance

Cloud Provider? Pick Your Poison

AWS, GCP, Azure, DigitalOcean - they all work. The SSH dance is basically the same everywhere. For AWS you've got your keypair:

$ ssh -i my_key.pem ubuntu@<instance-ip>

For GCP it's usually:

$ ssh -i ~/.ssh/google_compute_engine your-user@<instance-ip>

What Kind of Instance?

If you're just doing CPU cracking, grab something with lots of cores - a compute-optimized instance. But honestly, if you're serious about cracking, you want a GPU instance:

Provider	GPU Instance Type	GPU	Rough Cost (spot)
AWS	g4dn.xlarge	1x T4 (16 GB)	~$0.15/hr
AWS	p3.2xlarge	1x V100 (16 GB)	~$0.90/hr
GCP	n1-standard-4 + T4	1x T4	~$0.20/hr
Azure	NC4as_T4_v3	1x T4	~$0.25/hr

For CPU-only cracking on the cheap, a c6i.2xlarge (8 vCPUs) on spot pricing is pretty much unbeatable. The --fork flag loves cores.

One thing I've learned the hard way: if you're going GPU, make sure the AMI or image already has NVIDIA drivers or at least supports installing them cleanly. Ubuntu 26.04 makes this way less painful than it used to be.

Ubuntu 26.04 LTS

As of April 2026, Ubuntu 26.04 LTS "Resolute Raccoon" is the current LTS release. It ships with kernel 7.0, GNOME 50 on the desktop side, and way more up-to-date packages than the 2015 era this page originally targeted. The apt repository has john available directly, but we're going to build from source because the bleeding-jumbo branch moves fast and you want the latest hash formats.

Software Dependencies

First things first - update the package list and grab the essentials:

$ sudo apt update
$ sudo apt install -y build-essential libssl-dev zlib1g-dev git unzip

That's the bare minimum to compile John. But you'll definitely want these too for extra hash formats and performance:

$ sudo apt install -y pkg-config libgmp-dev libpcap-dev libbz2-dev

If You Have a GPU (and You Probably Want One)

For NVIDIA GPUs (the most common in cloud instances):

$ sudo apt install -y nvidia-opencl-dev ocl-icd-opencl-dev opencl-headers

For AMD GPUs (less common in cloud, but if you're on a dedicated box):

$ sudo apt install -y ocl-icd-opencl-dev opencl-headers

Perl and Python Goodies

A bunch of the *2john extractor scripts need Perl and Python libraries. The Perl stuff:

$ sudo apt install -y libcompress-raw-lzma-perl libdigest-md5-perl \
    libimage-exiftool-perl libmime-base64-perl libnet-ldap-perl \
    libnet-pcap-perl cpanminus

And the Python side:

$ sudo apt install -y python3 python3-pip python3-venv \
    python3-pycryptodome python3-scapy python3-parsimonious \
    python3-cryptography python3-simplejson python3-lxml python3-olefile

You can always circle back and install these later when a *2john script yells at you about a missing module. I usually do the core build first, then loop back for the scripting dependencies as needed.

Installing John the Ripper (The Right Way in 2026)

Clone Bleeding-Jumbo

The old way was downloading a numbered zip. The modern way is git. The bleeding-jumbo branch is where all the action is - 400+ hash formats, GPU support, and updates landing weekly:

$ mkdir -p ~/src
$ cd ~/src
$ git clone https://github.com/openwall/john -b bleeding-jumbo john

This takes like 30 seconds on a decent connection. The repo is around 13k stars on GitHub as of 2026 and it's actively maintained by a whole community of contributors.

Configure and Build

$ cd ~/src/john/src
$ ./configure

The configure script sniffs your system and figures out what's available. Watch its output - it tells you exactly what features it found. You'll see lines like:

checking for OpenSSL... yes
checking for zlib... yes
checking for GMP... yes
checking for OpenCL... yes

The "yes" cascade is genuinely satisfying. If something says "no" that you expected to be there, go install the -dev package and re-run configure.

Now build it:

$ make -s clean && make -sj$(nproc)

The -sj$(nproc) is the secret sauce - it parallelizes the build across all your cores and suppresses the noisy compile commands so you only see warnings and errors. On an 8-core instance this takes maybe 2-3 minutes. On a single core it's 10-15 minutes.

No make install needed. John runs from ~/src/john/run/ and that's actually the preferred way to use it - self-contained, no system-wide pollution, easy to update with a git pull later.

Optional: OpenMP Fallback Build

This is a slightly advanced trick that gives you a speed boost when OpenMP is disabled at runtime (which happens automatically when you use --fork). It builds two john binaries:

$ cd ~/src/john/src
$ ./configure --disable-openmp && make -s clean && make -sj$(nproc)
$ mv ../run/john ../run/john-non-omp
$ ./configure CPPFLAGS='-DOMP_FALLBACK -DOMP_FALLBACK_BINARY="\"john-non-omp\""'
$ make -s clean && make -sj$(nproc)

Honestly, this is a nice-to-have, not a must-have. Skip it on your first go.

Verify the Build

$ cd ~/src/john/run
$ ./john --list=build-info

This prints everything: compiler version, flags, what features are compiled in, available hash formats. It's a great sanity check.

Then run the self-tests:

$ ./john --test=0

This runs all the built-in tests without benchmarking. If everything passes, you're golden.

Benchmarking Your Beast

$ ./john --test

This benchmarks every single hash format John knows about. It takes a while. On a fast machine with GPU support it's worth letting it rip just to see the numbers scroll by. For a quick taste, benchmark just the formats you care about:

$ ./john --test --format=wpapsk
$ ./john --test --format=nt
$ ./john --test --format=raw-sha256

On a modern cloud instance with a T4 GPU, you might see something like:

Benchmarking: wpapsk, WPA/WPA2/PMKID PSK [PBKDF2-SHA1 OpenCL]... DONE
Speed for cost 1 (key size) of 0 and 1 and 2 and 3 as 4096
Raw:    185432 c/s real, 182100 c/s virtual

That's like 80x faster than the 2256 c/s on the old 2015 CPU benchmark from the original version of this page. Modern hardware plus OpenCL is no joke.

Actually Cracking Things

Basic Workflow

The simplest possible invocation:

$ ./john --wordlist=rockyou.txt hashes.txt

John auto-detects the hash format for you. If it guesses wrong (it happens, especially with raw hashes), specify it explicitly:

$ ./john --format=nt --wordlist=rockyou.txt hashes.txt

Using Rules (This Is Where John Shines)

Without rules, John is just trying each word from your wordlist verbatim. That's missing 80% of crackable passwords. Rules apply mutations - appending numbers, capitalizing, leet-speak substitutions, the works:

$ ./john --wordlist=rockyou.txt --rules hashes.txt

The default rules set is good. The Jumbo ruleset is the kitchen sink:

$ ./john --wordlist=rockyou.txt --rules=Jumbo hashes.txt

Jumbo rules have 3000+ rule permutations. It's slower but way more thorough. For a first pass, use default rules. For the stubborn hashes that survive, bring out Jumbo.

Forking for Multi-Core

This is the flag that separates people who wait from people who get results:

$ ./john --wordlist=rockyou.txt --rules --fork=8 hashes.txt

This runs 8 independent cracking processes in parallel, each chewing on a slice of the wordlist. On an 8-core instance this is basically an 8x speedup. Scale --fork to your vCPU count. John is smart about it - each fork works on a different set of password candidates and they all write to the same pot file.

Session Management

Cracking sessions can run for days. If your SSH connection drops, you don't want to lose progress:

$ ./john --session=ntlm_attack1 --wordlist=rockyou.txt --rules hashes.txt

John periodically saves its state to ~/.john/john.rec (or whatever session name you gave it). If the process dies or you Ctrl-C it once (gracefully), you can resume:

$ ./john --restore=ntlm_attack1

If you Ctrl-C twice, John aborts immediately without saving. Don't do that. Once is the polite way.

Checking What Cracked

$ ./john --show hashes.txt

This reads the pot file (~/.john/john.pot) and prints every hash that was cracked along with its plaintext. You need to specify the same hash file and ideally the same --format flag you used when cracking, otherwise John gets confused about which pot entries match.

Mask Mode (Targeted Brute Force)

When you know the password pattern (e.g., "always 8 chars, starts with uppercase, ends with two digits"):

$ ./john --mask=?u?l?l?l?l?l?d?d hashes.txt

The mask syntax:

?u - uppercase letter
?l - lowercase letter
?d - digit
?s - special character
?a - any printable

This is way faster than a blind brute force because you're only searching the keyspace that makes sense.

The *2john Extractors (Secret Weapons)

John ships with a bunch of utility scripts that extract hashes from all kinds of files. These live in ~/src/john/run/ alongside the john binary:

Command	What It Extracts
`zip2john target.zip > zip.hash`	ZIP archive passwords (classic PKZIP and AES)
`rar2john target.rar > rar.hash`	RAR archive passwords (v3 and v5)
`pdf2john.pl protected.pdf > pdf.hash`	Encrypted PDF passwords
`keepass2john target.kdbx > kp.hash`	KeePass database master passwords
`office2john.py document.docx > office.hash`	Microsoft Office document passwords
`dmg2john image.dmg > dmg.hash`	macOS DMG disk image passwords
`ssh2john.py id_rsa > ssh.hash`	SSH private key passphrases
`hccap2john capture.hccap > wpa.hash`	WPA/WPA2 handshakes (from aircrack captures)
`bitlocker2john -i image.dd > bl.hash`	BitLocker recovery keys
`truecrypt2john volume.tc > tc.hash`	TrueCrypt/VeraCrypt volume passwords

The flow is always the same: run the extractor, pipe the output to a hash file, then feed that hash file to john. The extractor output includes the hash in a format john understands, plus metadata about the file.

Wait, Don't These Work With Hashcat Too?

Short answer: many do. Longer answer: yes, but.

Many *2john extractors produce hashes in a standardized signature format that hashcat also accepts - you just need to know the right -m mode number. For example:

zip2john file.zip > hash.txt then hashcat -m 13600 hash.txt wordlist.txt
keepass2john vault.kdbx > hash.txt then hashcat -m 13400 hash.txt wordlist.txt
office2john doc.docx > hash.txt then hashcat -m 9400/9500/9600/9700 hash.txt wordlist.txt

Hashcat even documents which modes correspond to which hash signatures. So if the extractor output is compatible and the hash type is a fast GPU-friendly one, routing it to hashcat makes perfect sense.

Where the Compatibility Breaks

There are three categories where things fall apart:

1. Size limits. Hashcat has internal buffer caps on ciphertext length for some formats, notably PKZIP/WinZip. If your encrypted ZIP contains a large binary file, the zip2john output can exceed hashcat's limit and you get "Oversized line detected! Truncated" errors. John has no such limit and cracks it fine. This is a known hashcat issue (github.com/hashcat/hashcat/issues/2186).

2. Encryption variant edge cases. Some ZIP encryption methods (particularly for binary files vs plaintext) produce hashes that John handles but hashcat rejects with "Separator unmatched" or "Signature unmatched." Same goes for edge cases in PDF encryption, certain RAR variants, and similar corner cases. The extractors handle the file format parsing correctly, but hashcat's hash parser is stricter.

3. Format coverage gap. John bleeding-jumbo supports ~400+ hash formats; hashcat supports ~300+. There are formats where John is the only practical cracker: SSH private keys (ssh2john), macOS DMG files (dmg2john), Bitcoin wallet.dat (bitcoin2john), GNOME Keyring, certain older TrueCrypt volume types, and more. For these, the *2john extractor is essential not because the output format is John-specific, but because John is the only tool that can actually crack that hash type.

The Real Value

The extractors are "half the reason to use JtR" not because they lock you into John, but because:

The extractors themselves handle file format quirks better than alternatives (edge cases in ZIP, PDF, Office encryption)
For the "weird" formats, John is often the only cracker that works at all
John auto-detects hash format - you don't need to memorize mode numbers
The sensible workflow is: use *2john to extract, then route fast hashes (NTLM, raw SHA, WPA2) to hashcat on GPU and keep the weird stuff on John

There's even a tool called Hashcatizer that reimplements *2john-style extraction but outputs explicitly hashcat-compatible hashes with the mode number included - which tells you the community sees value in bridging this gap in both directions.

Wordlists: Feed the Beast

SecLists (Still the GOAT)

Daniel Miessler's SecLists repo remains the definitive wordlist collection:

$ cd ~/
$ git clone https://github.com/danielmiessler/SecLists

This gives you rockyou.txt, the 10_million_password_list variants, and hundreds of other specialized lists. The SecLists/Passwords/ directory alone is a goldmine.

Other Good Sources

Probable-Wordlists (berzerk0 on GitHub) - passwords sorted by probability
CrackStation's wordlist - built from multiple breach compilations
Weakpass.com - large curated wordlists (some are enormous though, like 40GB+)
Hashes.org found lists - cleaned-up lists from real-world cracks

Creating Your Own

If you're targeting a specific org, a custom wordlist built from their website, documentation, employee names, and local sports teams can be surprisingly effective. Tools like CeWL (Custom Word List generator) spider a website and spit out wordlists:

$ sudo apt install -y cewl
$ cewl -d 5 -m 6 -w target_words.txt https://target-company.com

Once you have your wordlist, see Cewl/Cleaning Wordlists for techniques to trim out junk and extract the most useful words. For more wordlist resources, browse Category:Wordlists.

Transferring Hash Files to the Instance

You've got hashes on your laptop, your cracking instance is in the cloud. scp is the straightforward way:

$ scp -i my_key.pem hashes.txt ubuntu@<instance-ip>:~/hashes.txt

For bulk transfers or if you're iterating a lot, rsync is better:

$ rsync -avz -e "ssh -i my_key.pem" ./hashdir/ ubuntu@<instance-ip>:~/hashdir/

Also, don't sleep on just curl-ing files from a private S3 bucket or GCS if you're in the same cloud. Way faster than going through your laptop.

Pro Tips and Tricks

Listing Formats

John knows a frankly ridiculous number of hash formats:

$ ./john --list=formats | wc -l

To find the right format for your hash:

$ ./john --list=formats | grep -i ntlm
$ ./john --list=formats | grep -i wpa
$ ./john --list=formats | grep -i bitcoin

Incremental Mode (The Nuclear Option)

When wordlists and rules fail, incremental mode does a true brute force with statistical character frequency analysis. It's slow but it finds passwords that humans wouldn't think to put in wordlists:

$ ./john --incremental hashes.txt
$ ./john --incremental=digits hashes.txt  # numbers only
$ ./john --incremental=lanman hashes.txt  # optimized for LM hashes

Piping John to Other Tools

You can use John purely as a password generator by sending candidates to stdout:

$ ./john --wordlist=rockyou.txt --rules --stdout | head -1000

This makes it easy to pipe candidates into other tools. The classic use case is piping into aircrack-ng for WPA cracking (see the Aircrack and John the Ripper page for the full breakdown).

Hashcat Is Also a Thing

John is incredible for unusual hash formats and for the *2john extractor ecosystem. But if you're cracking a mountain of NTLM hashes or raw SHA-256, and you have a serious GPU, hashcat is faster for those common formats. The two tools complement each other. On a cloud GPU instance you can install both:

$ sudo apt install -y hashcat

Use John for the weird stuff (KeePass, RAR, SSH keys, DMG files) and hashcat for the bulk GPU-friendly formats. Best of both worlds.

Keeping John Updated

Since you cloned from git, updating is trivial:

$ cd ~/src/john
$ git pull origin bleeding-jumbo
$ cd src
$ make -s clean && make -sj$(nproc)

New hash formats and optimizations land on the bleeding-jumbo branch all the time. A git pull every few weeks keeps you current.

Spot Instances and Session Safety

If you're using spot/preemptible instances (and you should be, they're like 70% cheaper), your instance can vanish at any moment. Two things save you:

First, always use --session so John saves state periodically. Second, back up the ~/.john/ directory and your pot file to persistent storage (S3 bucket, GCS, whatever) regularly. A simple cron job:

$ crontab -e
# Every 30 minutes, sync john state to S3
*/30 * * * * aws s3 sync ~/.john/ s3://my-cracking-bucket/john-state/

When your spot instance gets reclaimed and you spin up a new one, pull the state back down, re-clone and build John, and --restore. You lose at most 30 minutes of progress.