Managing individual SSH keys across many servers and team members becomes unwieldy at scale. SSH certificates provide a centrally managed alternative — short-lived, signed credentials issued by a trusted certificate authority, rather than individually distributed keys.
SSH Keys vs SSH Certificates
| Factor | Traditional SSH Keys | SSH Certificates |
|---|---|---|
| Revocation | Manually remove from every server's authorized_keys | Certificates expire automatically; revocation lists also supported |
| Adding a new user | Distribute the key to every server individually | Sign once, trusted everywhere the CA is configured |
| Auditability | Hard to know which key belongs to which person across servers | Certificate metadata identifies the holder explicitly |
Prerequisites
- A server to act as your certificate authority (can be any trusted, secured machine)
- OpenSSH on all servers (certificates are a built-in OpenSSH feature)
Step 1 — Generate a CA Key Pair
On your CA machine (kept especially secure, ideally offline/air-gapped for maximum security):
ssh-keygen -t ed25519 -f ssh_ca -C "SSH CA"This produces ssh_ca (private, keep extremely secure) and ssh_ca.pub (distribute to all servers).
Step 2 — Trust the CA on Each Server
sudo cp ssh_ca.pub /etc/ssh/ssh_ca.pubsudo nano /etc/ssh/sshd_configTrustedUserCAKeys /etc/ssh/ssh_ca.pubsudo systemctl restart sshStep 3 — Generate a User Key Pair (On the User's Machine)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519Step 4 — Sign the User's Public Key with the CA
On the CA machine, after the user submits their public key for signing:
ssh-keygen -s ssh_ca -I "[email protected]" -n alice -V +8h alice_id_ed25519.pub-I is an identity comment, -n restricts which usernames the cert can be used with, -V +8h makes the certificate expire in 8 hours — short-lived certificates significantly limit the impact of a stolen credential.
Step 5 — Return the Signed Certificate to the User
The signing process produces alice_id_ed25519-cert.pub — place it alongside the corresponding private key:
cp alice_id_ed25519-cert.pub ~/.ssh/id_ed25519-cert.pubStep 6 — Connect Using the Certificate
ssh [email protected]SSH automatically uses the certificate alongside the matching private key — no different connection command required.
Automating Certificate Issuance
For teams, integrate certificate signing into your existing identity provider or a dedicated SSH certificate management tool, so short-lived certificates are issued automatically after authenticating through your organization's existing SSO, rather than a manual signing process for every request.
Revoking Access
Because certificates expire automatically (often within hours), revocation is largely handled by simply not re-issuing a new certificate — for immediate revocation before natural expiry, a Key Revocation List (KRL) can be configured and distributed to servers.
Common Errors
"Certificate invalid: expired" — the short-lived certificate's validity window has passed; request a new signed certificate.
Server doesn't recognize the certificate — verify TrustedUserCAKeys points to the correct CA public key file on that specific server.
Best Practices
- Keep the CA private key extremely secure, ideally offline when not actively signing
- Use short certificate validity periods (hours, not months) to limit the impact of a compromised credential
- Integrate with your organization's existing identity/SSO system for a smoother, more secure workflow at scale
Continue Reading
- SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys
- How to Harden SSH Beyond the Basics (Ciphers, MACs & Algorithms)
- How to Implement the Principle of Least Privilege on a Linux VPS
Browse more articles in Advanced Security & Compliance.
