How does SSH certificate authority work?
An SSH certificate authority (CA) is a signing key that issues short-lived, identity-bound SSH certificates to users, replacing the need to distribute and rotate individual authorized_keys entries.
The mechanism has been in OpenSSH since version 5.4 (2010). It is documented in the ssh-keygen(1) manual page under certificates and in the OpenSSH source under PROTOCOL.certkeys. Facebook, Netflix, Uber, and Cloudflare have all published engineering posts on running an SSH CA in production.
SSH CA vs. authorized_keys
The two approaches solve the same problem (authenticating an SSH client to a server) with very different operational shapes. The table below summarizes the trade-offs.
| Concern | authorized_keys | SSH CA |
|---|---|---|
| Per-host setup on add/remove | Edit a file on every host | None — host trusts the CA, not the user |
| Credential lifetime | Indefinite (until removed) | Short-lived (minutes to hours) |
| Offboarding | Sweep every host | Stop issuing certs to that identity |
| Audit trail | Key fingerprint in sshd log only | key-id and principal recorded; ties to identity |
| Revocation | Remove the line on every host | KRL pushed once; or wait for TTL |
| Per-session policy (e.g. force-command) | Per-line, hard to manage at scale | Per-cert extension; minted at issuance time |
A minimal walkthrough
The smallest working SSH CA is a handful of commands. Production deployments replace the CA key file with an HSM or KMS-backed signer, but the protocol is the same.
# 1. Create the CA on a secure workstation (production: HSM/KMS).
ssh-keygen -t ed25519 -f ca_user -C "user-ca@example.org"
# 2. Trust the CA on every host: copy ca_user.pub there and add to sshd_config.
echo "TrustedUserCAKeys /etc/ssh/ca_user.pub" >> /etc/ssh/sshd_config
systemctl reload sshd
# 3. Sign a user's public key with a 1-hour TTL.
ssh-keygen -s ca_user \
-I alice@example.org \
-n alice,deploy \
-V +1h \
alice.pub
# -> writes alice-cert.pub
# 4. The user connects normally; ssh picks up the *-cert.pub automatically.
ssh -i alice deploy@host.example.orgWhere Linux Identity fits
Linux Identity runs the SSH CA as a managed service. The CA private key is an asymmetric ECC NIST P-256 key in a managed KMS, signed via ECDSA-SHA-256. The signing service verifies an OIDC ID token from your IdP (Okta, Google Workspace, Microsoft Entra) and mints a short-lived certificate. Host enrollment installs the CA’s public key into /etc/ssh/linuxid_ca.pub and points TrustedUserCAKeys at it.
More questions
- What are the three pieces of an SSH CA deployment?
- (1) The CA key pair — an asymmetric key whose private half signs user (or host) certificates. Modern deployments hold the private half in a hardware-backed key manager (HSM or cloud KMS). (2) The signed certificate — a short-lived blob issued by
ssh-keygen -s, binding a user’s public key to a list of principals, a validity window, and any extensions likepermit-pty. (3) The host’sTrustedUserCAKeyssetting — a line insshd_confignaming the CA’s public key. Once configured, any certificate signed by that CA is accepted without per-keyauthorized_keysentries. - How are SSH certificates issued in practice?
- The classic command is
ssh-keygen -s ca_key -I user@org -n alice,deploy -V +1h user_key.pub.-snames the CA private key;-Isets a key ID for audit;-nsets the principals (the local usernames the cert can log in as);-Vsets the validity window; the final argument is the user’s public key. The output is a*-cert.pubfile the SSH client presents alongside the user’s private key. In production, thessh-keygenstep is replaced by an API call to a signing service that holds the CA in an HSM or KMS, so the private key never sits on disk. - Which OpenSSH versions support certificate authentication?
- OpenSSH has supported certificates since version 5.4 (2010). Practical defaults — ed25519 cert keys, modern algorithms, KRL support — assume OpenSSH 6.5+ (2014). For host-key revocation lists (KRLs) you need 6.6 or later. For the recommended
-O verify-requiredsignature option (FIDO2 hardware-keys), OpenSSH 8.2+ (2020). Modern long-term-support Linux distributions (Ubuntu 22.04 / 24.04, RHEL 9, Debian 12) all ship OpenSSH 8.9 or newer. - How do you revoke an SSH certificate before it expires?
- OpenSSH uses Key Revocation Lists (KRLs). The CA operator runs
ssh-keygen -k -f revoked.krl serial:42(or by key-id), distributes the resulting file to every host, and addsRevokedKeys /etc/ssh/revoked.krltosshd_config. Once loaded,sshdrejects any cert whose serial or key-id appears in the KRL. Best practice is to keep certificate TTLs short (minutes to hours) so revocation is rarely needed, and to push the KRL via configuration management within seconds of a revocation event. - Are SSH certificates X.509?
- No. OpenSSH certificates use a custom wire format defined in the
PROTOCOL.certkeysdocument in the OpenSSH source tree. They share the goal of identity-bound short-lived credentials with X.509 (RFC 5280) but use a simpler, SSH-specific encoding. Some commercial PKI products issue X.509 client certificates and bridge to SSH via a different mechanism, but native OpenSSH only consumes its own certificate format.