Bandit 13 → 14: the key that wouldn't open the door next to it

This level stops handing you a password and hands you a private key instead. That part is a five-second conceptual jump. The interesting part is what happens when the intended one-liner refuses to connect — the way out is a command sitting on the level page the whole time.

the goal

The password for the next level is stored in /etc/bandit_pass/bandit14 and can only be read by user bandit14. For this level, you don’t get the next password, but you get a private SSH key that can be used to log into the next level.

the approach

ls

sshkey.private

So: no password to copy this time. The key is the credential. ssh -i <keyfile> is how you present one instead of typing a password, and the intended move is to hop to bandit14 on the same box:

ssh -i sshkey.private bandit14@localhost -p 2220

That one refused to connect, and the failure points at the wrong thing. The key checks out every time — healthy, right permissions, correct format — while localhost keeps refusing. The key was never the problem.

The way out is on the level page: scp is in its list of commands you might need. That’s not decoration, it’s the hint.

scp is cp over SSH: it copies files between machines. So instead of using the key on the box, pull the key down to my own machine and connect from there like any normal SSH login:

# from my machine, not from bandit13
scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .
chmod 600 sshkey.private
ssh -i sshkey.private bandit14@bandit.labs.overthewire.org -p 2220

Two things to flag in there. The port flag on scp is a capital -P — ssh uses lowercase -p for the same thing, and they are not interchangeable. And chmod 600 isn’t optional: SSH refuses to use a private key that other users on your machine can read, and it fails with a wall of UNPROTECTED PRIVATE KEY FILE rather than anything about permissions being the fix.

That got me in as bandit14, and then the password is just sitting there to be read:

cat /etc/bandit_pass/bandit14

the takeaway

A key is a credential you hold, not one you memorise. -i is how you present it; everything else about the SSH command is unchanged. That’s the concept the level is actually teaching.

When a level lists the commands you might need, read the list. scp sits there the whole time, easy to mistake for reference material rather than the pointer it is.

When the same check passes ten times, stop checking it. Re-verifying the key is the natural move, because it’s the part you know how to verify. Ten identical passes is information: the fault is somewhere you haven’t looked yet.