Authorized_keys

What the authorized_keys file actually does

The authorized_keys file is the server-side allowlist that determines which public keys can authenticate to a given account over SSH. It turns key material into an access decision, so it is not just configuration, it is a live control boundary.

Its practical role is simple: if a key appears in the file, that key can be used to prove possession of the matching private key and attempt login for that account. If the entry remains after the person, system, or integration should no longer have access, the file becomes an orphaned access path.

Why authorized_keys is a governance boundary

authorized_keys sits at the point where identity, authentication, and access governance meet. It is often edited like a convenience file, but every line is effectively an entitlement, because it grants a concrete route into a user context on a server.

This is why stale entries matter. A forgotten key can outlive the intended user, automation, contractor, or emergency access arrangement, which makes offboarding, rotation, and ownership reviews materially important. The same logic applies in environments that use SSH widely for administration, deployment, or cross-host automation, where a single file can accumulate long-lived access over time.

For broader control design, this is the same governance problem discussed in IAM and IGA Basics, because the file is one of the places where entitlement decisions are actually enforced.

How SSH key access becomes insecure

Security problems usually arise when the file is treated as static infrastructure instead of managed access control. Common failure modes include orphaned keys, shared keys across operators or tools, copied entries that were never removed, and weak separation between administrative accounts and routine user access.

Because the file controls access server-side, the risk is not only exposure of the private key. An attacker who obtains a valid private key, or who can insert a new public key into the file through another compromise path, can gain durable access that may look legitimate to the SSH service.

That is why SSH key sprawl and removal discipline are central to SSH Key and SSH Certificate Management Guide, and why lifecycle control matters as much as key strength.

Where authorized_keys fits in the access lifecycle

The file is most useful when it is treated as part of a full lifecycle, not as an ad hoc list. That lifecycle includes provisioning the correct key, limiting it to the right account and environment, rotating or replacing keys when trust changes, and removing entries as soon as access should end.

In practice, authorized_keys also reflects visibility and ownership. If no one can say why a key is present, who approved it, or when it should be removed, then the access record has already fallen behind reality. That is the same lifecycle problem addressed in NHI Lifecycle Management Guide, even when the underlying identity is a human administrator rather than an automated workload.

Where teams need a wider view of access patterns, Authorisation Models Guide is useful for thinking about how a simple allowlist entry maps to least-privilege access decisions.

How to interpret it operationally

Think of authorized_keys as a control surface, not a convenience file. Each entry should have an owner, a purpose, and an expected removal point, because the security of SSH access depends on the accuracy of that inventory.

When access needs to be temporary, the safer pattern is to make the key temporary too, or to replace direct long-lived entries with stronger governance around certificates, bastions, or centrally managed access workflows. The main test is whether the file still reflects current trust.

That is also why the broader SSH control discussion belongs next to Top 10 NHI Issues: even when the term is human-facing, the failure pattern is the same, stale access that survives longer than the trust that created it.

Risk and Threat Considerations

authorized_keys is attractive to attackers because it can create durable, low-friction access that bypasses password-based controls and may evade casual review. If a server accepts an untracked key, compromise can persist until the entry is discovered and removed.

Failure mechanism: stale, shared, or maliciously inserted keys turn a small configuration list into a persistent access path, especially when key ownership and review are weak.

Impact: unauthorized SSH access can enable server takeover, lateral movement, privilege abuse, and long-lived persistence that survives normal password resets.

Practitioner Guidance

What to watch for: Treat any authorized_keys file with multiple unmanaged entries, shared keys, or no documented owner as a control gap. That usually signals that offboarding, rotation, or recertification is incomplete.

Practitioner takeaway: The file should be managed as an entitlement registry for SSH access, not as a technical detail, because access that is easy to add but hard to retire is access that will eventually become stale.

Related resources from NHI Mgmt Group

• What is the difference between controlling SSH access with PAM and controlling it with authorized keys on the destination host?
• How should security teams manage SSH authorized keys to prevent persistent unauthorized access?
• What breaks when unauthorized SSH keys are left in authorized_keys?
• Authorized Keys