OpenSSH authorized_keys is the file used to specify which public keys are allowed to authenticate to an SSH account. It acts as the server-side trust list for key-based login, so correct formatting and placement are essential for secure, reliable access control.
Expanded Definition
OpenSSH authorized_keys is the server-side allowlist that tells an SSH account which public keys may authenticate. It is not the key itself, and it is not a general policy engine; it is a trust decision point for a specific account on a specific host. That distinction matters because the file can grant access even when password login is disabled, and because key options can narrow what an otherwise valid key is allowed to do.
In practice, the term usually refers to the per-user NIST SP 800-53 Rev 5 Security and Privacy Controls approach to key-based SSH trust rather than to a broader identity system. Definitions vary slightly across environments because administrators may manage the file directly, populate it from automation, or use a centralized account management layer that writes it on behalf of users. A common misunderstanding is treating authorized_keys as a static file with no lifecycle; in reality, it is only as secure as its key hygiene, file placement, and revocation discipline.
Examples and Use Cases
OpenSSH authorized_keys appears wherever SSH access is needed without passwords, especially on servers, bastions, automation hosts, and admin workstations. The operational trade-off is convenience versus revocation discipline: key-based access is efficient, but stale keys can linger unnoticed if ownership is unclear.
- A Linux administrator adds a new public key to a user’s authorized_keys file to allow secure remote login without exposing a password.
- A DevOps pipeline writes deployment keys into a service account’s authorized_keys so a controlled automation job can reach a target host.
- A bastion host uses per-user authorized_keys entries with key restrictions to limit where an allowed key can be used from.
- A break-glass process stores a separate emergency key in authorized_keys for recovery access when normal authentication paths fail.
When the file is managed manually, small formatting mistakes can block legitimate access, while overly broad key reuse can make one compromise affect many systems. For NHI-heavy environments, NHIMG’s Ultimate Guide to NHIs is useful context because SSH keys often function as machine or service credentials rather than as human login artifacts.
Security Implications
Authorized_keys becomes a control failure when it contains stale, duplicated, or overly privileged keys. In that state, SSH access can persist long after the original need has ended, which turns a convenience mechanism into an enduring access path. The blast radius is often larger than the file suggests because a single key may unlock multiple hosts, accounts, or automation paths if it is copied or reused.
Mismanagement also creates visibility problems. If teams cannot inventory which keys are present, who owns them, or when they were last reviewed, revocation becomes slow and incomplete. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful indicator of the broader visibility gap that often surrounds machine-access credentials. A practitioner should assume that any authorized_keys entry without a clear owner and removal date is a latent access risk, not a harmless placeholder.
When SSH key material is embedded in automation, the failure mode is often silent persistence rather than obvious compromise. That means the security issue may present as ordinary successful logins until an investigation reveals that access was never fully removed.
Domain and Governance Relevance
In NHI governance, authorized_keys is a concrete example of delegated trust for machine-access credentials. Each entry represents an identity-bearing access grant that should be owned, reviewed, rotated, and revoked like any other non-human credential. This is why SSH access management cannot be separated from broader secrets handling, offboarding, and privilege review.
The NHI lens changes the control question from “Does the server accept the key?” to “Who owns this key, what system uses it, and how is it removed when the system or job changes?” That matters for service accounts, automation nodes, and administrative tooling because these keys often outlive the workload that created them. In operational terms, authorized_keys is part of the lifecycle of machine access, not just a configuration detail.
For teams that rely on SSH at scale, the governance challenge is to keep key-based access explainable across hosts, not merely functional on a single machine. Without that ownership model, access tends to accumulate faster than review processes can remove it.
Risk and Threat Considerations
OpenSSH authorized_keys carries material exposure when keys are stolen, copied, or left in place after their intended use. Because SSH trust is often account-scoped and host-scoped, a single unmanaged key can provide durable remote access that is easy for an attacker to reuse and hard for defenders to notice quickly.
Failure mechanism: Risk materialises when key-based trust is granted without strong ownership, restriction, or revocation discipline. An attacker who obtains a valid private key, or an insider who retains access after role change, can authenticate directly and bypass password controls; if the same key is reused across systems, the compromise can spread laterally.
Impact: The result can be persistent unauthorized administrative access, delayed detection, and incomplete offboarding. In environments where authorized_keys is copied, templated, or manually curated, one stale entry can become a long-lived foothold across multiple servers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | SSH authorized_keys grants account access and needs lifecycle control and revocation. |
| 5 — Account Management | authorized_keys is bound to accounts and should follow account ownership and offboarding. | |
| 8 — Audit Log Management | SSH key-based access benefits from logging and review of authentication events. | |
| Recommendation — Inventory SSH keys, remove unused entries, and enforce timely revocation for departed users and workloads. Tie key review and removal to account changes, role changes, and offboarding events. Log SSH authentications and investigate unexpected key use or repeated login attempts. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | authorized_keys implements authentication and access control for SSH accounts. |
| Recommendation — Apply least privilege to SSH key access and restrict keys to the accounts and hosts that need them. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Information Flow Enforcement | SSH key trust should be constrained to the intended access path and system boundary. |
| Recommendation — Restrict SSH key use to approved paths and prevent keys from becoming broad trust tokens. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | SSH private keys are non-human credentials that rely on authorized_keys for authentication trust. |
| Recommendation — Rotate and revoke SSH keys as managed credentials, and eliminate shared or stale key material. | ||
Practitioner Guidance
Why practitioners should care: authorized_keys is not just a file placement issue; it is an access lifecycle control. If no one owns review and removal, the file becomes a repository of forgotten trust rather than an intentional allowlist.
What to watch for: pay attention to shared keys, keys without a named owner, and entries that persist after the account or workload changes. Those patterns usually indicate that revocation and review are lagging behind actual access usage.
Practitioner takeaway: Treat each authorized_keys entry as a governed credential with an explicit owner, purpose, and removal trigger.
