SSH Keys vs SSH Certificates: When and How to Migrate Your Fleet

Plain SSH keys and OpenSSH certificates both use public key cryptography, but they fail in completely different ways, and choosing between them is really a choice about which failure you would rather manage. A public key in an authorized_keys file is a standing grant with no owner, no expiry and no central record. A certificate is a short-lived grant that every server accepts because it trusts one signing key, which moves the risk from thousands of files to a single crown jewel. This guide compares the two models side by side: the threat model of each, the controls that matter, the criteria that tell you when to migrate, and a migration path from authorized_keys to a certificate authority (CA) that does not break automation. For the build itself see the SSH Protocol and Certificate Authority Guide; for discovery and hygiene of existing keys see the SSH Key Management Guide.

Key takeaways

• The short answer is usually both, for a while. Certificates should become the default for people and for automation that can request them, while a small, owned and restricted set of plain keys stays for systems that cannot.
• Keys fail by sprawl, certificates fail by concentration. Plain keys accumulate unseen grants; a certificate estate concentrates all access in the user CA private key and the service that signs with it.
• Short validity is what makes certificates worth it. ssh-keygen issues certificates valid from the Unix epoch to the distant future if no validity is set, so a certificate without a deliberate lifetime is just a key with extra steps.
• Migration is finished only when authorized_keys is closed. Trusting a CA while users can still append keys to their own files leaves the old backdoor route open; the end state is AuthorizedKeysFile pointing at a root-owned path or set to none.
• Fleet size is not the only trigger. Joiner, mover and leaver churn, automation volume, audit demands and AI agents that need shell access often justify certificates well before the server count does.

The short answer

Choose plain keys when the estate is small, stable and few people need access, when a target cannot validate certificates (some network appliances and managed services accept only a list of public keys), or for a handful of long-running automation trust relationships that are owned, command-restricted and source-restricted. Choose certificates when access changes often, when you need access to expire without anyone remembering to remove it, when you must prove who logged in as which account, or when the number of keys and trust relationships has outgrown anyone's ability to read them. In most organisations above a few dozen servers the answer is certificates for people and new automation, keys as a managed exception, and a dated plan to shrink the exception list.

What each model is, in architectural terms

Plain public keys

Each account on each server holds a list of public keys it accepts. By default sshd reads .ssh/authorized_keys and .ssh/authorized_keys2 in the user's home directory, and optionally runs an AuthorizedKeysCommand that prints keys from a directory or database. Each line can carry options, set out in the sshd(8) manual: expiry-time= stops accepting the key after a date, from= limits source addresses, command= forces a command, and restrict turns off port, agent and X11 forwarding, PTY allocation and user rc in one word. Clients pin host keys in known_hosts, usually by trust on first use.

OpenSSH certificates

A CA signs a user's or host's public key together with a key ID, a serial number, a list of principals, a validity window and a set of options. Servers list the user CA in TrustedUserCAKeys, and clients add an @cert-authority line to known_hosts for the host CA. Trust is centralised: the answer to "who can log in as deploy" is "anyone holding a valid certificate naming the deploy principal", and the policy that decides who gets one lives in the signing service. Principals map to accounts directly, through an AuthorizedPrincipalsFile, or through an AuthorizedPrincipalsCommand that can query a directory at login. Revocation is by expiry, or by a Key Revocation List (KRL) that can name serials, key IDs, keys or fingerprints, referenced by RevokedKeys.

Side-by-side comparison

That last row deserves weight. NIST IR 7966 is cautious about OpenSSH certificates for exactly this reason: it notes that most environments have no systematic tracking of issued certificates, so if a host trusts a signing key it can be impossible to tell who can access it. Certificates improve auditability only when the issuing service keeps a complete record of every certificate it signs.

Threat model: plain keys

• Key sprawl and unknown trust: NIST IR 7966 reports that some large enterprises have hundreds of thousands or even millions of SSH user keys for automated access. Each one is an entry point, and nobody can review a grant they cannot see. See How to Find ssh authorized keys across a server fleet.
• Backdoor keys: anyone who can write to an account's authorized_keys can add standing access (ATT&CK T1098.004 SSH Authorized Keys). The Cursor Marketplace Extension Compromise 2026 shows how this looks: a tampered extension tried to write an attacker key into the user's authorised keys file.
• Stolen private keys: unencrypted identity keys on laptops, CI runners, images and backups are harvested (T1552.004 Private Keys) and reused for lateral movement (T1021.004 SSH). A plain key has no expiry, so a key stolen today works until someone finds and removes every authorised copy.
• Leaver and retired automation keys: access is tied to the file, not the person or workload, so departure from the directory changes nothing on the server.
• Host key trust on first use: users trained to accept unknown host prompts will accept an impersonated host too.

What limits the damage: root-owned authorised key locations users cannot edit, restrict, from= and command= on every automation key (IR 7966 asks for command and source restrictions on automated keys unless specially approved), expiry-time=, a defined cryptoperiod with rotation, and continuous discovery.

Threat model: certificates

• User CA key compromise: whoever holds the private key can mint a certificate for any principal and log in anywhere that trusts the CA.
• Issuance service abuse: an attacker who compromises the identity provider session, the signing API or its policy can obtain legitimate certificates without touching the CA key. The signing service is effectively a privileged access system and must be protected as one. See Securing the jump host and bastion itself for the equivalent problem on gateways.
• Over-broad principals: a certificate naming root or a shared role principal accepted on every host recreates shared credentials at fleet scale.
• Long or missing validity: ssh-keygen's default is valid from the epoch to the distant future, and -V -1m:forever is a valid argument. A forever certificate cannot be revoked except by KRL, and KRLs only help if every server has a current copy.
• Parallel key path left open: if TrustedUserCAKeys is added but AuthorizedKeysFile still reads user-writable files, every old key and every new backdoor key still works.
• Revocation fragility: sshd_config states that if the RevokedKeys file is unreadable, public key authentication is refused for all users. Distribution of the KRL is therefore both a security control and an availability risk.

What limits the damage: CA keys in an HSM, cloud KMS or PKCS#11 token (ssh-keygen signs with -D or through ssh-agent with -U), separate user and host CAs per environment, validity in hours, a unique serial and meaningful key ID on every certificate, clear plus only the permit options a role needs, source-address= for automation, and a second CA key published in advance so CA rotation is a configuration change.

Controls per option

Hardware-backed keys combine well with either model. See the Security Keys for SSH guide, and the OpenSSH Server Hardening Guide for the rest of sshd_config.

Decision criteria

Small organisations: the deciding question is whether you can run the CA well, not whether certificates are better in theory. A CA key on an engineer's laptop is worse than a well-managed handful of keys. If you adopt certificates, use a hardware token or cloud KMS for the CA and accept a working-day lifetime. Large organisations: plain keys are rarely defensible at scale because nobody can review the grants; the work is in issuance policy, CA separation by environment, and closing authorized_keys.

Where non-human identities fit

Most SSH keys belong to machines, not people: backup jobs, deployment pipelines, configuration management, file transfer and monitoring. These are non-human identities and they are where both models are usually weakest. With plain keys, an automation key is often an unencrypted file with root access to many hosts. With certificates, the question becomes how a workload proves who it is to the signing service without a stored secret. Good patterns are a CI platform's OIDC token or a cloud instance identity exchanged for a certificate valid for the length of the job, with force-command=, source-address= set to the runner range and a key ID that names the pipeline and run. Where a workload cannot obtain a fresh certificate, keep a plain key but treat it as an owned NHI with a rotation date. AI agents that need shell access should never reuse a person's key or certificate; issue each task its own short certificate restricted to the commands the task needs. See the JIT Access Guide and the sibling Short-Lived Certificates vs Long-Lived Certificates comparison for the same trade-off in TLS.

Migration path from authorized_keys to a CA

1. Inventory and baseline. Collect every authorised key, its account, host, options and last use. You cannot close authorized_keys safely without knowing what depends on it. IR 7966 suggests monitoring usage over a long period before removing keys nobody claims.
2. Stand up host certificates first. Signing host keys removes trust-on-first-use prompts, carries no risk of locking anyone out, and gives the team practice with the signing service.
3. Build issuance before trust. Put the user CA key in an HSM or KMS, run signing behind a service tied to SSO and MFA, and record every certificate with serial, key ID, principals and validity. See the HSM Deployment and Operations Guide.
4. Pilot ring. Add TrustedUserCAKeys and a principals mapping to a small group of non-production hosts while authorized_keys keeps working. Test logins, automation, break-glass and KRL distribution, including what happens when the KRL is missing.
5. Move people. Issue certificates of a working day or less to administrators, then remove their personal keys from servers team by team.
6. Move automation. Convert pipelines and agents that can present a workload identity. For the rest, move keys into a root-owned exception file with restrict, command=, from=, an owner and an expiry.
7. Close the key path. Set AuthorizedKeysFile to the root-owned exception file or to none on each host group. This is the step that removes backdoor keys as a persistence route.
8. Roll back safely. Keep the previous sshd_config and authorised key files under configuration management for each ring, keep a tested break-glass account with a hardware-backed key stored offline, and never remove the old path on a host group until its rollback has been exercised.

Worked scenario: a 600-host estate

A company runs 600 Linux hosts across production and staging, 40 administrators, 25 contractors, a CI platform with ephemeral runners, nightly backup jobs, and a pilot AI operations agent. Discovery finds about 9,000 authorised key lines, a third with no identifiable owner, and many automation keys without command or source restrictions.

Decision: certificates for people, CI and the agent; plain keys as exceptions for two storage appliances that only accept public keys and for the backup jobs until the backup platform can request certificates. Design: separate user CAs for production and staging, a host CA per environment, CA keys in a cloud KMS, signing through a service that requires SSO with phishing-resistant MFA. People receive eight-hour certificates with role principals such as web-admin, mapped to accounts by AuthorizedPrincipalsCommand. CI runners exchange their OIDC token for a certificate valid for the job, with a forced deployment command and the runner subnet as source address. The agent receives a 15-minute certificate per approved task with a forced command wrapper and a key ID naming the task ticket. Exceptions: backup keys move to a root-owned file with restrict, command= and from=, a named owner and a 90-day review. Result: after closing authorized_keys on all host groups, a leaver's access ends at their last certificate's expiry, unknown key lines fall to zero, and every login carries a key ID that ties back to a person, pipeline run or agent task.

Detection and measurement

• Log what each model can tell you: sshd logs the certificate key ID on certificate logins and a fingerprint on key logins. Alert on key-based logins to host groups that should be certificate-only. See the Linux SSH and Authentication Log Detection Guide.
• Watch for authorised key changes: file integrity monitoring on authorised key locations catches T1098.004 activity during the transition.
• Reconcile issuance with use: every key ID seen in logs should exist in the issuance record; one that does not is a sign of CA misuse.
• Monitor the KRL: version, age and presence on every host, since an unreadable file blocks all public key logins.

Common failure patterns

• Trusting the CA but leaving authorized_keys open: the estate gains certificates and keeps every old risk, including backdoor keys.
• Issuing certificates with no validity: the ssh-keygen default makes them permanent, so revocation depends entirely on a KRL nobody maintains.
• One CA for everything: a single user CA trusted by production, staging and laptops means one issuance mistake or key theft reaches all of them. Keep the host CA separate too: the GitHub RSA SSH Host Key Exposure 2023 shows how disruptive forced host key replacement is when every client pins the key directly.
• Shared principals: certificates naming root or admin on every host, which loses the attribution certificates were meant to bring.
• CA key on disk: a CA private key in a home directory or repository is a fleet-wide credential waiting to leak.
• No issuance record: without a log of every certificate, NIST's concern applies in full: nobody can say who can access a host.

Framework mapping

Practitioner checklist

• Inventory every authorised key with account, host, options, owner and last use before deciding.
• Score the estate against the decision criteria table and record the decision and its review date.
• Start with host certificates and keep known_hosts entries until clients trust the host CA.
• Hold CA keys in an HSM, KMS or token, with separate user and host CAs per environment.
• Set validity on every certificate: hours for people, the job length for automation, minutes for agents.
• Give every certificate a unique serial and a key ID that names the person, pipeline or task.
• Restrict automation with clear, force-command= and source-address=, or the key equivalents.
• Close user-writable authorized_keys once each host group is migrated, keeping a tested break-glass path.
• Distribute the KRL atomically and alert when any host's copy is missing or stale.
• Reconcile key IDs in sshd logs with the issuance record every day.

Standards and references

• OpenBSD: ssh-keygen(1) manual page, Certificates and Key Revocation Lists
• OpenBSD: sshd_config(5) manual page
• OpenBSD: sshd(8) manual page, authorized_keys and known_hosts formats
• OpenSSH: PROTOCOL.krl key revocation list format
• NIST: IR 7966 Security of Interactive and Automated Access Management Using Secure Shell (SSH)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: T1098.004 SSH Authorized Keys

Related NHI Mgmt Group resources: SSH Protocol and Certificate Authority Guide, SSH Key Management Guide, SSH Key Compromise Response Playbook, SSH Key Management Buyer's Guide.