Public-key authentication is how most SFTP and SSH access is really granted, and the private keys are poorly guarded. They turn up in readable file shares, backups, container images, and source repositories; they are frequently stored without a passphrase; and some are weak or were generated by known-vulnerable tooling. A recovered private key authenticates as its owner with no password at all, and conversely, writing an attacker-controlled public key into a target's authorized_keys grants durable access. Keys are also widely reused across hosts, so one leaked key often opens many.
# use a recovered private key
chmod 600 id_rsa; ssh -i id_rsa user@<target>; sftp -i id_rsa user@<target>
# if the key has a passphrase, crack it offline
ssh2john id_rsa > hash && john --wordlist=rockyou.txt hash
# plant a key for durable access where you can write authorized_keys (e.g. via NFS/SMB
# write to a home dir, or an SFTP account whose home you can modify)
echo 'ssh-ed25519 AAAA... attacker' >> /mnt/victim-home/.ssh/authorized_keys
Exploitation notes#
- Hunt for private keys wherever files are readable: shares (
id_rsa,*.pem,*.ppk), backups,.githistories, and images; a passphraseless key is immediate access, a passphrased one is crackable offline withssh2john. - Key reuse is the force multiplier: the same key often authorizes the owner on many hosts, so a single find can open a fleet; map where the public half appears.
- Writing
authorized_keysis both an access and a persistence primitive; combine with a file-write primitive on the target's home (an NFS UID-spoof write, a writable SMB home, or an existing SFTP write) to plant a key. - Keys from known-vulnerable generators (weak entropy) are predictable and worth checking against known-bad key sets.