Use authorized_keys for a handful of servers and people. Move to OpenSSH user certificates when keys pile up across many hosts, because a signed certificate can expire on its own, name which accounts it may use, and be trusted by every server through a single CA key.
How authorized_keys scales
Each server keeps a list of public keys per account. Adding a person means editing that file on every host they need. Removing a person means editing them all again, and the manual gives no automatic expiry for a bare key unless you add the expiry-time option by hand.
At three servers that is fine. At fifty, stale keys are very likely.
What a certificate is
The ssh-keygen manual describes a certificate as a public key plus identity information, zero or more principal names and a set of options, all signed by a certification authority (CA) key. Servers or clients trust the CA key and verify its signature rather than trusting many individual keys. The manual notes this is a different, much simpler format than X.509.
You sign a user key like this:
ssh-keygen -s /path/to/ca_key -I key_id -n user1,user2 -V +8h user_key.pub
The -I value is a key identifier that the server logs when the certificate is used, which helps with audit. -n limits the principals. -V sets the validity window, and by default a certificate is valid from the Unix epoch to the distant future, so always set it.
What you control with certificates
The manual lists options you can bake into a user certificate:
force-commandto run one command regardless of what the user asks.source-addressto limit where the certificate is valid, in CIDR format.no-port-forwarding,no-agent-forwarding,no-ptyand similar bans, orclearto remove all default permissions and add back only what you want.verify-requiredfor FIDO keys.
Without a principals list, a certificate is valid for all users, so name them.
Server side setup
In sshd_config, TrustedUserCAKeys points to a file of CA public keys. If a certificate presented was signed by a listed CA, it can authenticate for any user in its principals list. AuthorizedPrincipalsFile lets you say which principal names are accepted for which account, so a role name such as "deploy" can map to a local user.
Revocation and the trade-offs
Short lived certificates reduce the need to revoke, since they expire in hours. When you do need to revoke, RevokedKeys accepts a key list or a key revocation list built with ssh-keygen, and the manual warns that if that file is unreadable, public key authentication is refused for everyone. Test it.
The costs are real: someone has to protect the CA key and run the signing flow. The manual notes the CA key can live on a PKCS#11 token or in an agent, which keeps it off disk. If the CA key leaks, every server that trusts it is exposed, so treat it like a root credential.
A simple decision rule
- Fewer than about ten hosts and a stable team:
authorized_keyswith restricted options, reviewed quarterly. See restricting a key to one job. - Many hosts, frequent joiners and leavers, or audit pressure: certificates with short validity.
Safeguard offers asset discovery to help find the hosts in question, and a free scan at gold.safeguard.sh/scan for dependencies.
Quick check
Do SSH certificates expire?
Yes, if you set a validity interval with -V. By default they are valid from the Unix epoch to the distant future, so set one.
What does a server need to trust certificates?
The CA public key listed in TrustedUserCAKeys, and ideally principals mapped with AuthorizedPrincipalsFile.
Sources
- ssh-keygen(1) manual page, Debian manpages, CERTIFICATES section
- sshd_config(5) manual page, Debian manpages
- sshd(8) manual page, Debian manpages
Last reviewed: 19 October 2026.
