Deploying SSH User Certificates for Centralized Access Control

Problem: The Scaling Limit of authorized_keys

Managing authorized_keys files across a growing fleet of servers creates operational toil. Onboarding a new engineer or rotating keys requires updating every host, and removing access means cleaning distributed files. This manual process is error-prone and has no native expiration mechanism.

SSH user certificates provide a centralized alternative. You distribute one Certificate Authority (CA) public key to each server. The server trusts any user key signed by that CA, provided the certificate lists the correct principals and has not expired.

Desired Outcome

A centralized trust model where users present short-lived certificates signed by a CA. Servers validate the signature and listed principals to grant access, removing the need for per-host authorized_keys management.

Prerequisites

• OpenSSH server with TrustedUserCAKeys support (OpenSSH 5.4 or later).
• A secure CA host, preferably offline, to hold the CA private key.
• Time synchronization such as NTP or chrony on all clients, the CA host, and servers. Certificates use absolute timestamps, so clock skew causes authentication failures.
• Root access on servers to edit sshd_config and install the CA public key.

Step 1: Create the CA Key Pair

Generate the CA key pair on the secure admin host. Ed25519 offers strong security with good performance.

# Run on secure CA host
mkdir -p ~/ssh-ca
cd ~/ssh-ca
ssh-keygen -t ed25519 -f ca_key -C 'SSH-User-CA' -N 'your-strong-passphrase'

Protect ca_key with strict permissions and store it offline or in a hardware security module. The public key ca_key.pub is distributed to servers.

chmod 600 ~/ssh-ca/ca_key

Step 2: Configure the SSH Server

On every server that should trust the CA, install the CA public key and update the SSH daemon configuration.

# Run as root on target servers
install -m 644 -o root -g root ca_key.pub /etc/ssh/trusted-user-ca-keys.pub

Add or append these directives to /etc/ssh/sshd_config:

TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub
AuthorizedPrincipalsFile .ssh/authorized_principals

AuthorizedPrincipalsFile is optional. When set, the server checks that a principal in the certificate appears in the listed file inside the user's home directory. Without it, the server matches certificate principals against the local login name.

Validate the configuration and reload the daemon:

sshd -t
systemctl reload sshd

Step 3: Sign a User Public Key

When a user needs access, they provide their public key, for example id_ed25519.pub. The CA signs it to produce a certificate.

# Run on CA host
ssh-keygen -s ca_key -I 'user_alice' -n 'alice,dev-team' -V +52h id_ed25519.pub

The command creates id_ed25519-cert.pub. Key parameters:

• -s ca_key: the CA private key used for signing.
• -I 'user_alice': an identity string recorded in server logs for auditing.
• -n 'alice,dev-team': principals. The server matches these against the local username or the AuthorizedPrincipalsFile.
• -V +52h: validity window. The certificate expires automatically 52 hours after issuance.

The user places id_ed25519-cert.pub in the same directory as their private key on the client machine. SSH presents the certificate automatically when the matching private key is used.

Validate and Diagnose

Inspect the certificate before distributing it:

ssh-keygen -L -f id_ed25519-cert.pub

Confirm the principals, critical options, and validity window match intent. On the server, confirm the CA key is loaded:

sshd -T | grep trustedusercakeys

Test authentication with verbose output:

ssh -v alice@server-hostname

Look for output showing that a certificate was offered and accepted. If login fails, check /var/log/auth.log or journalctl -u ssh on the server. Common causes include an expired certificate, a principal mismatch, or clock skew between the client and server.

Limitations and Recovery

SSH certificates do not support simple individual revocation. The primary control is short validity windows, such as 12 to 24 hours. If a key is compromised, you must wait for the certificate to expire or rotate the CA key across the fleet.

If the CA private key is stolen, an attacker can sign certificates for any user. Recovery requires generating a new CA key pair, distributing the new public key to all servers, removing the compromised public key, and re-issuing certificates to legitimate users.

To disable certificate authentication, remove the TrustedUserCAKeys line from sshd_config and reload the daemon. Users with keys still present in authorized_keys can continue to log in.