OpenSSH Certificates: The Complete Guide to SSH Certificate Authentication

An OpenSSH certificate is a digitally signed SSH public key containing additional information about the identity, validity and permitted use of that key.

The certificate is signed by an SSH Certificate Authority (CA), allowing systems that trust the CA to verify the certificate without maintaining a separate trusted public key for every user or host.

Unlike traditional SSH public-key authentication, where a server typically maintains individual authorized public keys, certificate authentication establishes trust through the authority that issued the certificate.

An OpenSSH certificate can contain:

• The public key being certified.
• A certificate type identifying it as a user or host certificate.
• A unique serial number.
• A key identifier.
• One or more valid principals.
• A validity period.
• Critical options and extensions.
• The certificate authority's public key.
• A digital signature created by the certificate authority.

The corresponding private key remains with the user or host. It is not included in the certificate.

OpenSSH certificates use a format native to OpenSSH. They are not X.509 certificates and do not require a traditional public key infrastructure based on TLS certificate chains.

Traditional SSH public-key authentication relies on a straightforward trust relationship.

A user possesses a private key, and the SSH server has a corresponding public key configured as authorized for an account.

During authentication, the user proves possession of the private key. The server verifies that the public key is authorized and accepts the authentication when the relevant checks succeed.

This works well for individual servers and small environments.

However, in larger environments, maintaining these trust relationships can become an administrative burden.

Every user key may need to be distributed to multiple servers. When a user changes roles, leaves an organization or loses a device, administrators must ensure that access is removed wherever that key was authorized.

OpenSSH certificates separate the authentication credential from the distribution of individual trusted user keys.

A server can trust a CA public key, while the CA signs certificates for authorized users. Each certificate can carry information about its permitted identities and validity period.

The server still applies authorization policy, but it no longer needs every individual user public key to be installed in its authorized_keys file.

OpenSSH certificate authentication involves three principal components:

1. An SSH Certificate Authority that signs public keys.
2. A user or host possessing a private key and corresponding certificate.
3. An SSH endpoint configured to trust the issuing authority.

Consider a user connecting to an SSH server.

First, the user generates an SSH key pair. The private key remains under the user's control, while the public key is submitted to a certificate authority.

The certificate authority determines whether the request should be approved. That decision may involve identity verification, access policy, or an external authorization system.

If approved, the authority signs the public key and issues an SSH user certificate.

The user then connects to the SSH server using the private key and certificate.

The server verifies that the certificate was signed by a trusted authority, checks its validity period, evaluates the permitted principals and applies any additional authentication or authorization restrictions.

The client must also prove possession of the private key corresponding to the certified public key.

If the checks succeed, the server can authenticate the user without requiring that individual's public key to be installed in an authorized_keys file.

An important property of OpenSSH certificates is that certificate validation can happen locally.

Once a server trusts a CA public key, it can verify certificates issued by that authority without contacting the CA for every SSH connection.

This reduces dependencies during authentication and allows certificate-based SSH access to operate even when the issuing service is temporarily unavailable.

However, it also makes protection of the CA private key critically important.

An attacker who obtains a trusted CA signing key may be able to issue certificates accepted by systems trusting that authority, subject to their configured authorization policies.

User certificates authenticate users connecting to SSH servers.

A user certificate binds a public key to one or more principals and can specify restrictions and an expiration time.

For example, an organization might issue a certificate permitting a developer to authenticate as the deploy account for a limited period.

The server must be configured to trust the issuing user CA and authorize the relevant certificate principal for the target account.

User certificates are particularly useful for centralized access management and short-lived infrastructure credentials.

Host certificates authenticate SSH servers to clients.

Normally, SSH clients identify servers using stored host public keys, often recorded in a known_hosts file.

This can produce host-key verification warnings when infrastructure is rebuilt, replaced or dynamically provisioned.

With host certificates, a trusted CA signs the host's public key and includes the hostnames or identities for which that certificate is valid.

SSH clients configured to trust the host CA can verify the host certificate without individually recording every server's public key.

Host certificates are useful in environments where servers are frequently created, replaced or reconfigured.

Although the underlying cryptographic mechanisms are similar, user and host authentication represent different trust relationships.

Using separate CA keys for user certificates and host certificates provides clearer separation of responsibilities and reduces the impact of a compromised signing authority.

For production environments, separate authorities are generally preferable.

An SSH Certificate Authority is fundamentally an SSH key pair used to sign other SSH public keys.

The CA private key creates certificate signatures. The corresponding CA public key is distributed to systems that should trust those signatures.

OpenSSH provides the tools needed to create a CA and sign certificates through ssh-keygen.

A basic Ed25519 CA key pair can be created with:

The private key, ssh_user_ca, must be protected.

The public key, ssh_user_ca.pub, can be distributed to servers that should trust certificates issued by this authority.

The referenced file must contain the trusted CA public key.

The SSH daemon must be reloaded or restarted for the configuration change to take effect.

However, trusting a CA does not mean every certificate issued by that authority automatically grants access to every account.

The server must still authorize the certificate's principals for the requested account, using the applicable OpenSSH authorization rules.

In production, explicit principal authorization is recommended rather than relying solely on matching a certificate principal to a local account name.

The following example demonstrates the basic process of generating a user key, signing its public key and inspecting the resulting certificate.

These commands illustrate the mechanism. Production certificate authorities should use stronger operational controls than a manually operated signing key.

Principals are an important part of OpenSSH certificate authorization.

A principal identifies an identity or role for which a certificate may be accepted.

For example, a certificate might contain the principals:

A file associated with the target account can list the principals permitted to authenticate as that account.

This allows an organization to separate the identity represented by a certificate from the local account being accessed.

It also enables role-based authorization patterns without distributing individual user public keys to every server.

The exact authorization behavior depends on how the server is configured and whether certificates are trusted through TrustedUserCAKeys or another supported mechanism.

One of the most useful capabilities of OpenSSH certificates is their built-in expiration.

A certificate can be issued for a limited validity period, such as 15 minutes, one hour or one working day.

Once the certificate expires, it can no longer be used to establish a new authenticated SSH session.

This limits the time during which a stolen certificate and its corresponding private key can be used for new authentication attempts.

Traditional SSH public keys do not have an equivalent built-in expiration mechanism.

Long-lived credentials create a persistent security concern.

A private key copied from an employee's laptop or exposed through an insecure backup may remain useful until administrators discover the compromise and remove the corresponding authorization.

Short-lived certificates reduce this exposure by limiting the validity of issued credentials.

However, certificate expiration is not a substitute for securing private keys, enforcing access policies or responding to compromise.

A stolen private key and a currently valid certificate may still be used during the certificate's remaining validity period.

Furthermore, expiration generally prevents new authentication; it does not automatically disconnect an SSH session that has already been established.

Short certificate lifetimes are most practical when issuance is automated.

Users should not need to contact an administrator whenever a certificate expires.

Instead, a certificate issuance service can authenticate the user, evaluate access policy and issue a fresh certificate for an approved purpose and duration.

This is where SSH certificates become particularly valuable as part of a modern infrastructure access architecture.

Certificate expiration and certificate revocation solve related but different problems.

Expiration defines when a certificate ceases to be valid.

Revocation allows administrators to reject a certificate or key before its normal expiration.

OpenSSH supports Key Revocation Lists (KRLs), which can be used to revoke certificates and public keys.

A server can be configured to consult a revocation file using:

Revocation requires an operational process for creating and distributing updated revocation information to the systems that enforce it.

Because OpenSSH certificate validation can occur locally, there is no inherent requirement for a server to contact a central revocation service during every authentication attempt.

This is one reason short-lived certificates are attractive: they can reduce dependence on distributing individual certificate revocations.

However, expiration alone does not provide immediate revocation.

Organizations with strict access termination requirements must consider how to revoke credentials promptly, remove trust, update authorization policies and address existing sessions.

Renewal normally means issuing a new certificate, potentially using the same public key, after the appropriate identity and authorization checks.

A well-designed issuance process should not assume that possession of a previously issued certificate automatically entitles the holder to another.

Authorization should be evaluated when new access is requested.

OpenSSH provides the cryptographic foundation for certificate-based authentication.

It does not, by itself, provide a complete organizational access management system.

As certificate adoption grows, several operational questions emerge:

These are primarily identity, authorization and lifecycle management problems rather than limitations of the OpenSSH certificate format.

This distinction matters.

OpenSSH certificate authentication solves the problem of establishing cryptographic trust without distributing every user's public key to every server.

Managing certificate-based access across an organization requires additional infrastructure and policy.

A certificate management system can connect existing identity providers to certificate issuance, evaluate authorization policies and automate the delivery of short-lived credentials.

The underlying SSH connection can continue to use standard OpenSSH clients and servers.

This allows organizations to improve access management without necessarily introducing a proprietary SSH protocol or replacing their existing SSH tooling.

SSH Teams is Jadaptive's solution for managing certificate-based SSH access.

It builds on native OpenSSH certificate authentication to provide controlled, short-lived credentials linked to identity and access policy.

Rather than requiring administrators to manually sign user keys and distribute certificates, SSH Teams provides an operational layer around certificate issuance and access management.

Its approach is designed around three principles:

OpenSSH provides the authentication mechanism. SSH Teams helps organizations manage the people, devices and policies involved in using it.

The word "certificate" often causes confusion because many engineers are familiar with X.509 certificates used for HTTPS and TLS.

OpenSSH certificates use a different format and trust model.

An OpenSSH certificate is an SSH public key accompanied by certificate metadata and a signature from an SSH CA.

It does not require X.509 certificate chains, browser-style certificate validation or a traditional TLS public key infrastructure.

Both systems use public-key cryptography and digital signatures to establish trust, but their formats and operational mechanisms differ.

For SSH certificate authentication, use OpenSSH's native certificate facilities rather than assuming that a conventional TLS certificate can be used interchangeably.

For practical OpenSSH certificate commands, including CA generation, signing, certificate inspection and configuration, consult the Jadaptive OpenSSH Certificate Cheatsheet.

OpenSSH Certificate Cheatsheet

For organizations evaluating automated short-lived SSH access, explore SSH Teams.

SSH Teams