What Are SSH Certificates Anyway?
Why SSH certificates are a better way to manage SSH access in organizations than SSH keys.
By Julian
What is an SSH cert?
An SSH certificate is a public SSH key that has been signed by an SSH certificate authority.
A normal SSH public key is just a key:
ssh-ed25519 AAAAC3... julian@laptop
The server has to know this exact key, usually because it was copied into authorized_keys.
An SSH certificate is different. It still contains a public key, but it also contains signed information around that key:
public key
+ allowed principals
+ validity window
+ critical options (like forced command or source address)
+ CA signature
Now the server does not need every user's public key. It only needs to trust the CA public key.
So the trust model changes from:
this server trusts this one public key
to:
this server trusts this CA
this CA signed a short-lived certificate for this user
That is the core idea: trust is no longer based only on possession of a key pair that was copied to the server. The important question becomes whether the presented public key was signed by a CA the server trusts, and whether the signed certificate is still valid.
SSH certs are still SSH keys, but with signed context attached.
Certs vs keys vs passwords
There are three common ways people authenticate to SSH:
- passwords
- raw SSH keys
- SSH certificates
They can all get you into a server, but they behave very differently once you have more than a few people and machines.
| Question | Password authentication | SSH keys | SSH certificates |
|---|---|---|---|
| Best fit | Maybe a throwaway lab, but not great for real server access | A single person or a very small, stable setup | Teams, changing access, audits, and shared infrastructure |
| What proves access? | A password the server can check | Possession of a private key | A private key plus a CA-signed SSH certificate |
| Does it naturally expire? | Only if you enforce password rotation | No, the key works until removed | Configurable. Certs have configurable validity windows set at signing * |
| How do you remove access? | Reset or disable the account/password | Find every authorized_keys entry and delete it | Stop issuing certs, let short-lived certs expire, revoke explicitly if needed* |
| Where does trust live? | Mostly on each server | In each user's authorized_keys files | In the CA key that servers are configured to trust |
| What can you audit? | Mostly account login events | Mostly account login events and key fingerprints | Who got a cert, for which principals, for which time window* |
| How does it age with a team? | Gets messy quickly | Starts simple, then becomes key inventory work | Scales around one trusted CA and short-lived issuance |
| Is it tied to a person? | Only through the local account | Not really, a public key line is easy to lose context for | Yes, the issuing flow can bind identity into the cert* |
| Can you trace stale credentials? | Not really. After access is revoked, you still do not know who stored or reused the password somewhere | Only by checking servers and finding which public keys are still present | Yes. Issued certs are short-lived and can be tracked from the issuing side* |
| Can you trace who logged in? | Only from server-side account logs, and shared passwords make this blurry | Sometimes. A key can map to a user if your inventory is clean | The certificate can identify the credential presented, but server-side logs are still needed to show that a login occurred* |
| What about sudo or server roles? | Usually local passwords, local groups, or local sudoers files | Keys only handle login. Users still need a sudo password or must be granted sudo locally | Can be combined with a PAM module for centralized sudo management* |
| What is exposed in a hack? | A reusable secret that may work anywhere the password was reused | A private key is often trusted on many servers, so one stolen key can open every server where its public key was copied | A short-lived cert has a small window, and the CA can stop issuing new access |
| Can it be phished? | Yes, very easily | Much harder, the private key is not typed into prompts | Much harder, with the extra benefit of short lifetimes |
* Available in Flotte
Why keys become painful
SSH keys are great for a single person.
One laptop, one server, one authorized_keys file. Easy.
The pain starts when access becomes a team workflow:
- people join and leave
- servers are created and replaced
- one key gets copied to many machines
- nobody knows which old key belongs to whom
- emergency access becomes permanent access by accident
At that point, the problem is not SSH. The problem is lifecycle.
With raw keys, every server becomes a small access database. To revoke a user, you have to find every server where their public key was copied. To review eligibility, you have to collect state from every server. To know whether a key is stale, you need a clean inventory.
That is a lot of trust placed in text files staying tidy forever.
How certificate access works
The practical flow is simple:
- Servers are configured once to trust your SSH CA.
- A user asks for access.
- Your system checks whether that user is allowed to access the server.
- If yes, it signs a certificate for the user's public key. The validity window is set by the CA — best practice is to keep it short (minutes or hours, not months).
- The user connects with normal SSH.
- The server verifies the CA signature and the certificate validity window.
The server no longer needs a long list of user keys.
It only needs something like this:
TrustedUserCAKeys /etc/ssh/user_ca.pub
That line says: accept user certificates signed by this CA.
Everything else moves to issuance policy: who can get a cert, for which server, as which Linux user, and for how long.
The important shift
With keys, access is usually granted by copying a public key to a server.
With certs, access is granted by signing a certificate.
That matters because signing can be short-lived, logged, and tied to identity.
If someone leaves the team, you stop issuing certificates. If a certificate was already issued, it expires when its validity window ends — and if best practices are followed, that window is short. If someone asks who was eligible and received a certificate, you can review permission and issuance records instead of trying to reconstruct that part of the story from every authorized_keys file. Server-side logs are still required to establish whether a connection occurred and what happened during it.
The best setup is boring:
no permanent user keys on servers
short-lived certs for login
central policy for who can request them
logs for every issued certificate
Where Flotte fits in
Flotte is a managed SSH user certificate authority for teams. It provides the signing and issuance layer that turns a verified company identity and an access decision into a short-lived OpenSSH user certificate. Your servers continue to use native OpenSSH: they trust the relevant CA public key and validate each certificate locally when a user connects.
Being the certificate authority is only part of the job. A useful SSH CA must also decide who may receive a certificate, for which server and Unix principal, and for how long. Flotte handles that workflow around OpenSSH:
- connecting access to your identity provider
- deciding who may access which server
- issuing short-lived SSH certificates just in time
- keeping permission and certificate-issuance records
- removing access without rotating keys across machines
Flotte does not proxy the SSH session and does not replace sshd. The CA signs user certificates, while managed servers receive the CA public key they need for verification. This preserves native SSH connections while moving certificate issuance and access policy into one managed process.
Flotte also keeps server trust scoped per server. Each server has its own key pair, so if something goes wrong on one machine, the blast radius is that machine. A leaked or misconfigured server key does not automatically become a credential that works across the whole fleet.
There is one more important piece: logging into a server and getting sudo rights are not the same thing.
SSH certificates can prove that a user may log in. They do not, by themselves, decide whether that user may become root.
With plain SSH keys, you still need local sudo passwords, local groups, or local sudoers rules.
That becomes another access system to maintain on every server (or a just "everyone has maximum access").
Flotte also includes a PAM module for centrally managed sudo rights. So the same access model can answer both questions:
May this user log in?
May this user use sudo?
That is the actual win: OpenSSH keeps doing SSH, certificates reduce the need for persistent user keys on managed servers, and Flotte gives teams centralized policy, issuance records, and sudo control around it.