Short-Lived SSH Certificates: How They Work and Why They Matter

A short-lived SSH certificate is an OpenSSH certificate issued with a relatively brief validity period.

It contains a public key, certificate metadata and a digital signature from a trusted SSH Certificate Authority.

The certificate also specifies when it becomes valid and when it expires.

A certificate might be issued for 15 minutes, one hour or the duration of an approved administrative task.

There is no single required lifetime.

The appropriate duration depends on the organization's security requirements, authentication mechanisms, operational processes and tolerance for interrupted workflows.

The underlying authentication mechanism remains standard OpenSSH certificate authentication.

The distinction is operational: certificates are intentionally temporary rather than issued for months or years.

OpenSSH does not define a special certificate type called a short-lived certificate.

A short-lived certificate is simply a normal SSH certificate with a restricted validity interval.

For example:

This signs the user's public key and issues a certificate valid for approximately 15 minutes from the signing time.

The resulting certificate can be used for authentication only while it is valid, subject to the server's trust and authorization requirements.

The private key is still required.

A certificate does not replace the key pair or eliminate the need to protect private keys.

Traditional SSH public-key authentication typically depends on public keys stored in server-side authorization files or managed through another authorization mechanism.

These keys do not contain a built-in expiration time.

Once authorized, a key may remain usable until the server's configuration changes or another control prevents its use.

This creates several operational challenges.

Short-lived certificate authentication uses the same trust model as ordinary OpenSSH certificates.

The SSH server trusts a certificate authority rather than requiring each user's public key to be individually installed.

The certificate authority signs a public key and includes a validity interval and permitted principals.

When the client connects, the server verifies the certificate signature, checks its validity and applies its authorization policy.

The client must prove possession of the corresponding private key.

A typical automated workflow consists of six stages.

The user authenticates with a trusted identity system.

This might involve an existing organizational identity provider, multifactor authentication or another approved authentication mechanism.

The certificate authority should not issue credentials merely because someone possesses an SSH public key.

The issuing system determines whether the user is permitted to access the requested infrastructure.

This may include evaluating identity, group membership, requested principals, device information or other organizational policies.

Authentication establishes who is requesting access.

Authorization determines what that identity is permitted to do.

If the request is approved, the certificate authority signs the user's public key.

The resulting certificate contains the permitted principals, validity interval and any applicable restrictions.

The CA private key remains protected by the issuing system.

The user's private key does not need to be transferred to the CA.

The user connects with a standard OpenSSH client using the private key and issued certificate.

The server validates the certificate against its configured trust and authorization rules.

No proprietary SSH authentication protocol is required.

After the validity interval ends, the certificate is no longer accepted for new authentication.

The user cannot simply continue establishing new connections with the expired certificate.

When additional access is required, the user requests a new certificate.

The issuing system can re-evaluate identity and authorization before granting another temporary credential.

This creates opportunities to enforce current access policies rather than relying indefinitely on previously distributed credentials.

One of the most important distinctions in short-lived SSH authentication is the difference between certificate validity and session lifetime.

An SSH certificate is checked during authentication.

Once the connection has been authenticated, the certificate's expiration does not automatically terminate that established SSH session.

For example, a user might authenticate with a certificate valid for 15 minutes and maintain an SSH session for several hours.

The certificate could expire while the session remains connected.

The expired certificate would no longer be valid for establishing a new authenticated connection, but the existing session would not automatically close simply because the certificate expired.

This distinction matters when designing access policies.

Short-lived certificates reduce the window for new authentication using compromised credentials.

They are not, by themselves, a mechanism for enforcing maximum session duration.

Organizations requiring immediate access termination or strict session time limits need additional controls.

SSH key rotation and short-lived certificates address related but different security concerns.

Key rotation replaces cryptographic key material.

Certificate expiration limits how long a particular authorization credential remains valid.

These mechanisms are complementary.

With traditional SSH public-key authentication, rotating a key generally involves generating a replacement key pair, distributing the new public key to authorized systems and removing the old authorization.

The process can become complicated when a key is used across multiple servers.

Rotation also does not guarantee that an old key has been removed everywhere.

With certificate-based authentication, a user's public key can be signed repeatedly with new certificates.

Each certificate can contain updated principals, restrictions and validity periods.

The underlying key pair does not necessarily need to change every time a certificate is issued.

This separates the lifecycle of the cryptographic key from the lifecycle of the authorization credential.

There is no universally correct certificate lifetime.

Shorter validity periods reduce the time during which a stolen certificate can be used for new authentication, but they also increase the frequency with which users or automated systems need fresh credentials.

The appropriate lifetime depends on the environment.

Yes.

OpenSSH supports certificate and key revocation through mechanisms including Key Revocation Lists.

However, certificate expiration and revocation are different controls.

Expiration occurs automatically when the validity interval ends.

Revocation allows a credential to be rejected before its scheduled expiration, provided the relevant systems have received and enforce the revocation information.

For example, an administrator may need to revoke access immediately after discovering that a user's private key has been compromised.

Waiting for the certificate to expire may not be acceptable.

OpenSSH certificate validation normally occurs locally.

A server can verify a certificate using its trusted CA public key without contacting the issuing authority for each connection.

This is useful for reliability, but it also means that centrally revoking a certificate does not automatically inform every server.

Revocation information must be distributed or authorization must be changed through another effective mechanism.

Short-lived certificates reduce the duration of exposure, but they do not eliminate the need for incident response and revocation procedures.

Unless the SSH server consults an appropriate additional control, an existing unexpired certificate may remain usable until it expires or is revoked.

This is an important consideration when integrating certificate issuance with centralized identity systems.

A secure design must account for both future certificate issuance and credentials that have already been issued.

Short-lived credentials are only practical at scale when obtaining them is convenient.

If every certificate requires a manual administrator action, short validity periods quickly become an operational burden.

An automated issuance service can authenticate a user, evaluate policy, sign an approved public key and return a certificate.

The user can then authenticate using a standard SSH client.

Automation can also support consistent certificate lifetimes, controlled principals and issuance records.

However, automation must not become a mechanism for issuing unrestricted credentials.

The security of the system depends on the controls applied before signing.

A user successfully authenticating with an identity provider does not necessarily mean they should receive access to every server.

Certificate issuance must consider what the authenticated identity is allowed to access.

For example, an engineer may be authorized to access development infrastructure but not production systems.

The certificate issuance process should reflect that distinction.

In some environments, user identity alone is not sufficient.

Organizations may also want to evaluate the device from which access is requested.

Device trust can provide additional assurance that credentials are being issued to an approved device rather than an unknown or compromised endpoint.

However, device trust is an additional control layered around certificate issuance.

It is not an inherent property of the OpenSSH certificate format.

Automated issuance increases the importance of protecting the CA private key.

A compromised signing authority could issue unauthorized certificates that are accepted by systems trusting that authority.

Production deployments should restrict access to CA signing operations, enforce authorization before issuance and maintain appropriate monitoring and audit records.

Short-lived certificates are a useful building block for just-in-time infrastructure access.

Rather than granting permanent access to infrastructure, a system can evaluate a request and issue a temporary credential for an approved purpose.

For example, an engineer may request production access to investigate an incident.

The access management system can authenticate the engineer, evaluate the request and issue a certificate with the appropriate principal and validity period.

The engineer then connects using their normal SSH client.

When the certificate expires, it cannot be used to establish additional authenticated sessions.

However, true just-in-time access requires more than certificate expiration.

The issuing system must enforce authorization, and the infrastructure must apply the intended restrictions.

If immediate access termination is required, additional revocation or session-management mechanisms may also be necessary.

Short-lived certificates provide a cryptographic mechanism for time-limited authentication.

Just-in-time access is the broader policy and operational process built around that mechanism.

OpenSSH provides native support for certificate-based authentication, including certificate validity periods, principals and CA trust.

What it does not provide by itself is a complete organizational workflow for authenticating users, evaluating access policy and issuing temporary credentials.

SSH Teams builds on the native OpenSSH certificate mechanism to provide managed, short-lived SSH access.

It is designed to connect certificate issuance to existing identity and access controls while allowing users to continue working with standard SSH clients and servers.

Rather than distributing permanent individual public keys throughout an infrastructure estate, organizations can establish trust in a certificate authority and manage credential issuance centrally.

SSH Teams also incorporates device-trust mechanisms into its access model, providing additional controls around certificate requests.

The result is a practical approach to short-lived SSH access without requiring a proprietary SSH protocol or mandatory bastion host.

Explore SSH Teams

https://jadaptive.com/sshteam