SSH Authorized Keys Persistence: Detection and Response
SSH authorized_keys persistence detection covers file changes, cloud metadata, key fingerprints, writers, login evidence, scope, containment, and hardening.
Trace every path that can authorize an SSH key
SSH authorized_keys persistence detection monitors more than a text file. MITRE ATT&CK T1098.004 describes local edits, scripts, cloud APIs, instance metadata, network-device configuration, macOS, Linux, and ESXi paths.
Resolve the effective AuthorizedKeysFile, included SSH configuration, user home directories, cloud guest agents, configuration-management sources, and privileged APIs. A file can be regenerated after deletion if the upstream authority remains compromised.
Inventory keys by fingerprint, owner, source, and expiry
Parse effective authorized-key files and record host, account, path, file owner and mode, key type, SHA-256 fingerprint, options, comment, approved owner, provisioning source, ticket, first seen, last verified, and expiry. Do not centralize private keys.
Baseline high-risk accounts first: root, backup, hypervisor, database, automation, and shared administration. Comments are labels, not trustworthy identity. Fingerprints and approved provenance are the durable comparison fields.
Correlate file changes with writer and later authentication
Detect create, append, overwrite, rename, permission change, alternate-path configuration, and guest-agent or metadata updates. Capture process tree, command line, effective user, container or host, package or automation context, file hash, before-and-after key fingerprints, and cloud audit actor.
Raise confidence for root targets, unknown fingerprints, interactive shell writers, encoded commands, disabled host controls, or successful SSH authentication soon afterward. Expected configuration management should match a signed change, known runner, approved fingerprint, and narrow window.
Remove the key only after preserving its provenance
Follow security alert triage: preserve file content, metadata, filesystem journal where available, process evidence, SSH logs, cloud audit, and configuration-management history. Determine first seen, affected accounts, successful uses, source IPs, commands, and privilege reached.
Isolate the host when compromise is likely, remove the unauthorized key from every upstream and local source, rotate other exposed credentials, revoke cloud sessions, rebuild highly trusted systems when integrity is uncertain, and hunt the fingerprint fleet-wide.
Reduce standing SSH authority and privileged paths
Disable SSH where unnecessary, prohibit direct root login, restrict users and networks, enforce file ownership and modes, prefer short-lived certificates or centrally governed access, and apply the principle of least privilege to metadata and VM-update APIs. Integrate key inventory into system hardening.
Prove one test key is detected and removed end to end
Next step: on an isolated test host, add an approved disposable public key through the normal provisioning path. Verify the file and control-plane events, fingerprint inventory, alert enrichment, authorized login record, removal from every source, and non-return after agent reconciliation. Never plant a key on production without explicit authorization.
Frequently asked questions
Is deleting the unknown SSH key enough?
No. Preserve the key and file metadata, investigate how it was added, rotate exposed authority, review successful logins, and repair the original access path.
Is ~/.ssh/authorized_keys the only location to monitor?
No. SSH server configuration can define alternate files, and cloud metadata, agents, configuration management, network devices, and hypervisors can provision keys.
