SSH Certificate Authority Setup

1. What is an SSH Certificate Authority?

Here's the surprising part: an SSH CA is just a key pair.

No special software. No complex infrastructure. No certificate chain hierarchy. Just a key pair that you designate for signing. This is different from X.509 PKI where you typically need a full CA application or managed service—SSH certificates work with native OpenSSH out of the box.

┌─────────────────────────────────────────┐
│       SSH Certificate Authority         │
│                                         │
│  ┌─────────────┐    ┌─────────────┐     │
│  │ Private Key │    │ Public Key  │     │
│  │   (signs)   │    │  (verifies) │     │
│  └─────────────┘    └─────────────┘     │
│        │                   │            │
│        ▼                   ▼            │
│   Keep SECRET         Distribute to    │
│   (offline/HSM)      servers/clients   │
└─────────────────────────────────────────┘

2. One CA or Two? The Architecture Decision

Best practice: Separate CAs for users and hosts.

┌─────────────────┐         ┌─────────────────┐
│    User CA      │         │    Host CA      │
│                 │         │                 │
│ Signs: user     │         │ Signs: server   │
│ certificates    │         │ certificates    │
│                 │         │                 │
│ Trusted by:     │         │ Trusted by:     │
│ SERVERS         │         │ CLIENTS         │
└─────────────────┘         └─────────────────┘

Why separate CAs? (Threat model perspective)

3. Creating the CA Key Pairs

On your CA host, create a dedicated directory and generate two key pairs:

mkdir -p /etc/ssh/ca
chmod 700 /etc/ssh/ca

User CA (signs user certificates):

ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "user-ca@example.com"

Host CA (signs host certificates):

ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "host-ca@example.com"

Flags explained:

Output files:

/etc/ssh/ca/
├── user_ca          # Private key - PROTECT THIS
├── user_ca.pub      # Public key - distribute to servers
├── host_ca          # Private key - PROTECT THIS
└── host_ca.pub      # Public key - distribute to clients

4. Protecting CA Private Keys

The CA private key is the crown jewel. If compromised, attackers can forge any certificate.

Protection levels (choose based on your risk tolerance):

chmod 600 /etc/ssh/ca/user_ca
chmod 600 /etc/ssh/ca/host_ca
chown root:root /etc/ssh/ca/*

5. CA Key Algorithm Choices

Ed25519 is recommended, but here are your options:

ssh -V
# Ed25519 supported in OpenSSH 6.5+ (2014)

6. Distributing CA Public Keys

The public keys need to go to the right places:

Distribution methods:

7. Signing Workflow

Now your CA is ready to sign certificates.

Sign a user certificate:

ssh-keygen -s /etc/ssh/ca/user_ca \       # Sign with User CA
  -I "username@example.com-$(date +%Y%m%d)" \  # Key ID for audit logs
  -n username,admin \                     # Allowed principals (usernames)
  -V +24h \                               # Valid for 24 hours
  /path/to/user_key.pub                   # User's public key to sign

Sign a host certificate:

ssh-keygen -s /etc/ssh/ca/host_ca \       # Sign with Host CA
  -I "server01.example.com-$(date +%Y%m%d)" \  # Key ID for audit
  -h \                                    # Mark as HOST certificate
  -n server01.example.com,server01,10.0.1.50 \ # Hostnames/IPs this cert is valid for
  -V +52w \                               # Valid for 52 weeks (1 year)
  /etc/ssh/ssh_host_ed25519_key.pub       # Server's host public key

→ See SSH User Certificates for detailed user signing options.
→ See SSH Host Certificates for detailed host signing options.

8. Validity Period Strategy

How long should certificates be valid?

User certificates: Short

Host certificates: Longer

9. Operational Procedures

For user certificates with short validity, you need an efficient signing process:

# User sends public key
# Admin signs and returns certificate
ssh-keygen -s /etc/ssh/ca/user_ca -I "user-$(date +%Y%m%d)" -n user -V +24h user.pub

Certificate renewal check:

# Check expiration
ssh-keygen -L -f /etc/ssh/ssh_host_ed25519_key-cert.pub | grep "Valid:"

# Example output:
# Valid: from 2025-01-14T00:00:00 to 2025-07-14T00:00:00

10. CA Key Rotation

Eventually, you'll need to rotate CA keys. Plan for this:

When to rotate:

• • Suspected compromise
• • Staff with CA access leaving
• • Compliance requirements (annual rotation)
• • Algorithm upgrades (RSA → Ed25519)

Rotation procedure:

11. Audit and Logging

Track what gets signed:

Basic logging:

# Log every signing operation
ssh-keygen -s /etc/ssh/ca/user_ca ... 2>&1 | tee -a /var/log/ssh-ca-signing.log

Better: Structured signing script

#!/bin/bash
# sign-user-cert.sh
# Minimal example – adapt paths and logging for your environment

USER_KEY="$1"
PRINCIPALS="$2"
VALIDITY="${3:-+24h}"

TIMESTAMP=$(date -Iseconds)
KEY_ID="$(basename $USER_KEY .pub)-${TIMESTAMP}"

# Sign the certificate
ssh-keygen -s /etc/ssh/ca/user_ca \
  -I "$KEY_ID" \
  -n "$PRINCIPALS" \
  -V "$VALIDITY" \
  "$USER_KEY"

# Log the operation
echo "$TIMESTAMP | SIGN | $KEY_ID | principals=$PRINCIPALS | validity=$VALIDITY" >> /var/log/ssh-ca.log

What to log:

• • Timestamp
• • Key ID
• • Principals granted
• • Validity period
• • Who requested the certificate
• • Who approved (if applicable)

12. Quick Start Checklist

Ready to set up your SSH CA? Here's the condensed version:

mkdir -p /etc/ssh/ca
chmod 700 /etc/ssh/ca

ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "user-ca@example.com"
chmod 600 /etc/ssh/ca/user_ca

ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "host-ca@example.com"
chmod 600 /etc/ssh/ca/host_ca

# On servers, /etc/ssh/sshd_config:
TrustedUserCAKeys /etc/ssh/user_ca.pub

# On clients, ~/.ssh/known_hosts:
@cert-authority *.example.com ssh-ed25519 AAAA...

FAQ

Related Guides

→ Explore all SSH topics in our Guide Collection