LEARN. PRACTICE. GROW.Separate authentication elements
An OpenSSH user certificate associates a public key with identity and options signed by a CA. It is not an X.509 certificate for a website. The client still needs access to corresponding private material through a file, agent, or suitable device. The CA private key serves issuance and must not be copied to every executor as a job credential. In the exercise, distinguish five elements: intended account, certified principal, trusted CA, validity interval, and session restrictions. A signature does not replace the other authorization requirements.
Inspect local issuance
The lab creates a disposable CA and user key. Issuance sets Key ID dr-batch-27, principal batch, serial 27, validity on October 2, 2026 from 09:00 to 10:00 UTC, -O clear, and force-command=/usr/bin/true. Then ssh-keygen -L confirms those fields and the absence of permission extensions. The interval is deliberately fixed for reproducible interpretation; this is not a credential intended for real access. The forced command was not executed. All temporary private keys are removed when the runner ends.
Connect principal and account
Key ID identifies issuance for logging; it is not automatically the authorized remote account. In the path where the CA is in TrustedUserCAKeys and there is no principals file or command, the account name must appear in the certificate principal list. If the account is deploy and the only principal is batch, a valid signature does not resolve the difference. Where AuthorizedPrincipalsFile exists, review the mapping applicable to the account. Other CA trust mechanisms, such as authorized_keys, have their own rules; do not transfer conclusions between mechanisms without identifying the effective path.
Interpret validity and restrictions
An attempt at 10:30 UTC falls outside the observed interval. Plan issuance and renewal for new authentications without confusing that interval with a guarantee that every open session ends at the same time. Options also have semantics: an unknown critical option causes refusal; an unknown extension may be ignored. A mandatory restriction needs the appropriate mechanism and validation on the target version. The lab’s clear removes default permissions and inspection shows force-command, but these fields demonstrate neither server acceptance nor command execution.
Prepare the operational acceptance decision
The final case requests a 10:30 job using the exercise certificate and a different command. The decision is to correct authorized issuance and validate account, trust, authentication, and behavior on the appropriate target. Successful -L is only local inspection. Evidence.json records version, commands, six observation groups, and runner hash; it contains no private keys. Summary: a public certificate does not replace key possession, CA trust does not replace account authorization, and validity requires planning. Connect this lesson with automation, least privilege, renewal, and access recovery.
The local certificate showed principal batch and one-hour validity; no server authentication occurred.
Common pitfalls
Key ID as account; -L as login; trusted CA as universal access; validity as session lifetime.
Related topics: SSH connection and server identity · Key authentication and remote accounts · Effective configuration and reproducing failures
Confirm each authentication and authorization condition before relying on the credential in a job.
Reference: ssh-keygen(1) · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary