Daniel Nashed's Blog

Using an SSH Certificate Authority (CA) for Centralized SSH Access

Managing authorized_keys across many servers does not scale and can't be easily recoved without logging into each machine and removing the public key.

SSH certificates solve this by introducing a Certificate Authority (CA) model: servers trust one CA, and the CA signs user keys.
No more distributing individual public keys to every machine.

It also lowers the exposure by limiting what a user can do on a machine and how long a key can log into the machine.
You can even restrict from where to login and you can also enforce a command to be executed.

The following is just to explain how the components work together.
There are solutions like the step-ca or HashiCorp vault to automate operations.

But this write-up should help to understand how it works together.
Here is a reference to smallstep CA to explain it in another way --> https://smallstep.com/docs/tutorials/ssh-certificate-login/

1. Create an SSH User CA

Your CA is just an SSH key pair used to sign other keys:


ssh-keygen -t ed25519 -f ca_user -C "SSH User CA"

• ca_user → private CA key (keep secure!)
• ca_user.pub → distributed to servers

Protect the private CA key carefully — it can issue valid login certificates.

2. Generate a User Key

Each user still has their own key pair:

ssh-keygen -t ed25519 -f id_ops


3. Sign the User Key

Use the CA to create a short-lived certificate:


ssh-keygen -s ca_user \
-I "nsh-ops" \
-z 1001 \
-n opt-notes \
-V +1m \
-O source-address=192.168.39.0/24 \
id_ops.pub

This creates:  id_ops-cert.pub

Key options:

• -n → allowed principals (roles)
• -V → validity period (short-lived = safer)
• -O source-address → restrict client IP
• -I → certificate identity
• -z → serial number

Optional restriction to just :

-O force-command="/usr/bin/domino"


4. Configure the Server to Trust Your CA

Instead of storing user keys, configure SSH once:


echo 'TrustedUserCAKeys /etc/ssh/ca/ca_user.pub' >> /etc/ssh/sshd_config
echo 'AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u' >> /etc/ssh/sshd_config
echo 'PasswordAuthentication no' >> /etc/ssh/sshd_config
echo 'PubkeyAuthentication yes' >> /etc/ssh/sshd_config

Install the CA public key:


mkdir -p /etc/ssh/ca
cp ca_user.pub /etc/ssh/ca/
chmod 644 /etc/ssh/ca/ca_user.pub

Restart SSH:


systemctl restart ssh


5. Control Access via Principals

If the certificate contains:

-n ops-notes

Allow it for a user:


mkdir -p /etc/ssh/auth_principals
echo "ops-root" > /etc/ssh/auth_principals/root

Access is granted only if:

• The certificate is signed by your CA
• It is still valid
• The principal matches
• Source IP matches (if restricted)
   

No authorized_keys file required.

Why Use SSH Certificates?

• Central trust model
• No key sprawl
• Short-lived credentials
• Role-based access via principals
• Strong automation support
   

SSH certificates are one of the most powerful — and underused — features of OpenSSH.
For larger or dynamic infrastructures, they’re a major upgrade over traditional authorized_keys management.

• Comments [0]