Bandit Level 13 → 14

Login: ssh bandit13@bandit.labs.overthewire.org -p 2220
(you already logged in as bandit13 and found sshkey.private in the home directory)

Task

You are given a private SSH key file (sshkey.private) in the bandit13 home directory. Use that key locally to connect to the bandit14 account. After you successfully ssh to bandit14, read the file /etc/bandit_pass/bandit14 to get the next level password.

---

Quick solution (commands)

# copy the private key from the remote host to your local machine
scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .

# secure the key locally (OpenSSH requires strict permissions)
chmod 600 sshkey.private

# use the key to login as bandit14
ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org

# once logged in as bandit14, read the password for the next level
cat /etc/bandit_pass/bandit14

---

Theory (a bit more — why this works)

1. Public-key SSH authentication

   • Instead of a password, SSH can use an asymmetric key-pair: a private key (which you keep secret) and a public key (stored on the server).
   • If the server has the corresponding public key in the authorized_keys of an account, SSH proves you own the private key and logs you in as that account.
   • In this level you were given the private key for bandit14. Possessing that key is equivalent to having the password for bandit14 (for authentication purposes).

2. scp

   • scp copies files over SSH. The -P 2220 option tells scp to use port 2220 (Bandit uses that port).
   • Example: scp -P 2220 bandit13@...:sshkey.private . copies sshkey.private from the remote bandit13 home to your current local directory.

3. File permissions matter

   • OpenSSH refuses to use private key files that are readable by group or others. If a private key file is group/world-readable SSH prints a warning like:

     Permissions 0640 for 'sshkey.private' are too open.

   • The correct permission for private keys is `` (-rw-------) so that only the file owner can read/write it. 700 (-rwx------) also works but is non-standard (private keys usually don't need execute bit).
   • Use chmod 600 sshkey.private to fix permissions.

4. Windows line endings

   • If the key was moved through Windows or edited with a Windows editor, it may contain CRLF ( ) line endings. SSH expects Unix LF ( ). Convert with dos2unix or a tr command if needed.

5. Troubleshooting

   • If SSH refuses to authenticate, add verbose output to see why:

     ssh -vvv -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org

     Look for messages about Offering public key and Authentication succeeded or Permission denied.
   • If you still get Permission denied (publickey), confirm:
     • The key file content is intact (no accidental edits).
     • File permissions are 600 and ownership is your user.
     • You used the correct user (bandit14) and port (2220).

6. ssh-agent alternative

   • Instead of passing -i every time, add the key to your agent (keeps it in memory):

     ssh-add sshkey.private
     ssh -p 2220 bandit14@bandit.labs.overthewire.org

---

Full explained session (step-by-step)

1. On the remote server (bandit13) — you discovered the key:

bandit13@bandit:~$ ls
sshkey.private

2. From your local machine — copy the key here for use:

scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .
# you will be prompted for the bandit13 password

3. Secure the key file

# make it readable only by you
chmod 600 sshkey.private
# verify
ls -l sshkey.private
# output should look like: -rw------- 1 youruser yourgroup 1675 Sep 19 12:34 sshkey.private

4. Attempt SSH using the key

ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org

• On first connect you'll likely be asked to accept the host fingerprint — answer yes.
• If the key works you'll be dropped into a shell as bandit14.

5. Read the next-level password

cat /etc/bandit_pass/bandit14
# this prints the password you need for the next level

---

Example (what you might see)

$ scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .
bandit13@bandit.labs.overthewire.org's password:
sshkey.private                          100% 1675   1.6KB/s   00:00

$ chmod 600 sshkey.private
$ ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org
The authenticity of host '[bandit.labs.overthewire.org]:2220 ([IP]:2220)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Welcome to bandit...
$ cat /etc/bandit_pass/bandit14
<the-password-for-bandit15>

---

Cleanup & security reminder

• This is a game environment, but in real life never share private keys publicly (e.g., push them to GitHub). Remove keys from your local machine when you no longer need them:

shred -u sshkey.private   # securely delete
# or simply: rm sshkey.private

• If you ever suspect a private key has been exposed, revoke it on the server (remove the corresponding public key from ~/.ssh/authorized_keys) and generate a new key pair.

---

If you want, I can:

• shorten this into a one-page README.md suitable for GitHub, or
• create a small diagram explaining public/private key flow, or
• add the exact ssh -vvv debugging output to the doc (if you paste your session output).

Tell me which you prefer and I will update the file.

<!-- truncate -->