Bandit 18 → 19: a shell that quits before you can type

This one sabotages .bashrc so that logging in throws you straight back out. It looks exactly like a connection being refused, which is the trap — and the answer is sitting in the wording of the goal.

the goal

The password for the next level is stored in a file readme in the homedirectory. Unfortunately, someone has modified .bashrc to log you out when you log in with SSH.

the approach

The first attempt drops you back at your own prompt, which reads as the box refusing to let you connect at all.

That reading is wrong, and the level statement says so: log you out, not keep you out. You can only be logged out of something you were logged into. So the password is accepted, authentication succeeds, the box hands over a shell — and the shell immediately kills itself, because .bashrc is a script bash runs at startup and someone has put an exit in this one. From outside, a session that dies in its first half-second is indistinguishable from one that never opened.

Which reframes the problem. Nothing needs to stop .bashrc running. The box just needs to do one thing for me without handing me an interactive shell to sit in:

ssh bandit18@bandit "cat readme"

(bandit there is my local shorthand for the game server — the full form is bandit18@bandit.labs.overthewire.org -p 2220.)

bandit18@bandit.labs.overthewire.org's password:
<password>

The password comes back and the session is over before .bashrc matters. No need to look at what’s in that file at all — once the shape of the problem is clear, there’s nothing in there you need.

the takeaway

An argument after the host changes what ssh asks for. ssh host requests an interactive login shell; ssh host "command" asks the remote end to run that command and hand back its output — a non-interactive shell, which takes a different startup path.

Worth being precise about that, because it’s fiddlier than “non-interactive means no startup files.” man bash’s INVOCATION section is where the rules live, and it documents a special case: when bash detects its input is a network connection, it reads ~/.bashrc even non-interactively. Which is why the usual first line of a stock .bashrc is a guard that returns early when the shell isn’t interactive. Read the section once properly rather than guessing at it forever — the answer to “will my .bashrc run” is genuinely conditional.

“It won’t connect” is a conclusion, not an observation. The observation is ending up back at your own prompt. Connection refused, auth failure, and connect-then-immediately-exit all produce that, and they need completely different fixes. The level’s own wording separates them — log you out means that at some point, you were in.