Short SSH certificates still need explicit access boundaries

A short certificate is only one boundary

A short-lived SSH certificate limits when that certificate can be accepted for a new authentication, provided the issuer sets an explicit validity interval and the server enforces the intended trust configuration. It does not decide which account should accept the identity, establish the client's trust in the server or terminate a shell that authenticated earlier. Design those decisions separately before describing a certificate service as complete access control. ^[1][2][3][4]

Consider a hypothetical maintenance request. An engineer needs access to one operational account on a defined host group. The issuer can sign a certificate containing the approved principal and validity interval. The host must still trust that issuer and authorize the principal for the target account. The client must verify that it reached the intended host. If the maintenance session later needs containment, an operator needs a separate way to identify and end the active connection.

This separation is useful because each boundary has a different owner and different evidence. The issuer knows why it signed a credential. The host knows which principals its account configuration accepts. The client knows which host identity it trusts. An incident operator may need process or connection evidence that none of those authentication decisions supplies. Combining them under the phrase short-lived access makes the design harder to review and can hide a missing control.

Use the OpenSSH manuals for the deployed version when implementing the design. The references here were reviewed on August 28, 2026, but OpenBSD's current manuals and a packaged Portable OpenSSH release are not always the same snapshot. Record the installed client and server versions and check supported options before applying configuration. Release notes can identify changed behavior, while the actual host's effective configuration remains the implementation evidence. ^[8]

The objective is a bounded certificate lifecycle with explicit permissions and operational ownership. It is not a claim that certificates eliminate every static credential, make every host equivalent or provide immediate revocation of an established session. The following procedure focuses on the issuer, the host's authorization rules and the tests that distinguish those outcomes.

The issuer decides which identity it will sign

An OpenSSH user certificate contains a public key and signed information such as principals, validity and certificate identifiers. The CA signature establishes the issuer of those claims; it does not make every claim appropriate for every host. The signing service should therefore receive an approved identity and scope, then issue only the principals and restrictions required by that request. The trust placed in the CA depends on what its issuance process is allowed to assert. ^[1][4]

Set the validity interval explicitly. The ssh-keygen manual documents a default that extends from the Unix epoch into the distant future, so merely using certificate syntax does not produce a short-lived credential. Choose the interval as a policy decision based on the access purpose and the application's operating requirements. The article does not prescribe a universally safe duration. A shorter interval can reduce the future authentication window while also increasing dependence on a functioning issuer. ^[1]

Principal selection deserves equal care. A certificate presented for a maintenance account should not acquire unrelated identities because an issuance template includes them by convenience. Record the requested principal, the approval that supports it and the target account or host scope expected to accept it. The server will make its own authorization decision, but a tightly scoped issuance policy reduces the consequences of a host configuration that is broader than intended.

Protect the CA's signing authority separately from ordinary client keys. The organization should define who can invoke signing, which approval or workload identity authorizes it, and how the issuer's own credentials are protected. Avoid distributing the CA private key to every administrative workstation merely to make certificate issuance convenient. This is an architectural recommendation: the certificate model concentrates trust in a signing authority, so the service around that authority needs its own access and recovery design.

Keep issuance records useful without retaining private key material. A certificate key identifier and serial can help connect a signed credential to a request and a later revocation action, but the record must state how those identifiers are assigned and interpreted. Do not assume that a human-readable identifier proves identity or that a serial is unique unless the issuer enforces that property. OpenSSH provides certificate and KRL mechanisms; the organization's issuer determines their operational consistency. ^[1]

Certificate options and extensions also need a policy. Review the supported restrictions against the intended maintenance task and the receiving server's behavior rather than copying every field from a sample. A restriction that is unsupported, omitted or incorrectly scoped may not produce the expected boundary. Explain any intentionally allowed forwarding or session capability in the issuance record so the operator can distinguish required functionality from a permissive default.

Source. OpenSSH ssh-keygen manual ^[1]; OpenSSH sshd_config manual ^[2]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 1 accessible table

Certificate field	Meaning	Independent check
Issuer	CA that signed the certificate	Host trusts this user CA
Principal	Claimed login identity	Target account permits the principal
Validity	Explicit authentication interval	Server checks time at authentication
Restrictions	Issuer-selected certificate constraints	Server enforces supported constraints
Serial or key ID	Certificate tracking identifier	Revocation and audit processes use it

Figure 1 accessible table

Certificate field	Meaning	Independent check
Issuer	CA that signed the certificate	Host trusts this user CA
Principal	Claimed login identity	Target account permits the principal
Validity	Explicit authentication interval	Server checks time at authentication
Restrictions	Issuer-selected certificate constraints	Server enforces supported constraints
Serial or key ID	Certificate tracking identifier	Revocation and audit processes use it

Download imageDownload table CSV

The host still decides where that identity can log in

On the server, TrustedUserCAKeys identifies trusted user certificate authorities. AuthorizedPrincipalsFile supplies a separate principal-authorization mechanism for accounts using that CA trust path. With the default principals configuration, no principals file or command is configured, and the target account's username must appear in the certificate's principals list. A configured principals file can define another accepted mapping. CA signature trust and account-level principal authorization remain separate decisions; omitting a principals file does not remove the default username check. ^[2]

The distinction between trust mechanisms matters. OpenSSH documents that AuthorizedPrincipalsFile applies to CAs trusted through TrustedUserCAKeys, not to a CA trusted through a cert-authority entry in authorized_keys. A runbook that configures one mechanism while assuming the other mechanism's principal checks apply can have a serious authorization gap. Choose the intended path, read its complete configuration contract and test it on the target server version. ^[2]

Map principals to operational accounts deliberately. If two host groups accept the same principal for different local accounts, explain that relationship instead of assuming a principal is a portable role with identical permissions everywhere. After authentication, the operating system and application permissions associated with the account still matter. The certificate's identity claims are one input to login authorization; they are not a universal description of the account's effective privileges.

Client-side host verification is another independent check. A user certificate authenticates the user to the server. It does not by itself establish that the server is the intended host. OpenSSH clients can use trusted host keys or a host-certificate trust configuration under the documented client rules. Keep the host trust distribution and update process visible in the architecture so a user certificate rollout does not encourage operators to ignore host identity warnings. ^[3][4]

Review effective configuration rather than only a template. Included configuration files, account-specific matches and deployment differences can change the policy that a particular connection encounters. Use the server's supported configuration validation and effective-setting inspection tools in an authorized test environment. The article does not provide a tested production configuration; the acceptance requirement is that the relevant account, CA and principal combination is understood on the actual host.

Be careful when transferring examples into a managed product. GitHub's SSH certificate-authority support has its own supported fields, enterprise configuration and usage rules. It is evidence for GitHub's product contract, not proof that every OpenSSH server or managed service exposes the same settings. Keep provider-specific documentation with the corresponding implementation record, and avoid presenting a product-specific limitation as an inherent property of the underlying certificate format. ^[7]

Source. OpenSSH ssh-keygen manual ^[1]; OpenSSH sshd_config manual ^[2]; OpenSSH ssh_config manual ^[3]; OpenSSH ssh manual ^[5]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 2 accessible table

Decision	Owner	Enforcement moment	Evidence
Issue identity	Certificate issuer	Before signing	Approved principal and validity
Authorize user	Host administrator	New authentication	Effective CA and principal configuration
Verify host	SSH client owner	Connection establishment	Trusted host CA or pinned host key
Distribute revocation	Access operations	Before subsequent authentication checks	Readable current KRL
End active access	Incident operator	Explicit containment action	Connection or process termination record

Figure 2 accessible table

Decision	Owner	Enforcement moment	Evidence
Issue identity	Certificate issuer	Before signing	Approved principal and validity
Authorize user	Host administrator	New authentication	Effective CA and principal configuration
Verify host	SSH client owner	Connection establishment	Trusted host CA or pinned host key
Distribute revocation	Access operations	Before subsequent authentication checks	Readable current KRL
End active access	Incident operator	Explicit containment action	Connection or process termination record

Download imageDownload table CSV

Expiry and revocation do not close an existing shell

Certificate expiry is checked when the certificate is used for authentication. A connection that has already authenticated is a different state. The OpenSSH authentication and connection model does not turn the later expiry time into an instruction to terminate that established connection. If the organization's access objective requires an active shell to end at a particular time, it needs an additional session-control mechanism and evidence that the mechanism works. ^[4][5]

The same distinction applies to revocation. OpenSSH supports key revocation lists, and the server's RevokedKeys setting identifies revocation information used in public-key authentication. Updating that information can affect subsequent authentication checks. It should not be described as proof that all earlier connections have ended. For incident containment, identify the active access paths and apply the authorized connection or process controls appropriate to the host and environment. ^[1][2]

Revocation distribution can itself cause an outage. The sshd_config manual states that if the configured RevokedKeys file is unreadable, public-key authentication is refused. Treat file creation, permissions, replacement and rollback as an operational change with a protected recovery route. An atomic distribution procedure can reduce the chance of exposing a partially written file, but its behavior still needs testing on the organization's delivery mechanism. Do not deliberately break the only administrative path on a production host to demonstrate this failure mode. ^[2]

Connection reuse deserves attention when interpreting tests. An SSH client can reuse an existing connection under supported multiplexing behavior, so a command that appears to start a new login may not exercise a fresh certificate authentication. Check the client's effective behavior and use a controlled test that actually establishes the boundary being evaluated. Otherwise, an expired-certificate test can produce a misleading result because it relied on a connection authenticated before expiry. ^[3][5]

Agent behavior is another separate concern. An agent can make signing operations available to clients, and forwarding changes where that access may be requested. Review whether agent forwarding is needed, which restrictions are supported and how the organization's client configuration handles it. A short certificate does not make an unnecessarily broad forwarding path harmless. The ssh-agent and client manuals should guide the concrete configuration rather than a generic claim that certificate lifetime solves credential exposure. ^[3][6]

For an incident, keep issuance, authentication and session evidence together without treating them as identical. An issuance record identifies a signed credential; an authentication record can identify its use; a connection or process record supports active-session handling. The exact fields available depend on the environment. State what was observed and what was not, especially when the certificate has expired but an earlier session may still be active.

Test the denied paths before broad distribution

Use a disposable or otherwise approved test host with an independent recovery channel. Begin by validating the intended client and server versions and the syntax of the proposed configuration. A syntax check can detect configuration errors, but it does not establish that the authorization policy is correct. Keep syntax validation, effective-setting inspection and actual connection tests as separate results in the acceptance record.

Test the allowed principal and the denied principal separately. The approved certificate should authenticate to the intended test account under the chosen trust mechanism. A certificate containing a principal that the account does not authorize should fail. Record the CA trust path and account policy used by the test so a later reviewer can determine whether AuthorizedPrincipalsFile or another mechanism actually supplied the decision. These are proposed tests, not results claimed by this article. ^[1][2]

Then exercise certificate validity using controlled test credentials and fresh connections. Confirm that the test does not reuse an existing authenticated transport. Observe the relevant outcome before and after the intended validity boundary, without publishing private key material or relying on a fabricated log excerpt. If the client or server clock is part of the test setup, document it; a timing result cannot be interpreted without knowing which environment performed the check.

Test revocation through the intended delivery mechanism. Create a controlled revocation entry for the test credential, distribute the file using the approved process and verify that a subsequent authentication is rejected. Also inspect permissions and failure handling without jeopardizing the recovery path. A locally generated KRL that was never delivered to the target host is not evidence of enforced revocation. The test needs both distribution and authentication observations. ^[1][2]

Finally, test host verification and the operational response to an active session. The client should reject an untrusted host identity under the intended policy. A session-containment exercise should establish and then end a controlled session through the separately authorized mechanism, recording that result independently of certificate expiry. This prevents a single successful certificate login from being used to claim that host trust and active-access termination are also complete.

Keep failures specific. An unauthorized principal accepted by the host calls for review of account authorization. A rejected valid certificate may indicate issuer trust, validity, supported options or another configuration issue. An unreadable revocation file is a distribution problem. Assign the corrective action to the boundary that failed, then repeat that test. Broadly weakening the server configuration to make the certificate work would remove the evidence the exercise was intended to produce.

The evidence an SSH certificate service should keep

A useful handoff joins the issuance request, certificate identifier, approved principals, explicit validity, trusted CA scope and target-account policy. It also records how host identities are trusted, how revocation reaches servers and who owns active-session containment. Keep references to protected key storage rather than copies of private material. The record should let an operator explain why a particular certificate was issued and where it was intended to authenticate.

Review that record when the issuer, server version, principal mapping, host trust or connection-management behavior changes. OpenSSH release notes and the deployed manuals help identify implementation changes, while the organization's tests establish whether its chosen configuration still behaves as intended. A previous successful login is evidence for the configuration exercised at that time, not a permanent approval of every future client or server update. ^[8]

Short certificates are useful when they are part of this explicit lifecycle. The issuer limits what it signs, the host limits which identities it accepts, the client verifies its destination, and an operator handles established sessions when necessary. Keeping those responsibilities separate makes the access boundary easier to test and gives the organization a precise answer when someone asks what expiry or revocation actually accomplished.