Replace SSH Keys with a Short-Lived CA

Run an SSH certificate authority, issue short-lived user and host certificates, and have servers trust the CA so key rotation and revocation are manageable.

~50 minsshsecuritypki

Task

Manage SSH access with certificates instead of distributing and rotating long-lived public keys.

When to use this

Public keys are copied to authorized_keys on many hosts and never removed when people leave, so offboarding is unreliable.

Prerequisites

An SSH CA key pair
Servers configured to trust the CA

Steps

1. Generate and, if possible, store the CA key in an HSM or KMS.

Expected output: The root of trust is protected.

2. Issue short-lived user certificates with principals and validity on demand.

Expected output: Each user has a certificate scoped to their identity and a short life.

3. Configure servers to trust the CA rather than individual keys.

Expected output: Access is governed centrally.

4. Issue host certificates so clients verify servers through the same CA.

ssh-keygen -s ca_key -I alice -n alice,dev -V +8h alice.pub

Expected output: Both directions are covered by the CA.

Troubleshooting

Problem

Certificate not accepted

Solution

Ensure the principal matches the login user and the server trusts the CA with the right options.

Problem

CA key compromised

Solution

Keep the CA key offline or in a KMS; issuance servers should hold a signing key, not the root, where possible.

Limitations

An SSH CA introduces a signing service that must be available for access and is itself a high-value target.
It does not remove the need to audit who has which principals; the CA centralizes trust, not authorization policy.

Context

Manage SSH access with certificates instead of distributing and rotating long-lived public keys. Public keys are copied to authorized_keys on many hosts and never removed when people leave, so offboarding is unreliable.

Steps

Generate and, if possible, store the CA key in an HSM or KMS. Expected: The root of trust is protected.
Issue short-lived user certificates with principals and validity on demand. Expected: Each user has a certificate scoped to their identity and a short life.
Configure servers to trust the CA rather than individual keys. Expected: Access is governed centrally.
Issue host certificates so clients verify servers through the same CA. Expected: Both directions are covered by the CA.

# issue a user cert valid for 8 hours
ssh-keygen -s /ca/ca_key -I alice -n alice,deploy -V +8h alice.pub
# server trusts the CA
TrustedUserCAKeys /etc/ssh/ca.pub

Verify

The root of trust is protected.
Each user has a certificate scoped to their identity and a short life.
Access is governed centrally.
Both directions are covered by the CA.

Limits

An SSH CA introduces a signing service that must be available for access and is itself a high-value target.
It does not remove the need to audit who has which principals; the CA centralizes trust, not authorization policy.