Back to Blog
Technical January 15, 2026

Certificate-Based SSH Authentication Explained

SSH keys have been the default for decades. They are also one of the biggest unmanaged attack surfaces in most organizations. Here is how certificates fix this.

How SSH Certificates Work

SSH certificates are built into the OpenSSH protocol and have been supported since OpenSSH 5.4 (released in 2010). Instead of trusting individual public keys placed in authorized_keys files, the server trusts a Certificate Authority (CA). The CA signs short-lived certificates that are issued to users on demand.

Each certificate contains:

  • The user’s public key
  • The user’s identity (email, username)
  • A list of permitted principals (server-side usernames like root, ubuntu)
  • A validity window (e.g., valid for 12 hours)
  • Optional extensions (port forwarding, PTY allocation)
  • The CA’s signature

The server is configured to trust the CA’s public key (a single line in sshd_config). When a user presents a certificate signed by that CA, the server validates the signature, checks the validity window, and verifies that the requested principal is permitted. If everything checks out, access is granted.

User CA vs Host CA

A complete certificate-based SSH deployment uses two CAs:

User CA

The User CA signs certificates for people. When a user authenticates (via SSO, OIDC, or local credentials), the User CA issues a short-lived certificate embedding the user’s identity, their roles, and which server-side principals they can use.

Servers trust the User CA’s public key. This replaces all authorized_keys files with a single trust anchor. Add a new user? Sign them a certificate. Remove a user? Stop signing certificates for them. No servers need to be touched.

Host CA

The Host CA signs certificates for servers. When a Mezite agent joins the cluster, the Host CA issues a certificate for that node’s host key. This lets users verify that they are connecting to a legitimate server, not an impostor.

Without host certificates, users see the dreaded “The authenticity of host cannot be established” warning and learn to type “yes” without thinking. With host certificates, the user’s SSH client automatically verifies the host’s identity against the Host CA. No warnings, no TOFU (trust on first use), no man-in-the-middle risk.

Traditional SSH (keys) bash 
# Every server has authorized_keys files
$ cat /home/ubuntu/.ssh/authorized_keys
ssh-ed25519 AAAAC3Nz... alice@laptop     # Who is this?
ssh-ed25519 AAAAC3Nz... bob@workstation  # Still active?
ssh-rsa AAAAB3Nz...                      # No comment, no idea
ssh-ed25519 AAAAC3Nz... deploy-key       # What does this grant?
# 47 more keys...

# No expiry. No audit. No identity. No revocation.
Certificate-based SSH (Mezite) bash 
# Server trusts one CA (configured once)
$ grep TrustedUserCA /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/mezite_user_ca.pub

# No authorized_keys files needed.
# User authenticates through Mezite:
$ msh login --proxy=access.example.com --user=alice
> Logged in as alice@example.com

# Certificate issued automatically:
>   User: alice@example.com
>   Principals: [alice, ubuntu]
>   Valid: 2026-01-15 09:00 - 2026-01-15 21:00 UTC
>   Roles: [developer, staging-access]

# Connect — certificate presented automatically:
$ msh ssh --login=ubuntu staging-web-01
ubuntu@staging-web-01:~$

Why Short-Lived Certificates Beat Static Keys

Automatic Expiry

A 12-hour certificate issued at 9 AM stops working at 9 PM. There is no key rotation process because there are no long-lived keys to rotate. Tomorrow, the user gets a new certificate. If they do not log in, they have no access. If they leave the company, they cannot get new certificates.

Embedded Identity

Every certificate carries the user’s identity — their email, their roles, their permitted principals. When the server receives a certificate, it knows exactly who is connecting and what they are authorized to do. This flows through to audit logs, session recordings, and access decisions.

Centralized Revocation

When a user leaves or a compromise is suspected, you revoke access in one place: the Mezite Auth Service. The user can no longer obtain new certificates, and their existing certificates expire within hours. No servers to update, no authorized_keys files to edit, no risk of missing a forgotten key on a forgotten server.

Auditable by Design

Every certificate issuance is an auditable event. Mezite records when certificates are issued, to whom, with what permissions, and for how long. Combined with session recording, you get a complete chain from authentication through authorization to the actual terminal session. Auditors get everything they need.

How Mezite Automates the Whole Thing

Running your own SSH CA manually is possible but operationally painful. You need to generate and secure the CA keypair, build a signing service, handle certificate issuance, configure every server to trust the CA, manage revocation, and build audit logging around all of it.

Mezite automates the entire certificate lifecycle:

  • CA generation — Ed25519 CA keypairs are generated automatically on first start and stored encrypted in the database (SQLite or PostgreSQL).
  • User certificate issuance — When a user logs in through msh login, the Auth Service signs a certificate with their identity, roles, and principals. No manual steps.
  • Host certificate issuance — When an agent joins the cluster, the Auth Service signs a host certificate. Users automatically trust the host.
  • Server configuration — The agent configures sshd to trust the User CA and present the host certificate. No manual sshd_config editing.
  • Certificate renewal — The mezd identity daemon can automatically renew certificates for CI/CD pipelines and service accounts.
  • Audit trail — Every certificate operation is logged as a structured audit event.

The result is a complete SSH CA infrastructure that requires zero manual certificate management. Users authenticate, get certificates, and connect. Hosts join the cluster and get certificates. Everything is logged.

Making the Switch

Moving from SSH keys to certificate-based authentication does not require changes to your servers’ SSH daemon configuration or your users’ SSH clients. OpenSSH has supported certificates natively for over fifteen years. Mezite handles the CA management, the certificate issuance, and the server configuration automatically through the agent.

Start with the SSH Access Guide to set up certificate-based SSH access in your Mezite cluster. If you are evaluating Mezite for the first time, the Quickstart Guide will get you to a working cluster in under five minutes.

MT

Mezite Team

Engineering