How to Set Up an Openssh Certificate Authority for Scalable User and Host Authentication on Ubuntu Server

ByAkensai

Learning how to set up an OpenSSH Certificate Authority for scalable user and host authentication on Ubuntu Server is one of the smartest moves you can make for your infrastructure security. Managing SSH keys manually across dozens of servers quickly becomes a nightmare. Keys get lost, revocation is painful, and auditing who has access to what is nearly impossible. An OpenSSH CA solves all of this. It lets you sign user and host keys centrally, so you trust the CA instead of tracking individual public keys. In this tutorial, you’ll build a working CA from scratch, sign both user and host certificates, and configure your servers to trust them automatically. By the end, you’ll have a scalable, auditable SSH authentication system running on Ubuntu Server.

Prerequisites for Setting Up an OpenSSH Certificate Authority

Before you start, make sure you have the following in place.

Required software and access:

  • Ubuntu Server 20.04 or 22.04 (CA machine and at least one target server)
  • OpenSSH 7.4 or later (check with ssh -V)
  • Root or sudo access on all machines
  • Basic familiarity with SSH key pairs and the Linux command line

Machines you’ll need:

  • CA machine , a secure, dedicated server or VM that generates and stores CA keys
  • Target server , the SSH server your users connect to
  • Client machine , the workstation a user connects from

Estimated time: 45–60 minutes.

Keep your CA machine offline or heavily firewalled. The CA private key is the crown jewel of this setup. If it’s compromised, every certificate you’ve signed becomes untrusted. For more background on OpenSSH certificate authentication, read the official sshd_config documentation.

Step-by-Step Guide to Building Your OpenSSH Certificate Authority on Ubuntu

See also: How to Provision a Digitalocean Droplet with Terraform and Run Post-deployment Scripts

Step 1: Generate the CA key pairs

On your CA machine, create a dedicated directory and generate two separate key pairs , one for signing user certificates and one for signing host certificates.

sudo mkdir -p /etc/ssh/ca
sudo chmod 700 /etc/ssh/ca
cd /etc/ssh/ca
sudo ssh-keygen -t ed25519 -f user_ca -C "User CA"
sudo ssh-keygen -t ed25519 -f host_ca -C "Host CA"

Use a strong passphrase for both keys. The ed25519 algorithm is fast and secure. You’ll now have four files: user_ca, user_ca.pub, host_ca, and host_ca.pub.

Step 2: Sign a host certificate for your target server

Copy the target server’s public host key to your CA machine. The default host key is usually /etc/ssh/ssh_host_ed25519_key.pub. Use scp to transfer it.

scp user@target-server:/etc/ssh/ssh_host_ed25519_key.pub /tmp/target_host.pub

Now sign it with your host CA key. Set the hostname and a validity period.

sudo ssh-keygen -s /etc/ssh/ca/host_ca 
  -I "target-server-host-cert" 
  -h 
  -n target-server.example.com 
  -V +52w 
  /tmp/target_host.pub

This creates /tmp/target_host-cert.pub. Copy it back to the target server.

scp /tmp/target_host-cert.pub user@target-server:/etc/ssh/ssh_host_ed25519_key-cert.pub

Step 3: Configure the target server to use the host certificate

On the target server, edit /etc/ssh/sshd_config and add this line.

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Restart SSH to apply the change.

sudo systemctl restart sshd

Step 4: Configure clients to trust the host CA

On each client machine, add the host CA public key to the known hosts file. This tells SSH to trust any host certificate signed by your CA.

echo "@cert-authority .example.com $(cat /etc/ssh/ca/host_ca.pub)" >> ~/.ssh/known_hosts

Replace .example.com with your actual domain pattern. Now clients won’t see the “unknown host” warning for any server with a valid signed certificate.

Step 5: Sign a user certificate

On the CA machine, sign a user’s public key. First, get their public key. Then run the signing command.

sudo ssh-keygen -s /etc/ssh/ca/user_ca 
  -I "alice-user-cert" 
  -n alice 
  -V +30d 
  /tmp/alice_id_ed25519.pub

The -n alice flag sets the principal, which must match a valid Unix username on the target server. The certificate is valid for 30 days. Send alice_id_ed25519-cert.pub back to the user.

Step 6: Configure the target server to trust the user CA

On the target server, add the user CA public key to /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

Copy user_ca.pub from your CA machine to the target server first.

scp /etc/ssh/ca/user_ca.pub user@target-server:/etc/ssh/user_ca.pub

Then update sshd_config to point to that file and restart SSH.

sudo systemctl restart sshd

Step 7: Test the connection

The user places their certificate alongside their private key. Both files must be in ~/.ssh/.

cp alice_id_ed25519-cert.pub ~/.ssh/
ssh -i ~/.ssh/alice_id_ed25519 [email protected]

If everything is configured correctly, the connection succeeds without any password prompt and without adding the host key manually. You can inspect a certificate’s details with this command.

ssh-keygen -L -f ~/.ssh/alice_id_ed25519-cert.pub

For a deeper look at certificate options and extensions, check the OpenSSH manual pages.

Troubleshooting Common OpenSSH Certificate Authority Errors

Problem: “Certificate invalid: name is not a principal”

This happens when the principal in the certificate doesn’t match the username on the server. Double-check the -n flag you used during signing. The value must match the Unix account name exactly.

Problem: Host certificate isn’t being presented

Run sudo sshd -T | grep hostcertificate on the target server. If the line is missing, your sshd_config edit didn’t save or the path is wrong. Also confirm the cert file is readable by root.

Problem: “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED”

This appears on the client if the @cert-authority line in known_hosts is missing or the domain pattern doesn’t match. Re-check the pattern and make sure there are no extra spaces.

Problem: Certificate expired

Certificates have hard expiry dates. Always automate renewal before they expire. Consider using a cron job or a secrets manager to handle this. Check expiry anytime with ssh-keygen -L -f cert.pub.

Tip: Always test with ssh -vvv for verbose output. It shows exactly which authentication methods are being tried and why they succeed or fail.

Conclusion

You now know how to set up an OpenSSH Certificate Authority for scalable user and host authentication on Ubuntu Server. This approach replaces the fragile model of copying individual public keys everywhere. Instead, you control access centrally through certificate signing. Revoking access is as simple as not renewing a certificate. Adding a new server takes minutes, not hours of key distribution. Your next steps should include automating certificate renewal, setting up a KRL (Key Revocation List) for emergency revocations, and restricting CA machine access with strict firewall rules. This setup scales cleanly from five servers to five hundred. Start small, test thoroughly, and expand with confidence.

Similar Posts