A method of maintaining access by adding an attacker-controlled public key to a user’s authorized keys file. After privilege escalation, this allows repeated login without needing the original exploit. It is a common post-compromise technique because it survives simple password resets and user account changes.
How persistence via SSH keys works
Persistence via ssh key is a post-compromise access technique, not just a login method. The attacker adds a public key to a target account’s authorized_keys file, then uses the matching private key to return repeatedly, often without touching the original exploit path again.
The technique is effective because it turns a one-time intrusion into a durable access channel. If the key is placed on an account with elevated permissions, or if the account later gains those permissions, the attacker can retain access even after the initial vulnerability is patched or the original password is changed. That is why SSH-key persistence often appears alongside privilege escalation and lateral movement in intrusion chains.
In practice, this is a relationship between access control and post-exploitation tradecraft. The attacker is not “breaking SSH” in the abstract; they are abusing a legitimate authentication mechanism and a trusted administrative pathway. Public-key authentication is normal and widely deployed, which makes the malicious change easy to miss unless key ownership, file integrity, and account changes are monitored closely. For broader context on how long-lived credentials and excess privilege expand exposure, see Ultimate Guide to NHIs.
A useful way to think about this technique is that the persistence lives at the account layer, while the exploit that enabled it may live elsewhere. Once the key is installed, defenders can remove the initial foothold and still leave a backdoor in place if they do not inspect authorized keys, account metadata, and privileged access paths.
Why attackers use SSH key persistence
Attackers favour SSH keys because they are durable, low-noise, and operationally simple. A key-based backdoor does not depend on a remembered password, password reuse, or the continued presence of the original vulnerability, so it survives many routine cleanup actions.
It is especially attractive after privilege escalation because the attacker can bind persistence to an account that already has strong access. In that case, the same key can support repeated administrative login, command execution, and deeper system compromise. If the account is used by multiple administrators or automation processes, the malicious key can blend into normal operational activity unless ownership is tracked carefully. The post-compromise value of this pattern is also visible in Salt Typhoon US telecoms breach, where stolen credentials and follow-on access supported sustained intrusion.
SSH key persistence also scales well for attackers. One implanted key can provide repeated access across reboots, password changes, and some account resets, and it can be copied into additional accounts to widen the foothold. That makes it a common choice when the attacker intends to remain undetected for weeks or months rather than exfiltrate data immediately.
Because the method uses standard SSH behaviour, detection often depends more on change monitoring than on protocol inspection. A normal-looking key entry can become malicious the moment it is added by an unauthorised actor, which is why file integrity, privileged session review, and account ownership matter more than the transport itself.
How organisations detect and remove SSH key persistence
Detection starts with identifying unauthorized changes to authorized keys, home directories, and account records. A sudden new key, an unfamiliar comment field, or a key added outside normal provisioning flow can all indicate persistence. On Linux systems, the most important evidence is usually not the SSH connection itself, but the file and account changes that made the connection possible.
Removal requires more than deleting one key. Organisations should confirm whether the attacker created backup accounts, copied keys to other users, modified shell startup files, or paired the key with other persistence mechanism. If the original compromise path is still open, removing the key only creates a temporary interruption. The same is true if the attacker still holds another credential, token, or remote management path. For operational guidance on credential hygiene and rotation patterns, the Ultimate Guide to NHIs is a useful reference point, especially where long-lived access material remains valid after a breach.
Good response also includes key provenance review. Teams should verify who created the key, when it appeared, which hosts accepted it, and whether the account should have had that access in the first place. If the account is privileged, rebuilding trust may require more than key removal, including password resets, session revocation, and host-level integrity checks.
Because SSH keys are often stored as plain text in user profiles, source control, deployment scripts, or shared admin tooling, the removal process should also include a search for duplicate copies. Attackers commonly preserve persistence by leaving the same key in multiple places, or by recreating it after the first cleanup if they still have access to an adjacent system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | Covers adding SSH keys to preserve account access after compromise. |
| Recommendation — Monitor for unauthorized account changes and investigate added SSH keys as persistence. | ||
| CIS Controls v8 | 6 — Access Control Management | Requires managing and revoking account access, including unauthorized key-based access paths. |
| Recommendation — Revoke unapproved SSH keys and tighten account access approval and review. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Addresses access control and credential trust needed to prevent key-based persistence. |
| Recommendation — Enforce least-privilege access and review authentication artifacts for unexpected SSH keys. | ||
Practitioner Guidance
What to watch for: Treat unexpected changes to authorized_keys as an access event, not just a configuration change. The key question is whether the new key matches approved ownership, role, and lifecycle controls for that account.
Governance implication: Assign explicit ownership for privileged SSH access and define who can approve, add, and review keys. If no one owns the key lifecycle, persistence can survive long after the initial incident is believed to be closed.
Practitioner takeaway: If a host has been compromised, assume every trusted login path may have been altered until key provenance and account history are verified.
Risk and Threat Considerations
SSH key persistence creates durable post-compromise access, so the main risk is not the original intrusion but the attacker’s ability to return later without re-exploiting the same weakness. Because the key survives simple password resets and can be hidden in routine administrative noise, it is a common route to prolonged dwell time and repeated privilege use.
Failure mechanism: An attacker with write access to an account’s authorized_keys file can replace or supplement legitimate access with a key they control, then authenticate repeatedly as that user. If the account is privileged, the attacker may preserve administrative reach even after the initial incident is partially remediated.
Impact: This can enable persistence, lateral movement, re-entry after cleanup, and continued data access from a trusted login channel. In environments where SSH access is broadly permitted, a single overlooked key can keep a compromised system exposed for a long time.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
