SSH keys are the simpler default for a small fleet. SSH certificates become attractive when a team needs centralized issuance, short validity periods, or fewer per-host key-distribution changes—and is willing to operate a certificate authority.
What is the difference?
A public-key workflow places user public keys in server authorization policy, commonly authorized_keys. A certificate workflow signs a user key with an SSH CA; the server trusts the CA and checks the certificate’s principals and validity.
Certificates do not eliminate private-key protection. They change the trust and expiry model around the public key.
Decision table
| Priority | Better starting point |
|---|---|
| One to a few servers | SSH keys |
| Minimal new infrastructure | SSH keys |
| Short-lived team access | SSH certificates |
| Central issuance and policy | SSH certificates |
| No owner for a CA and recovery process | SSH keys |
What does a certificate authority add?
The CA becomes a high-value operational boundary. Protect its signing key, define who can issue certificates, document principals, and maintain a recovery and revocation process. A certificate that expires can reduce stale access, but a compromised CA can affect many hosts.
OpenSSH’s ssh-keygen supports certificate creation and key-revocation-list workflows. The exact flags and server configuration should be checked against the OpenSSH version shipped by the target distribution.
Which model should a small team choose?
Choose keys when the fleet is small enough that onboarding and offboarding are reviewable. Choose certificates when repeated key distribution is the actual bottleneck and someone owns CA security, issuance automation, auditing, and emergency recovery.
Compare this with Tailscale SSH versus SSH keys and tailnet-only SSH.