SSH user certificates: bind host login to an expiry and a narrow principal

Last updated: 5 Oct 20267 min read

tutorial

An SSH user certificate signs a user's public key with a trusted user CA and carries validity bounds and principals. A server configured with TrustedUserCAKeys can accept that CA, while its authorized-principals policy determines which certificate principal may enter a target account. Without an explicit principals file, the target username normally supplies the accepted principal. This narrows the useful life of a stolen certificate, but it does not revoke the user's private key elsewhere or remove sessions that are already open. The issuing service needs identity verification, clock health, audit records, and an emergency removal path for the CA or a compromised signer.

Operational decision

A database responder requests a certificate valid for 27 minutes with the principal db-operator. The bastion maps that principal only to a dedicated maintenance account, denies shell access to the service account, and records the certificate key ID with the ticket ID. A disposable host test tries a valid certificate, an expired one, and the same certificate against an account whose principal mapping does not match. The rollout retains a separately controlled break-glass route in case the issuer is unavailable. After expiry, a fresh login must fail; an already established session is handled through a separate incident procedure when immediate eviction is required.

TrustedUserCAKeys /etc/ssh/trust/people_ca.pub
AuthorizedPrincipalsFile /etc/ssh/principals/%u
Ticket: CHG-4726
Principal: db-operator
Lifetime: 27 minutes

Cost and verification

Short validity reduces the replay window but increases reliance on the issuer and accurate clocks. A broad principal accepted by many accounts defeats the intended boundary. Measure issuance latency, denied-login causes, expired-certificate acceptance, and remaining direct authorized_keys entries that bypass the certificate path. Test the effective sshd configuration and a real negative login on a disposable host before replacing an existing access system. A CA key held on the same general-purpose host as its issuer creates a different compromise scope than a protected signer.

Common Mistakes

Do not use a certificate principal that grants every host account.
Do not claim expiry terminates sessions already established.
Do not remove the emergency access path before the issuer failure drill.

Connected lessons

Practice and check

devops

linux

host-security