Attackers use SSH Authorized Keys by adding their public key to a user’s authorised keys file so they can log in without a password. This creates durable access and often survives password resets. Defenders should review authorised keys, restrict shell access, protect home directories, and alert on new key additions, especially for privileged or service accounts.
How SSH Authorized Keys Become a Durable Access Path
SSH authorized keys are not just a login convenience, they are a persistent authentication path. Once an attacker places their public key into a user account’s authorized_keys file, they can usually authenticate without knowing the password. That means the access can outlast a password reset unless the key is removed and the account is reviewed.
The practical security issue is that SSH keys often blend into normal administration. A key added to a developer, admin, or service account can look legitimate at first glance, especially if the account already uses key-based login. That is why reviewing key provenance, account ownership, and file permissions matters as much as the login mechanism itself. For broader SSH key governance, see SSH Key and SSH Certificate Management Guide.
Attackers also prefer SSH keys because they are durable. Unlike a password phish or a one-time session theft, a planted key can survive routine help-desk resets, and if the account is shared or rarely monitored, the access path can remain hidden for a long time.
Where Attackers Plant Keys and Why It Works
The most common target is a writable authorized_keys file in a home directory, but attackers may also abuse configuration drift, weak file ownership, exposed backups, or automation that copies keys around. If they can write to the file, they can usually add a new key and gain silent access on the next SSH connection.
This technique is especially effective where shell access is broad and administrative boundaries are weak. A single compromised account can become a stepping stone to other hosts, while service accounts with long-lived access can be reused for lateral movement or scheduled jobs. The attacker does not need to defeat SSH itself, they only need a place where the system trusts whatever key is listed.
Key-based persistence is also attractive because it can be disguised as routine administration. Teams often expect authorized_keys to change during onboarding, automation rollout, or troubleshooting, so a malicious addition may not stand out unless there is a clear baseline and change record.
When the compromise path leads through a privileged account, it is worth comparing the observed access model with a stronger authorization design. The Authorisation Models Guide is useful when you need to separate “can log in” from “should be allowed to do anything useful after login.”
How to Detect, Contain, and Remove the Backdoor
Detection starts with inventory and change visibility. Look for newly added public keys, unexpected key fingerprints, unusual timestamps, and keys appearing on accounts that normally should not have interactive SSH access. Compare current authorized_keys content to a known-good baseline, then investigate the source of any unapproved addition.
Containment usually needs more than deleting the file entry. If the attacker used the key to create sessions, set up automation, or escalate privileges, you should treat the account as potentially compromised and review adjacent systems for the same key material or reuse. If the account is shared, the blast radius is larger because the attacker may have blended into legitimate operational use.
Cleaning up the account is only one part of the fix. You also need to close the write path that made the file editable, protect home directories, limit interactive shell access where it is not needed, and ensure that service accounts are not being used as general-purpose login accounts. When a fleet has many SSH identities, lifecycle discipline becomes the difference between a one-off cleanup and a recurring incident. The NHI Lifecycle Management Guide is directly relevant to offboarding orphaned keys and tightening ownership.
Risk and Threat Considerations
SSH authorized key abuse is dangerous because it creates stealthy persistence with low noise. The attacker is not exploiting a protocol flaw so much as abusing a trusted trust store, which means the defensive failure is often visibility and ownership rather than encryption or transport security.
Failure mechanism: A malicious or stolen key is added to an authorized_keys file, then survives password resets, routine logins, and in some environments even partial remediation because the write path or companion access remains open.
Impact: The attacker gains durable remote access, can return after an initial cleanup, and may use the account for privilege escalation, staging, or lateral movement if the account has wider system trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | SSH authorized_keys abuse is persistence through account modification. |
| Recommendation — Monitor for unauthorized SSH key additions and investigate account changes as persistence activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Directly governs account lifecycle and removal of unused access paths. |
| Recommendation — Review and remove dormant SSH access paths from accounts and automation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys are authenticators whose lifecycle and rotation must be controlled. |
| AC-2 — Account Management | Unauthorized key insertion changes account access and requires account governance. | |
| AC-6 — Least Privilege | Limiting shell and account privilege reduces the impact of a planted key. | |
| Recommendation — Enforce lifecycle control, rotation, and removal for SSH authenticators. Reconcile SSH key use with account ownership and disable unnecessary access. Restrict SSH-enabled accounts to the minimum access needed. | ||
Practitioner Guidance
What to verify: Confirm who owns each SSH key entry, whether the account should still have shell access, and whether the file path, permissions, and parent directory protections actually prevent unapproved edits. If you cannot attribute the key to a person, system, or approved automation owner, treat it as suspicious until proven otherwise.
What to measure: Track the number of keys per account, the age of each key, and how many keys are attached to privileged or service accounts. A growing count, stale keys, or keys that outlive their owners usually indicates weak offboarding and poor access governance.
Decision rule: If the key can authenticate to a production or privileged system, rotate the credential path and assess blast radius before assuming the account is merely “passwordless but safe.” If the account is non-interactive, remove shell access rather than leaving an unnecessary login path in place.
Practitioner takeaway: SSH key abuse is usually a governance problem revealed through authentication, not an SSH protocol problem, so the right response is to make keys attributable, short-lived where possible, and continuously reviewable.