How should security teams manage SSH authorized keys to prevent persistent unauthorized access?

Why authorized_keys becomes a persistence mechanism

The risk is not the file itself, but the authority it confers. Once an SSH public key is accepted in MITRE ATT&CK T1098 Account Manipulation Guide, an attacker can often return without a password, MFA challenge, or user-visible prompt. That makes unauthorized key insertion a durable access path, especially on shared admin accounts, automation hosts, and overlooked service access.

Persistent access is most likely when key placement and key use are weakly governed. If teams allow broad write access to authorized_keys, or treat it as a local admin convenience rather than a security control, a single change can outlast the original intrusion vector and survive routine password resets.

How to control key placement, permissions, and review

Manage SSH keys as lifecycle-controlled access artifacts, not static configuration. Restrict who can add or change keys, ensure file and directory permissions prevent non-admin modification, and keep ownership tied to a clearly accountable administrator or platform team. Where possible, centralize SSH access through stronger patterns so you can reduce the number of places where direct key insertion can occur.

Review should focus on what is present, who approved it, and whether it is still needed. A useful baseline is to inventory all authorized keys, compare them with expected users and systems, and remove orphaned or stale entries promptly. SSH Key and SSH Certificate Management Guide is a useful companion for understanding sprawl, rotation, and the transition from long-lived keys to governed SSH certificates.

For environments with shared administrative access, pair key review with stronger access design. Unix and Linux Privileged Access Guide shows how SSH certificates, scoped sudo, and session control reduce the blast radius of a single compromised key.

What to detect when key-based access is already in use

Teams should watch for key addition, key replacement, and unusual login patterns, not just failed authentication attempts. A malicious key can sit quietly for weeks before being used, so monitoring needs to cover file changes, identity changes, and the first successful logins that follow them. In practice, key insertion is an access-manipulation problem, not only a login problem.

If an organisation already suspects compromise, Cloud Credential Compromise Playbook is relevant because the response pattern is similar: contain the access path, identify persistence, revoke what was added, and validate that the attacker cannot simply return. The same logic applies when a key has been added to a privileged Unix account or automation account.

When the key is attached to a system that also exposes other secrets or management interfaces, assume lateral movement may have started. Review recent access, nearby accounts, and any changes made after the key appeared, because SSH key abuse is often used as a foothold for broader administrative persistence.

Risk and Threat Considerations

Unauthorized SSH keys matter because they create durable, passwordless access that may bypass normal account controls and survive credential resets. The main threat is persistence: once a key is planted, an attacker can return repeatedly until the entry is found and removed.

Failure mechanism: A user, admin workflow, or compromised system adds an SSH public key to authorized_keys without tight approval, change control, or monitoring, then the attacker uses that key to re-enter at will.

Impact: The attacker retains stealthy access to administrative or operational systems, can evade simple password rotation, and may use that foothold for privilege escalation, data theft, or further persistence.

Practitioner Guidance

What to prioritise: Treat any key that can reach a privileged account or production host as a high-value control point. If you cannot explain why a key exists, who owns it, and when it was last used, it should be treated as suspicious until proven otherwise.

What to verify: Confirm that only the intended administrators or automation paths can modify authorized_keys, that permissions block non-admin tampering, and that each key maps to an approved identity or system. Review for stale entries after staff changes, vendor exits, and automation retirement.

Practitioner takeaway: The key question is not whether SSH keys are allowed, but whether each one has a defensible owner, a bounded purpose, and a reliable removal path when that purpose ends.

Related resources from NHI Mgmt Group

• SSH Authorized Keys
• Unauthorized Access
• How should security teams replace static SSH keys with short-lived access controls?
• How should security teams prevent unauthorized access across human and machine identities?