Our SSH key authentication guide covers the standard approach — generate a keypair, copy the public key to every server a user needs access to. That works for a handful of servers and users; it breaks down at real infrastructure scale, where revoking one person’s access means finding and removing their key from every host individually, and there’s no expiry — a key copied in 2022 still works in 2026 unless someone remembers to remove it.
SSH certificates solve this differently: a trusted Certificate Authority signs short-lived certificates for each user, and every server trusts the CA instead of individual keys. Access expires automatically, and revocation means one action at the CA level, not a sweep across every server.
Step 1: Understand the Model Shift
With plain keys, each server maintains its own list of trusted public keys — granting or revoking access means touching that list on every relevant server. With certificates, every server instead trusts one thing: a CA public key. A user authenticates with a certificate signed by that CA, valid for a limited time window and scoped to specific principals (roles). Revoking access going forward just means the CA stops signing new certs for that user — existing short-lived certs simply expire on their own.
Step 2: Generate a CA Keypair
On a secured, access-controlled host (this key signs access to everything — protect it accordingly, ideally in Vault or an HSM for anything beyond a small team): ssh-keygen -t ed25519 -f ssh_ca -C 'infra CA'. This produces ssh_ca (the private signing key — never distributed) and ssh_ca.pub (distributed to every server that should trust certificates it signs).
Step 3: Configure sshd to Trust the CA
Copy ssh_ca.pub to every server as /etc/ssh/ca.pub, then add TrustedUserCAKeys /etc/ssh/ca.pub to /etc/ssh/sshd_config and restart sshd. From this point, the server trusts any valid certificate signed by this CA — you never need to distribute individual user public keys to this server again.
Step 4: Sign a User’s Public Key Into a Certificate
A user generates a normal keypair as usual, then the CA signs their public key: ssh-keygen -s ssh_ca -I jsmith -n jsmith,ops -V +8h /home/jsmith/.ssh/id_ed25519.pub. This produces id_ed25519-cert.pub — the actual certificate, valid for 8 hours (-V +8h) and scoped to the principals jsmith and ops (-n).
Step 5: Configure the Client to Use the Certificate
SSH automatically uses a certificate placed alongside its matching private key with the -cert.pub suffix — no special client flag needed if it’s in the default ~/.ssh/ location matching the original keypair. Connect normally: ssh jsmith@server, and the server accepts it because it trusts the signing CA, not because it has jsmith’s specific public key listed anywhere.
Step 6: Use Principals for Role-Based Access
Server-side, restrict which principals are accepted per-host or per-user in sshd_config or an AuthorizedPrincipalsFile — a database server might only accept certificates carrying the dba principal, while a general app server accepts ops. This gives you role-based access control layered on top of certificate trust, without needing per-user configuration on every host.
Step 7: Revoke Access
The main revocation mechanism is simply short expiry — an 8-hour certificate for someone who left the team this morning is fully expired by tonight with zero action needed. For immediate revocation (a suspected compromise), distribute a revoked_keys file referenced by RevokedKeys in sshd_config across servers — needed rarely, since short expiry handles the routine case.
Step 8: Automate Signing With Vault (Advanced)
Manually running ssh-keygen -s for every access request doesn’t scale past a small team. Vault’s SSH secrets engine can act as the CA itself, issuing short-lived signed certificates on demand through an authenticated API call — tying directly into the Vault basics guide on this blog, so the same policy-based access control covering application secrets extends to infrastructure SSH access too.
Command reference
# Generate CA keypair (once)
ssh-keygen -t ed25519 -f ssh_ca -C 'infra CA'
# Server: trust the CA
echo 'TrustedUserCAKeys /etc/ssh/ca.pub' >> /etc/ssh/sshd_config
systemctl restart sshd
# Sign a user certificate (8 hour validity, jsmith/ops principals)
ssh-keygen -s ssh_ca -I jsmith -n jsmith,ops -V +8h ~/.ssh/id_ed25519.pubRelated tutorials
Terminal screenshots are original illustrations created for Gnome IT Solutions (blog.gnomeitsolutions.com).