A password usually has an owner and a reset or revocation process. An unmanaged SSH key can sit outside that lifecycle and still open the door years later.
What Are SSH Keys?
SSH public-key authentication uses a cryptographic key pair: a private key and a corresponding public key. The private key stays with the user or service, in a file, an agent, or a hardware token. In a typical OpenSSH deployment, the public key is authorised through ~/.ssh/authorized_keys on the target host. (OpenSSH)
Anyone holding the private key corresponding to an authorised public key may authenticate as that account, subject to any additional server-side restrictions or authentication requirements.
NIST published IR 7966 in October 2015, whose abstract noted that "the security of SSH key-based access has been largely ignored to date." A decade on, that is still broadly true. (NIST IR 7966)
How Does SSH Key Authentication Work?
The client proves possession of the private key by producing a cryptographic signature tied to the SSH authentication exchange; the private key itself is never sent to the server. That removes several risks associated with reusable passwords, so public-key authentication can provide stronger authentication when the private key is properly protected. (OpenSSH)
Common key types are RSA, ECDSA, and Ed25519. Ed25519 keys are 256 bits and strong at that size, so key length is not comparable across algorithms. For RSA, 2048 bits still meets NIST's current minimum security-strength requirement, while RSA-3072 corresponds to roughly 128 bits of classical security and is a stronger choice for new keys. (NIST)
Why Do SSH Keys Become a Blind Spot?
No inherent expiry. A raw SSH public key does not carry an expiration date, so an unmanaged authorized_keys entry can remain valid indefinitely. An unrestricted entry added in 2019 can still work in 2026 unless it is removed, revoked, expired through configuration, or otherwise blocked. (OpenSSH)
No central issuance by default. In an unmanaged deployment, a user who can modify their own authorized_keys can create and authorise a new key without going through a central provisioning workflow.
No inventory. Keys live in per-user files scattered across every host. Nothing collects them by default, so nobody can say who holds access to what.
Leaver processes can miss them. If a server uses a separate local account rather than the disabled directory identity, an authorised key may remain usable until that local access is revoked.
Privileged access management can miss them. PAM platforms miss unmanaged SSH keys when key discovery and SSH access are not integrated into the deployment.
Where Does the Volume Come From?
Interactive logins are the small half. The large half is automation, and NIST notes automated SSH access is used for high-privilege operations including file transfers, disaster recovery, and patch management. Those keys are hardest to remove, because nobody is sure what breaks. (NIST IR 7966)
What Does This Look Like in Practice?
In the Virtualizor incident of August 2026, a backdoored update added an attacker-controlled key to root's authorized_keys.
That single line can outlive the surrounding malware. On the examined node, the injected key provided passwordless root access until the authorised-key entry was removed or otherwise revoked. (LowEndTalk)
Why Does It Matter?
Keys accumulate access. A key trusted on many hosts turns one compromised workstation into movement across an estate, and those logins look routine.
Additions also go unnoticed. Most organisations can list their privileged users. Far fewer can list their keys, who added each, and whether it is still needed.
Common Mistakes
- Treating key authentication as automatically safe. It removes password risk, not access-lifecycle risk.
- Enabling agent forwarding unnecessarily. Someone with access to a forwarded agent socket can use your loaded identities to authenticate onward. (OpenSSH)
- Generating keys without passphrases. An unprotected private key on a laptop is a credential sitting in a file.
How to Reduce the Risk
- Inventory
authorized_keyson every host, and record an owner for each - Move to SSH certificates, which carry a validity period and expire on their own
- Combine
from=,command=, andrestrictto limit where a key can be used and what it can do - Alert on any change to
authorized_keys, especially root and service accounts
What Should Security Testing Cover?
Ask your testers to establish:
- Which hosts one recovered private key can reach
- Whether adding a key to a privileged account raises an alert anyone acts on
How OraSec Can Help
SSH key access is one of the clearest gaps between an access list and reality. OraSec's internal penetration testing follows key-based trust to establish what one compromised key reaches, and red teaming tests whether adding one gets noticed.
Conclusion
A line in a text file grants standing privileged access, and unless someone configures an expiry, records who added it, and watches for changes, nothing does.
Until you can produce that inventory, your access review covers the accounts you know about, not the access that exists.
FAQs
Do SSH keys expire? Raw SSH public keys have no inherent expiry. OpenSSH can apply an expiry-time= to an authorised-key entry, while SSH certificates include explicit validity periods.
Are SSH keys more secure than passwords? Properly protected SSH keys can provide stronger authentication than reusable passwords, but key-based authentication is not automatically secure if key lifecycle and private-key protection are weak.
How do we find unused SSH keys? Collect authorized_keys from every host, match each entry to an owner and purpose, then remove anything nobody claims.
What is SSH key sprawl? Authorised keys accumulating across an estate faster than anyone removes them, until the total set of access is unknown.
