Detecting SSH authorized_keys Persistence on Linux

Appending an attacker’s public key to ~/.ssh/authorized_keys gives durable, password-less access that survives credential resets and looks like ordinary SSH. Cloud-focused and cryptomining campaigns do this routinely, and so do operators who want a fallback once the first foothold is lost. Detection combines file-change monitoring, inventory of authorised keys and logging of which key was used.

Signals at a Glance

Watching the Key Files

Start with write detection on the files that grant access. auditd cannot wildcard home directories, so generate per-user watches from your inventory or configuration tooling, and always include root and system accounts such as www-data, postgres and git:

# /etc/audit/rules.d/ssh-keys.rules
-w /root/.ssh/ -p wa -k ssh_keys
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config
# Per-user watches: generate these for each account that has a home directory, for example
# -w /home/alice/.ssh/authorized_keys -p wa -k ssh_keys
# -w /var/lib/postgresql/.ssh/ -p wa -k ssh_keys
# Where kernel and EDR coverage allow, prefer a path regex over per-user rules:
#   TargetFilename matches /\.ssh/authorized_keys2?$ with a write or rename action
# tune/validate: legitimate writers are provisioning tools and cloud-init; filter on exe and auid.

Real-time rules miss keys planted before monitoring began. Inventory the keys on every host with osquery and compare them with the keys you expect. The query returns the owner, key comment and file modification time, so a key added since the last review stands out:

-- osquery: authorized keys per user, with file modification time
SELECT u.username,
       ak.key_file,
       ak.algorithm,
       ak.comment,
       substr(ak.key, 1, 24) AS key_prefix,
       datetime(f.mtime, 'unixepoch') AS file_mtime
FROM users u
JOIN authorized_keys ak USING (uid)
JOIN file f ON f.path = ak.key_file
ORDER BY f.mtime DESC;
-- tune/validate: key comments are attacker-controlled; compare key material or fingerprints, not comments.

Detecting Use of a Planted Key

• Set LogLevel VERBOSE in sshd_config. sshd then logs the fingerprint of the key used on each successful public-key login, for example Accepted publickey for user from ip ... SHA256:....
• Maintain an allowlist of expected fingerprints per host or role, and alert on any successful key login with a fingerprint outside it.
• Alert on the combination of a recent authorized_keys write and a first-seen source IP for that account within the following hours.
• Review AuthorizedKeysCommand and AuthorizedKeysFile in sshd_config, since an attacker who controls those can bypass per-user file monitoring entirely.
• Remove the root cause during response: rotate the exposed credentials, remove unrecognised keys on every host, and check for other persistence listed in the cron and systemd guide.
• In cloud environments, enforce key management centrally (instance metadata, certificate-based SSH or a bastion) so local authorized_keys edits become an exception worth alerting on.