How to Replace Static Authorized Keys with OpenSSH Cryptographic Certificates

Managing static authorized_keys files across dozens of Linux servers creates operational debt. Engineers leave old public keys behind, key rotation requires touching every single host, and revoking compromised credentials forces emergency configuration sweeps. An SSH Certificate Authority replaces static key distribution with cryptographic signatures. Hosts trust the CA signature, and users authenticate with short-lived certificates containing strict expiration timestamps and Unix principal definitions.

Static SSH keys behave like persistent passwords. Signing certificates with short lifespans enforces automatic credential expiry without touching remote servers.

Step 1 – Generate Dedicated CA Signing Keys

Do not generate your Certificate Authority keys on a shared server. An SSH CA key signs credentials that grant root or administrative access across your infrastructure, so you must generate and store it on an offline, encrypted storage volume or an isolated management workstation. OpenSSH supports ed25519 keys for signing, which offer compact signatures and fast verification.

Run ssh-keygen to create separate signing keys for user certificates and host certificates. Separating user and host signing authorities prevents compromised host keys from issuing valid user login credentials.

# Generate CA key for user access
ssh-keygen -t ed25519 -f ~/.ssh/ssh_user_ca -C "user-ca@infra.internal"

# Generate CA key for host verification
ssh-keygen -t ed25519 -f ~/.ssh/ssh_host_ca -C "host-ca@infra.internal"

Restrict the private keys with strict Unix file permissions using chmod 600. Back up the public keys ssh_user_ca.pub and ssh_host_ca.pub, because every server in your fleet requires the public component to verify incoming connections.

Step 2 – Configure Target Hosts to Trust the User CA

Target servers must know which CA public key is authorized to sign user certificates. Copy ssh_user_ca.pub to the /etc/ssh/ directory on every target Linux server. Then update the OpenSSH daemon configuration file at /etc/ssh/sshd_config to point to this trusted authority.

Add the TrustedUserCAKeys directive and specify the absolute path to your public CA file. You should also define the AuthorizedPrincipalsFile path if you want to restrict which certificates can log in as specific system users.

# Append to /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Create the principals directory with mkdir -p /etc/ssh/auth_principals and populate files named after the local Unix accounts. For example, /etc/ssh/auth_principals/ubuntu contains the list of accepted role tags, such as sre-admin or backend-dev. Test your configuration with sshd -t before restarting the SSH service via systemctl restart sshd.

Step 3 – Issue Time-Limited User Certificates

When an engineer needs server access, sign their public key with your user CA. You must define a unique key ID for audit logging, specify one or more valid principals, and set a strict validity window. Setting an expiry of eight to twelve hours prevents lingering access after a work shift ends.

Execute ssh-keygen with the certificate signing flag -s to produce an authenticated certificate file named id_ed25519-cert.pub.

ssh-keygen -s ~/.ssh/ssh_user_ca   -I "john.doe-access-session"   -n "sre-admin,ubuntu"   -V +8h   -z 1001   ~/.ssh/id_ed25519.pub

Inspect the generated certificate metadata using ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub. Verify that the validity period, serial number, key ID, and authorized principals match your security requirements. The user places this certificate next to their private key, and OpenSSH presents it automatically during handshake negotiation.

Step 4 – Sign Host Keys and Eliminate Known Hosts Prompts

SSH Certificate Authorities also eliminate blind acceptance of host public keys and dangerous trust-on-first-use warnings. By signing each server’s host key with your host CA, your client machines verify the server identity instantly without maintaining massive, outdated known_hosts files.

Sign the server host key /etc/ssh/ssh_host_ed25519_key.pub with your host CA key, assigning the valid hostname or internal FQDN as the principal.

ssh-keygen -s ~/.ssh/ssh_host_ca   -I "bastion.infra.internal-host"   -h   -n "bastion.infra.internal,10.0.1.5"   -V +52w   /etc/ssh/ssh_host_ed25519_key.pub

Add HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub to /etc/ssh/sshd_config on the server and restart sshd. On client workstations, append @cert-authority *.infra.internal followed by the contents of ssh_host_ca.pub into ~/.ssh/known_hosts to trust all signed nodes across your domain automatically.

Step 5 – Implement Certificate Revocation Lists

Short certificate validity windows minimize exposure windows, but active security incidents require instant revocation. OpenSSH supports Key Revocation Lists (KRL) to block specific key serial numbers or public keys immediately without modifying your CA keys or restarting active services.

Generate a binary KRL file using ssh-keygen and add the revoked certificate serial number or public key file to the list.

# Revoke certificate by serial number
ssh-keygen -k -f /etc/ssh/revoked_keys.krl -z 1001

# Point sshd to the revocation database
echo "RevokedKeys /etc/ssh/revoked_keys.krl" >> /etc/ssh/sshd_config
systemctl reload sshd

You can update the KRL dynamically on live hosts by executing ssh-keygen -k -u -f /etc/ssh/revoked_keys.krl with new serials. Distribute this revocation binary through your configuration management pipeline to invalidate compromised credentials within seconds across all bastion and edge nodes.

Next steps

Connect your user CA signing workflow to an internal identity provider or short-lived CLI authentication helper. By issuing certificates on demand following MFA validation, you enforce zero-trust access principles, retain full audit trails via certificate key IDs, and eliminate unmanaged authorized_keys files across your infrastructure.