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 hour went somewhere else entirely: the intended one-liner refused to connect for me, and the way out was a command I’d been staring at the whole time without reading it.

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

bandit13@bandit:~$ 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:

bandit13@bandit:~$ ssh -i sshkey.private bandit14@localhost -p 2220

That did not work for me. And I lost a long time here, because the failure was in the wrong place — I checked the key over and over, and the key was fine every time. Healthy, right permissions, correct format. Localhost just kept refusing.

What eventually got me out was reading the level page’s list of commands you might need for it. scp is on that list. 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:

bandit14@bandit:~$ 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 actual concept this level is teaching and it’s worth separating from the hour of pain around it.

When a level lists the commands you might need, read the list. scp was sitting there the entire time. I treated it as reference material instead of as the hint it was, and that cost me most of the hour.

And when the same check passes ten times, stop checking it. I kept re-verifying the key because that was the part I knew how to verify. The key was never the problem. Ten identical passes is information — it means the fault is somewhere you haven’t looked yet.