Every organization that has run Linux at scale for more than a few years is sitting on a pile of SSH keys nobody can fully account for. The keys work. Engineers log in, automation runs, deployments ship. And underneath that smooth surface is an authentication system with no expiry, no central authority, and no reliable way to answer the question an auditor will eventually ask: who can log into this host, and why.
SSH public key authentication was a good design for a single administrator managing a handful of machines. It scales to a fleet the way a shoebox of index cards scales to a library catalog, which is to say it does not. The problem is not that key-based auth is insecure in principle. The problem is that the operational model around it has no lifecycle, and a credential with no lifecycle becomes permanent by default.
SSH certificates solve the structural problem rather than patching the symptoms. Instead of distributing public keys to every host and hoping someone remembers to remove them, you sign a short-lived certificate with a trusted certificate authority, and the host trusts the CA rather than the individual key. This post explains why raw keys do not scale, what certificates change, and why most organizations are still running on unmanaged keys despite knowing better.
The Certificate Visibility Gap
Typical enterprise: what's tracked vs. what actually exists
Tracking Coverage
Certificates Found by Source
⚠️ In the average mid-market enterprise, less than 15% of certificates have both ownership documentation and expiry monitoring.
How Raw Key Auth Actually Breaks Down
The mechanics of SSH public key auth are simple, and the simplicity is exactly where the operational debt hides. A user generates a keypair. The public key gets appended to the authorized_keys file on every host that user needs to reach. From that moment, anyone holding the matching private key can log in, forever, until someone manually edits that file on every host and removes the line.
No expiry means no forcing function
An SSH key does not expire. There is no date after which it stops working, no renewal event that forces a review, no natural moment where someone asks whether this access is still needed. A key generated by an engineer in 2019 who left the company in 2021 will still authenticate in 2026 if nobody removed it. And in most fleets, nobody removed it, because removal is manual, per-host, and invisible when skipped.
Contrast this with TLS certificates, which expire and force renewal. That forcing function is annoying, but it is also the mechanism that keeps a TLS estate from accumulating decade-old credentials. SSH keys have no equivalent, so they accumulate without limit.
authorized_keys is a distributed database with no admin
The authorized_keys file is effectively a tiny access-control database living on every host, and no single system owns it. Each file drifts independently. A key added by hand during an incident at 3am, a key copied by a configuration tool three years ago, a key pasted into a wiki and then onto forty servers: all of them live in files that no central inventory tracks.
| Dimension | Raw SSH Keys | SSH Certificates |
|---|---|---|
| Expiry | None, permanent until manually removed | Built in, minutes to hours |
| Central control | None, each host holds its own authorized_keys | CA issues all access centrally |
| Who can log in | Requires scanning every host | Defined by issuance policy |
| Offboarding | Manual removal on every host | Stop issuing, access expires |
| Host authenticity | TOFU, user accepts unknown host fingerprint | Host certificate signed by CA |
| Audit trail | None at the key level | Issuance log records every certificate |
Orphaned keys are the normal state, not the exception
Because removal is manual and invisible, orphaned keys are not a rare failure. They are the steady state. When an engineer leaves, their private key copies may be deleted from their laptop, but the public keys remain in authorized_keys files across the fleet. If a backup of that laptop, a cloned repository, or an old config management checkout still holds the private key, that access is live.
An auditor asking “show me everyone who can reach the production database host” cannot be answered from a central system. It can only be answered by scanning authorized_keys on that host, correlating each key fingerprint back to a human or a service, and discovering that a meaningful fraction map to nobody anyone can name. That gap between keys present and keys attributable is the risk that key-based auth creates by design.
What SSH Certificates Change
An SSH certificate is a short-lived credential that binds a public key to a set of claims, signed by a certificate authority the host trusts. The host no longer trusts individual user keys. It trusts the CA, and it accepts any certificate the CA signs, within the constraints the certificate carries.
The CA replaces the authorized_keys sprawl
Instead of pushing public keys to every host, you configure each host once to trust the CA’s public key via the TrustedUserCAKeys directive. From then on, a user presents a certificate rather than a bare key, and the host validates it against the CA. There is nothing to add or remove per user. Access is granted by the CA issuing a certificate and revoked by the CA declining to issue the next one.
# /etc/ssh/sshd_config on every managed host
TrustedUserCAKeys /etc/ssh/ca_user_key.pubThat single line replaces the entire authorized_keys distribution problem. The host does not need to know which users exist. It needs to know which CA it trusts.
Short lifetimes make expiry the default
Certificates carry a validity window, and for user access that window is short, often measured in hours. A certificate issued at the start of a workday expires by evening. There is no orphaned-key problem because there is no persistent credential to orphan. If access should end, you simply stop issuing, and the last certificate the user holds expires on its own.
This flips the lifecycle. With raw keys, the default is permanent and you must act to revoke. With certificates, the default is expiry and you must act to extend. The forcing function that SSH keys never had is built into the credential.
Principals carry authorization, not just identity
A certificate can embed principals, which are labels the host uses to decide what the certificate is allowed to do. A certificate issued with the principal “db-admin” can be accepted only on hosts configured to honor that principal. Authorization stops being a per-host file edit and becomes a property of the credential itself, issued according to central policy.
Host certificates end TOFU
The other half of SSH’s trust problem is host authentication. With raw keys, the first time a user connects to a host they are shown a fingerprint and asked to trust it blindly. This trust-on-first-use model means a user who does not scrutinize the fingerprint will happily accept an impostor host. Host certificates fix this: the host presents a certificate signed by the CA, the client trusts the CA, and the unknown-fingerprint prompt disappears. The client knows the host is genuine because the CA vouched for it.
# Client ~/.ssh/known_hosts entry trusting the host CA
@cert-authority *.internal.example.com ssh-ed25519 AAAA...hostCApublickeyThe Migration Path
Moving from keys to certificates does not require a flag day. The two models coexist cleanly, because a host can trust a CA and still honor existing authorized_keys during the transition.
Stand up the CA first
Generate a user CA keypair and a host CA keypair, and protect the private keys the way you would any high-value signing key, ideally in an HSM or a hardened signing service rather than a file on disk. The CA private key is now the crown jewel: anyone who holds it can mint access to the entire fleet. Treat its storage and access controls accordingly.
Add CA trust alongside existing keys
Push the TrustedUserCAKeys directive to hosts while leaving authorized_keys in place. Nothing breaks. Existing key-based logins continue to work, and certificate-based logins begin to work in parallel. This lets you migrate users and automation incrementally rather than all at once.
Move interactive users to short-lived certs
Integrate certificate issuance with your identity provider so that a user authenticating through SSO receives a short-lived SSH certificate. The user stops managing a permanent private key as their access credential and instead receives a fresh certificate each session. This is where the operational win becomes visible: offboarding a user means disabling them in the identity provider, and their SSH access expires within hours without touching a single host.
Drain and remove the old keys
Once certificate issuance covers a population of users and automation, the corresponding authorized_keys entries can be removed. Do this with evidence, not assumption: confirm the certificate path works for a user before deleting their legacy key. The end state is authorized_keys files that are empty or nearly so, with access governed entirely by the CA.
Why Most Organizations Still Run on Unmanaged Keys
If certificates are this much better, the obvious question is why the majority of enterprises still run on raw keys. The answer is not ignorance. It is inertia plus the absence of a forcing function.
Raw keys work. They do not break, they do not expire, and they do not generate the renewal events that make TLS certificate sprawl visible and painful. The cost of unmanaged SSH keys is invisible until an audit, a breach, or an offboarding gone wrong surfaces it. Nothing in day-to-day operations pushes an organization to fix a system that appears to be working.
Standing up a CA also requires upfront design: integrating with identity, protecting the CA key, configuring hosts, and building the issuance path. That is real work with no immediate outage to justify it, which means it loses prioritization battles to problems that are actively on fire. The result is a slow accumulation of risk that nobody owns until it becomes someone’s incident.
The organizations that migrate are usually the ones that have already felt the pain: an orphaned key implicated in an incident, an audit finding they could not answer, or an offboarding where access persisted for weeks. The structural fix was available the whole time. The forcing function arrived late.
FAQ
Q: Are SSH certificates the same as TLS certificates? No. They share the concept of a CA signing a credential, but SSH certificates use a simpler, SSH-specific format rather than X.509, and they carry SSH-specific fields like principals and the validity window. You do not use your web PKI to issue SSH certificates; you run a dedicated SSH CA. The underlying idea of trusting an authority instead of individual keys is the same.
Q: What happens to a user when their SSH certificate expires mid-session? An active, already-authenticated session continues until it is closed, because the certificate authenticates the connection at login. The next time the user tries to open a new connection, they need a fresh certificate. With short lifetimes this means re-authenticating through your identity provider, which is typically a fast, automated step rather than a manual key operation.
Q: Do I have to remove all my authorized_keys to use certificates? No. Hosts can trust the CA and honor existing authorized_keys at the same time, which is what makes incremental migration possible. You add CA trust, move users and automation over, confirm the certificate path works, then remove the legacy keys. There is no flag day where everything must switch at once.
Q: What is the risk if the SSH CA private key is stolen? It is severe, because the CA key can mint access to every host that trusts it. This is why the CA key belongs in an HSM or a hardened signing service with strict access controls and an audit log, not in a file on an administrator’s workstation. The concentration of trust is the tradeoff: you replace thousands of scattered keys with one key that must be protected as a crown jewel.
Q: How do certificates help with offboarding specifically? With raw keys, offboarding means finding and removing that person’s public key from every host, a manual process that is easy to do incompletely. With certificates, you disable the person in your identity provider, which stops new certificates from being issued, and their last short-lived certificate expires on its own within hours. Access ends centrally and automatically rather than host by host.
About QCecuring
QCecuring helps enterprises move SSH access off unmanaged keys and onto a certificate model with central control and built-in expiry. Our platform inventories existing authorized_keys sprawl, attributes keys back to identities, and operates the issuance path that turns offboarding and rotation into policy decisions rather than manual, per-host cleanup.
See how your SSH key sprawl maps to a certificate model
Tags: SSH Key Management, SSH Certificates, Certificate Authority, Public Key Authentication, Enterprise Security, Identity, Access Management, Offboarding, Short-Lived Credentials, TOFU, Principals, Zero Trust