SSH User Certificates Bind CA Trust to Principals

Managing SSH access with individual public keys is straightforward at small scale. Each server can keep a list of accepted keys in authorized_keys. As the number of people and hosts grows, however, access control also becomes a key-distribution problem: adding, rotating, and removing identities requires changes across the machines that trust them.

OpenSSH user certificates provide a different trust model. A server can trust a user certification authority (CA), then accept user certificates signed by that CA when the certificate also satisfies the server’s authentication policy. The CA signature answers only part of the decision. Principals, validity intervals, certificate options, and server configuration determine where and how the signed key may be used.

A CA signature is not an account mapping

An OpenSSH user certificate contains a public key, identity metadata, principal names, a validity interval, and optional restrictions or permissions. The CA signs that structure. A server configured with TrustedUserCAKeys can verify the signature against a trusted CA public key.

That verification establishes that the certificate was issued by a trusted signer and has not been altered without invalidating the signature. It does not, by itself, mean that every certificate from that CA should authenticate as every local account.

Principals provide the binding between certificate identity and the account policy enforced by sshd. A certificate can be issued with explicit principals:

ssh-keygen -s user_ca -I alice-prod -n alice -V +8h alice.pub

Here, alice-prod is the key identifier and alice is a certificate principal. The identifier is useful for identification and logging; the principal participates in authorization.

Server policy decides which principals are accepted

With a CA configured through TrustedUserCAKeys, OpenSSH can use AuthorizedPrincipalsFile to list principal names accepted for a local account. A certificate must contain a matching principal when that mechanism is configured.

A minimal server-side shape can look like this:

TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

For a local account named deploy, its principals file might contain:

release-bot
platform-operator

A certificate carrying release-bot can then be considered for authentication to that account, subject to the rest of the SSH policy. This separates the identity namespace encoded in certificates from local Unix account names.

If no authorized-principals file or command is configured for certificates trusted through TrustedUserCAKeys, OpenSSH’s default principal check requires the target username to appear in the certificate’s principals list. Explicit principal mapping is useful when identity names and account names should not be identical.

Short validity reduces dependence on key removal

Certificates can carry a bounded validity interval. The -V option to ssh-keygen sets when a signed certificate is acceptable. An issuer can therefore create credentials intended to expire after a limited period instead of treating every issued public key as an indefinite server-side entry.

Expiration does not eliminate revocation requirements. A compromised certificate may still need to be rejected before its validity interval ends, and compromise of the CA private key is a separate, more serious event. Short validity narrows the time window of an issued credential; it does not make revocation or CA protection unnecessary.

The CA private key deserves stronger controls than ordinary user keys because its compromise can permit issuance of certificates that servers trusting that CA may accept. Operational designs commonly separate signing authority from target hosts so those hosts need only the CA public key.

Certificate options constrain session capabilities

OpenSSH user certificates can include critical options and extensions. Issuance can, for example, force a command or remove capabilities such as port forwarding, agent forwarding, PTY allocation, user RC processing, or X11 forwarding.

A certificate for an automated task can be narrower than an interactive operator credential:

ssh-keygen -s user_ca \
  -I backup-job \
  -n backup \
  -V +2h \
  -O clear \
  -O force-command=/usr/local/bin/run-backup \
  backup.pub

-O clear removes the default certificate permissions before selected properties are added. A forced command changes what the authenticated session can execute. Exact restrictions still need to match the service design; a forced command is not a substitute for securing the invoked program and its inputs.

Critical options and extensions also have different compatibility semantics. An implementation that does not recognize a critical option must reject the certificate, while an unrecognized extension may be ignored. That distinction matters when defining custom certificate policy.

Principal scope belongs in the issuance boundary

A broad CA with unrestricted issuance can collapse several intended trust boundaries into one. If the same signer can issue any principal for production, development, automation, and administrative accounts, possession of that signing authority carries the combined reach of those namespaces.

The certificate format cannot compensate for an issuer that grants principals too broadly. The signing service must authenticate the requester, decide which principals that requester may receive, choose an appropriate validity interval, and apply required options before signing.

This makes CA policy part of the access-control system rather than a mechanical key-signing step. A request for a certificate representing release-bot should be evaluated as a request for that identity, not merely as a request to sign a public key.

Host certificates solve a different authentication direction

OpenSSH also supports host certificates. A host certificate lets clients authenticate a server host through a trusted host CA. User certificates operate in the opposite direction: they let servers authenticate connecting users through a trusted user CA.

Keeping those roles distinct simplifies trust analysis. A key trusted to certify hosts does not automatically need authority to certify users, and deployments can use separate CA keys for the two purposes.

The useful boundary is CA plus policy

SSH certificates reduce the need to copy individual user public keys to every server, but centralization changes the failure model. The CA becomes a high-value authority, principal issuance becomes an authorization decision, and server-side mappings remain part of enforcement.

A sound deployment keeps those responsibilities explicit: protect the CA private key, issue only permitted principals, use bounded validity appropriate to the access path, constrain certificate capabilities where needed, and configure servers to accept only the intended principal mappings. The result is not trust in a signature alone. It is trust in a signed identity constrained by local SSH policy.

References

Cybersecurity OpenSSH SSH Certificates