Persistence via SSH Keys

What persistence via SSH keys means

Persistence via SSH keys is a post-compromise technique in which an attacker adds their own public key to a target account’s authorized_keys file, then uses that key to return later through normal SSH logins. Because the access path looks like legitimate key-based administration, it can survive simple password resets and remain useful after the original exploit is closed.

This technique matters because SSH key access is often trusted as a strong administrative control. Once an attacker can modify a user’s key material or the file that stores it, they no longer depend on the original vulnerability, only on the continued presence of the implanted key and any path that lets them authenticate to the host.

Why attackers use authorized_keys modification

SSH keys give durable, repeatable access, which makes them attractive after privilege escalation. Compared with a one-time shell, a planted key can provide future access without generating obvious password-reset fallout, and it may continue working until the key is discovered and removed from every relevant account and host.

Persistence often follows another compromise step such as stolen credentials, sudo abuse, or write access to a home directory or configuration path. The technique is especially effective when defenders focus on changing passwords but do not review key-based access, SSH configuration, or the account’s authorized key inventory.

For a practical overview of SSH key sprawl, revocation, bastions and removal of orphaned keys, see SSH Key and SSH Certificate Management Guide.

How this persistence is established and maintained

The attacker must reach a point where they can write to the target user’s authorized_keys file or an equivalent SSH trust location. That can happen through direct host compromise, abuse of automation accounts, poisoned deployment steps, stolen developer access, or any other path that grants write access to the user context used for SSH login.

Once the key is inserted, the attacker usually keeps it low-friction by blending it into existing admin access patterns, using standard SSH tooling, and relying on the fact that the host sees the login as a normal public-key authentication event. If multiple machines or shared home directories reuse the same key, the persistence can spread beyond a single system.

The account manipulation pattern behind added SSH keys is a classic post-compromise primitive, and it is worth comparing against MITRE ATT&CK T1098 Account Manipulation Guide, which covers added SSH authorized keys and other durable access changes.

Why it is hard to spot and remove

SSH key persistence is easy to miss when defenders look only for malware, password changes, or obvious scheduled tasks. The access path may appear legitimate because the login uses a normal authentication mechanism, often from an address or workstation the attacker already controls or has proxied through.

Removal is also harder than a simple password reset because the defender must identify every copy of the rogue key, every account that trusts it, and any related automation or repo secret that can reintroduce it. If the attacker also changed permissions, added secondary keys, or planted access in multiple accounts, the same compromise can reappear after cleanup.

Detection improves when administrators compare authorized key inventories, host logs, and identity activity together, rather than treating SSH access as a separate operational problem. Identity Threat Detection and Response (ITDR) Guide is useful here because it focuses on identity-driven persistence, abnormal access patterns, and response steps that go beyond account password resets.

Why defenders should treat SSH keys as durable access assets

SSH keys should be treated as access-bearing material, not as inert configuration. A key that remains valid after a password change, host rebuild, or routine user reset can preserve attacker access unless it is explicitly discovered, revoked, and replaced across the environments that trust it.

That makes inventory, ownership, and offboarding the core control problem. If administrators cannot answer which keys exist, who owns them, where they are authorised, and whether they are still needed, then authorized_keys becomes a quiet persistence layer rather than a managed control point.

For broader guidance on stale keys, rotation, certificates and removing orphaned access, the SSH Key and SSH Certificate Management Guide is the most direct reference, and How to find unused GitHub deploy keys and SSH keys is useful when the same persistence problem extends into developer platforms.

Risk and Threat Considerations

SSH key persistence creates durable post-compromise access because it survives the controls many teams check first, especially password resets and account password changes. The danger is not just continued login, but the attacker’s ability to return quietly through a trusted administrative path and re-establish control after the original intrusion is thought to be contained.

Failure mechanism: An attacker gains write access to a user’s SSH trust material, adds their own public key, and then uses that key for repeated authentication until every trusted copy is removed and the underlying write path is closed.

Impact: The attacker can retain long-lived access, bypass routine password hygiene, move laterally through SSH-reachable systems, and preserve a foothold for further privilege escalation, data theft, or re-compromise.

Practitioner Guidance

What to watch for: Treat any unexpected change to authorized_keys, new key entries on privileged accounts, or key-based logins from unusual administration paths as a high-priority persistence signal. The most common mistake is assuming a password reset has removed the threat when the real persistence mechanism is the SSH key itself.

Governance implication: Assign clear ownership for SSH keys, require periodic review of authorised keys, and make key removal part of offboarding and incident response. Where SSH is used for automation or privileged access, the review process should cover both human accounts and the service paths that can replant keys.

Related resources from NHI Mgmt Group

• Persistence via Run Keys
• SSH Authorized Keys Persistence
• Should organisations use SSH certificates instead of long-lived keys?
• How should security teams replace static SSH keys with short-lived access controls?