Step 91. Linux Review — OverTheWire Bandit 0–10

Level 1 — Programming and the Inside of a Computer | Difficulty ★★☆☆☆ | Estimated time: 3 hours

Prerequisites: basic Linux commands from Steps 18–20 (ls, cd, cat, find, grep, etc.). A Linux terminal (including WSL) is ready.

• What you need: internet, an SSH client (built into PowerShell on Windows 10+, built into the terminal on macOS/Linux), and one local Linux terminal (WSL). Open a notepad (or your wiki) in advance — if you don’t record the passwords you find, you can’t proceed to the next level.
• Caution: ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. OverTheWire Bandit is an official legal wargame "built for you to attack," so connecting to that server itself is legal. The command measurements in this chapter were performed in a /tmp practice ground on local WSL (Ubuntu 24.04), and platform connection screens are marked as output examples.

Today, for the first time, you connect to a server out there. But that server is a legal practice ground "built for you to attack" — OverTheWire Bandit. The rules are simple — SSH into each level’s server and find the "next level’s password" hidden somewhere. Find it, and you use that password to connect to the next level. Your weapons aren’t flashy hacking tools but basic commands like ls, cat, and find. This is the day the Linux basics you learned at Level 0 change from "textbook knowledge" into "keys that open doors."

1. Learning Objectives

By the end of this chapter, you will be able to:

• Connect to and exit a remote server over SSH (ssh user@address -p port)
• Correctly handle special filenames like files starting with - and names containing spaces
• Choose ls -a, file, find, grep, sort | uniq, strings, base64 -d, and tr appropriately for the situation
• Filter out error output with 2>/dev/null
• Leave a per-level password chain and solution notes as a document

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

2-1. SSH — A Door for Legally Entering Someone Else’s Computer

SSH (Secure Shell) is a protocol that brings a remote computer’s terminal onto your screen. The communication is encrypted, and connecting requires an ID and a password (or a key). The syntax is ssh user@address -p port — this single line is today’s first gate.

All of Bandit’s connection info is published on the official site. That server is a practice ground deliberately left open to be used that way. This is important: "a practice server with its address and password published" and "someone else’s server" are as different as heaven and earth. The former is a classroom; entering the latter without permission is a crime.

2-2. Wargame Thinking — Reading the Problem Is Half the Battle

On each Bandit level’s official page (overthewire.org/wargames/bandit), you’ll find things like this:

• Level Goal: what to find on this level (mostly "a hint about where the next password is hidden")
• Commands you may need: a list of commands that might be needed

Half the answer is already here. Does "commands you may need" list file? Then this problem is about figuring out a file’s true identity. Read the hints → try → if stuck, read the command’s manual (man) — this cycle is the official solution method of wargames.

2-3. The Password Chain — Records Are Your Lifeline

You must find level N’s password to proceed to level N+1. In other words, a password isn’t use-once-and-discard — it’s the next link in the chain. Record each one as you find it, in the form bandit5: foundstring. If the session drops or you come back tomorrow, without records you’re back to the beginning. This isn’t a game where your files are saved on the server — the password itself is your progress. Sessions are temporary; records are permanent.

3. Follow Along

Platform connections and problem screens are shown as output examples, while the core commands are set up so you can reproduce them directly on your own WSL (in a /tmp practice ground). Every measurement in this chapter was performed in a practice ground on local WSL.

3-1. First SSH Connection — Level 0

Input

ssh bandit0@bandit.labs.overthewire.org -p 2220

Output example (platform connection screen — may vary by environment):

The authenticity of host '[bandit.labs.overthewire.org]:2220' can't be established.
...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
bandit0@bandit.labs.overthewire.org's password:        ← enter bandit0 (it's normal that nothing shows)

How to read it: the first time you connect to a server, a fingerprint check asks "do you trust this server?" — type yes. When the prompt changes to something like bandit0@bandit:~$, you’ve succeeded. Your terminal is now inside someone else’s computer (a legal practice ground).

Why: Level 0’s goal is the connection itself. Getting the SSH syntax user@address -p port into your body is the first harvest.

3-2. Level 0 → 1: Reading the readme

You’re inside the server. The goal page says "the password is in the readme file in the home directory."

Input

ls
cat readme

Output example: you see a single file named readme, and reading it with cat shows a long string — that’s bandit1’s password.

How to read it: see files with ls, read with cat. Linux’s two most basic actions are the first problem’s answer. Write down the string you found right now.

Why: this is the stage for learning the wargame’s rhythm. Read the problem → look → read.

3-3. Level 1 → 2: A Strangely Named File — Practice on WSL

For the next level, exit with exit, then connect with ssh bandit1@... -p 2220 (using the password you just found). This goal: "it’s in a file named -."

You can reproduce this problem identically on local WSL. Let’s make a practice ground.

Input (WSL)

mkdir -p /tmp/banditlab && cd /tmp/banditlab
echo "fakePASSlevel2" > ./-
cat -

Output (measured 2026-09-09, WSL Ubuntu 24.04): cat - doesn’t read the file and instead waits for input. In the command world, - has the special meaning of standard input, so it wasn’t recognized as a file. Escape with Ctrl+C.

Fix

cat ./-

Output (measured 2026-09-09):

fakePASSlevel2

How to read it: ./- is an explicit path meaning "the file named - in this folder." Writing it as a path avoids the special interpretation.

Why: Bandit lesson #1 — if a filename collides with command syntax, attach a path. Real-world accidents with files named like -rf actually happen, so this is worth making a habit.

3-4. Level 2 → 3: Filenames with Spaces

Goal: "it’s in a file whose name contains spaces." Continuing with the same kind of experiment.

Input

echo "fakePASSlevel3" > "spaces in this filename"
cat spaces in this filename

Output (measured 2026-09-09):

cat: spaces: No such file or directory
cat: in: No such file or directory
cat: this: No such file or directory
cat: filename: No such file or directory

Fix

cat "spaces in this filename"

Output (measured 2026-09-09): fakePASSlevel3

How to read it: typed without quotes, the words get split at the spaces and it fails looking for four files. Wrapped in quotes, the whole thing including spaces becomes one name. If you autocomplete the filename with the Tab key, the shell escapes it for you (inserting before spaces).

Why: handling spaces is basic courtesy in shell usage. Later, when you write scripts, missing quotes are a regular cause of major accidents.

3-5. Level 3 → 4, 4 → 5: Hidden Files and a File’s True Identity

Level 3’s goal: "it’s in a hidden file in the inhere folder."

Input

mkdir -p inhere && echo "fakePASSlevel4" > inhere/.hidden
ls inhere
ls -a inhere

Output (measured 2026-09-09):

# ls inhere — nothing shows
# ls -a inhere
.  ..  .hidden

How to read it: files starting with . are invisible to a plain ls. -a (all) reveals hidden files. Read it with cat inhere/.hidden.

Level 4’s goal: "among the many files in the inhere folder, it’s in the single one that’s human-readable."

Input

printf "fakePASSlevel5n" > inhere/-file07
head -c 100 /dev/urandom > inhere/-file03
file ./inhere/-file03 ./inhere/-file07

Output (measured 2026-09-09):

./inhere/-file03: data
./inhere/-file07: ASCII text

How to read it: the file command looks at a file’s contents and tells you "this file’s true identity." The key point is that it judges by content, not by name. The one file judged ASCII text is the answer. Note also that we attached ./ because the filenames start with - — the lesson from 3-3 got recycled immediately.

Why: these two problems are the very basics of breach analysis — see what’s hidden (ls -a) and identify what things are (file). Files left by an intruder are mostly hidden or disguised by name.

3-6. Make a Prediction — Conditional Search with find

Level 5’s goal looks like this: "among the files somewhere in the inhere folder, it’s in the one that is human-readable, 1033 bytes in size, and not executable."

Prediction: the folder holds dozens of subfolders and files. Instead of opening them one by one with file, what command finds it in one shot?

Check for yourself (WSL practice ground)

python3 -c "open('inhere/-file09','w').write('x'*1033)"
find inhere -type f -size 1033c ! -executable

Output (measured 2026-09-09):

inhere/-file09

How to read it: it’s find where-to-search -conditions. -type f (files only), -size 1033c (1033 bytes — c means bytes), ! -executable (not executable — ! is negation).

Why: in security work, find is the standard tool for the request "find files matching conditions across the whole server." Finding web shells, finding recently modified files — all are applications of find.

3-7. Levels 6–10 — The Section Where Tools Accumulate

A map of the remaining levels, plus local practice for each command.

• 6→7: find a file "owned by a specific user, of a specific size" across the whole server. Combine -user, -group, -size on find /. Errors pour out from folders you lack permission for, so discard them with 2>/dev/null.
• 7→8: the password is "next to the word millionth" in a huge text file.

Input (WSL practice)

printf "foonmillionth fakePASSlevel8nbarn" > data.txt
grep millionth data.txt

Output (measured 2026-09-09):

millionth fakePASSlevel8

• 8→9: find "the line that appears exactly once."

Input

printf "aaanbbbnbbbnaaanONLYONCEncccncccn" > uniqdata.txt
sort uniqdata.txt | uniq -u

Output (measured 2026-09-09):

ONLYONCE

How to read it: uniq only sees adjacent duplicates, so sort must come first, without fail. Sorting first, deduplication second — this order is level 8’s answer structure.

• 9→10: find the readable string inside a binary file. In Bandit, the password has several = signs in front of it.

Input

printf "==========n3f3f3f3f3fn========== the password is fakePASSlevel10n7x7x7x7x7x7xn" > bin.dat
head -c 500 /dev/urandom >> bin.dat
strings bin.dat | grep "=="

Output (measured 2026-09-09):

==========
========== the password is fakePASSlevel10

How to read it: strings picks out only "human-readable stretches" from a binary blob. Even amid the mixed-in garbage bytes (/dev/urandom), it filtered out just the two sentences.

• 10→11: decode base64-encoded data.

Input

echo "The password is fakePASSlevel11" | base64
echo "VGhlIHBhc3N3b3JkIGlzIGZha2VQQVNTbGV2ZWwxMQo=" | base64 -d

Output (measured 2026-09-09):

VGhlIHBhc3N3b3JkIGlzIGZha2VQQVNTbGV2ZWwxMQo=
The password is fakePASSlevel11

How to read it: base64 translates, base64 -d reverses. Seeing the = tail at the end, you can suspect Base64 (review from Step 50).

The official procedure when stuck: struggle for 20 minutes → re-read the level page’s "commands you may need" → read that command’s man page (or --help). If it still doesn’t work, find someone else’s write-up and read it — but understanding it, then closing the window and typing it again by hand is what counts as solving.

3-8. The Feel of Pipes — Assembling Commands Like LEGO

Let’s decompose the sort | uniq -u from level 8→9. The vertical bar | is called a pipe, and it means "pass the left command’s output into the right command’s input."

Input

printf "applenbanananapplencherryn" > fruits.txt
cat fruits.txt | sort
cat fruits.txt | sort | uniq -c

Output (measured 2026-09-09):

apple
apple
banana
cherry
      2 apple
      1 banana
      1 cherry

How to read it: what cat spat out went not to the screen but into sort‘s mouth, and then into uniq -c‘s mouth. uniq -c counts adjacent identical lines. A two-stage factory of "sort → count" was connected by pipes.

Why: the philosophy of Linux commands is "make each small tool do one thing well, and assemble with pipes." Bandit’s later problems are almost all assembly problems like this, and real-world log analysis works exactly this way. A single line like cat log | grep ERROR | sort | uniq -c | sort -nr becomes a summary of a day’s worth of logs.

Bonus — tr: in a higher level (11→12), a substitution cipher called ROT13 appears. It’s the alphabet shifted by 13 letters, and one line of tr reverses it.

echo "Gur cnffjbeq vf snxrCNFF" | tr "A-Za-z" "N-ZA-Mn-za-m"

Output (measured 2026-09-09): The password is fakePASS — tr "letters to change" "new letters" is position-for-position substitution.

4. Missions & Exercises

Mission — Completing the Level 0→10 Chain + a Command Summary Document

1. Complete SSH connections from bandit0 through bandit10, and record 11 passwords.
2. Write bandit-0-10.md in your wiki — 3 lines per level: "what the problem asked / commands used / lesson learned."
3. Add a one-line summary for each command you met today (file, find, strings, base64, uniq, tr).
4. Reproduce all of the chapter’s WSL practice-ground exercises (3-3 through 3-8) on your own computer, and attach the outputs to the document.
5. Record today’s mistakes (e.g., the cat - incident) in your troubleshooting document.

Exercises

Exercise 1. Explain why cat - can’t read the file, and state two fixes (one more besides attaching a path). (Hint: input redirection like cat < ./-)

Exercise 2. In find inhere -type f -size 1033c ! -executable, explain what each condition means and the role of !.

Exercise 3. In sort data.txt | uniq -u, explain why removing sort fails to properly find "the line that appears exactly once."

Exercise 4. You ran find / conditions and "Permission denied" errors plastered the screen. Which level’s problem does this situation come from, and write the command form that leaves only normal results.

bandit0: bandit0 (the published initial password)
bandit1: <string found in readme>
bandit2: <string found with cat ./->
...

[Level 2 → 3]
- What the problem asked: read a file whose name contains spaces
- Commands used: ls → cat "spaces in this filename"
- Lesson learned: wrap filenames with spaces in quotes. Tab autocompletion escapes them too.

6. Common Pitfalls & Fixes

Wall 1. The ssh connection drops right away

Symptom: the connection closes as soon as you connect, or the password is rejected.

Cause: one of three — missing port (-p 2220), a typo in the password, or a mismatch between username and level (connecting to bandit0 with bandit1’s password, etc.).

Fix: slowly re-check the command. It’s normal for the password to be invisible on screen, and watch for leading/trailing spaces when copy-pasting. If you’re unsure about pasting, type it by hand.

Wall 2. Running find floods "Permission denied"

Symptom: error messages plaster the screen and bury the answer.

Cause: find / rummages through the whole server and throws an error for every folder you lack permission for.

Fix: the magic that discards errors — find / conditions 2>/dev/null. Only normal results remain.

Wall 3. I ran cat – and it froze with no output

Symptom (measured 2026-09-09): the command doesn’t finish and the cursor just blinks.

Cause: - has the special meaning of standard input, so cat is waiting for keyboard input.

Fix: escape with Ctrl+C (or Ctrl+D), then attach a path like cat ./-. This rule works for every command on filenames starting with -.

Wall 4. I found the password but the next level won’t open

Symptom: connecting with the string you just found is rejected.

Cause: mostly a leading/trailing space or newline that came along when copying. Occasionally the file you read was for a different level, not "the next" one.

Fix: type the string by hand. If it still fails, re-check the goal page to confirm the file you read was really "for the next level."

Wall 5. I ran sort | uniq -u and multiple lines came out

Symptom: "the line that appears exactly once" isn’t a single line.

Cause: uniq only sees adjacent duplicates. If you drop sort, it can’t catch scattered duplicates.

Fix: check the pipe order — it must be sort data.txt | uniq -u. Sorting first, deduplication second (see the measurement in section 3-7).

7. Summary

Today’s Concepts

Today’s Commands

An Instinct More Important Than Commands

People who’ve done Bandit say one thing in common — "I didn’t learn difficult commands; I learned how to pull hints out of a problem and connect them to commands." Real-world breach analysis is the same. A log line, a file — those are the problems, and your toolbox is the answer. Reading "which tool is needed right now" matters more than knowing tools — that’s this chapter’s true harvest.

And don’t forget the record-keeping habit. Even if your internet drops mid-wargame, your progress doesn’t vanish — the password itself is the progress, and with the recorded chain alone you can jump straight back in anytime with ssh bandit7@.... The moment you open level 10’s door, you change from "a person who knows Linux commands" into "a person who solves problems." You’ve crossed the eleven hills of your first wargame, and the wiki document you made along the way is your first wargame conquest record.

Once every box is checked, Step 91 is complete.