← SSH: secure access and production diagnosis
10 / 12 · 60 MIN

SSH certificates, revocation, and acceptance

Compare server-side certificate acceptance and prepare renewal, revocation, and RUN handover criteria.

Confirm certificate policy in an actual session

Earlier ssh-keygen -L observations showed local fields. certificateAccepted now demonstrates actual authentication with a trusted CA, suitable principal, and temporal validity. authorized_keys stays empty in these experiments, preventing the raw key from being accepted as fallback when the certificate is being assessed. The client also ignores the personal agent and explicitly selects identity and certificate. Compare the control with wrongPrincipal and expiredCertificate. A signature may be trusted while the account or time still fails policy. In fictional case Ria, changing Key ID would not fix a principal issued for another consumer. Action should respect intended authorization, correct issuance or approved mapping, and retest in job context. Do not generalize this configuration to every possible principal-mapping arrangement.

Distinguish an unknown restriction from valid authorization

unknownCriticalOption issues a certificate with the original critical option dr-unknown. The server identifies it as unsupported and rejects authentication. A CA signature does not make an implementation enforce a condition it does not understand. This distinction matters when issuance and operations teams evolve at different speeds. In case Lago, converting the option into something ignorable would only be acceptable if the required policy remained effectively enforced through an approved mechanism; obtaining status zero is insufficient. Define a positive test for the permitted operation and a negative test for the condition that must be rejected. The runner uses an invented field solely to observe rejection. It does not assess an issuance product, hardware device, host certificates, or every critical option supported by the release.

Treat revocation as an operational dependency

The valid control certificate is included in a temporary KRL. ssh-keygen -Q confirms that entry, and the instance using RevokedKeys rejects the same credential despite remaining within its time window. This does not mean the KRL rewrote the certificate; the server applied an additional condition. For real distribution, prepare complete content and publish it consistently. Case Farol adds a file-access failure, assessed from documentation and not executed by the runner: an unreadable configured list can prevent publickey authentication for all users. Repair acceptance should test both an allowed and a revoked credential. Removing the control to pass the positive test does not preserve the objective. CA rotation, distribution across servers, and recovery procedures still require their own experiments.

Prepare renewal and operational handover

The next guide proposes forty minutes. First classify runner results by stage and identify the positive control corresponding to each rejection. Then solve Cais and Ria: distinguish remote status from authentication and define renewal before the job’s next session. In the third block, prepare Farol’s list publication and rollback without losing mandatory revocations. In the last, decide acceptance of Lago’s profile and deliver a matrix of requirement, evidence, owner, and pending action. The guide has not yet been performed with participants. An accepted lab connection does not prove the business command, enterprise account, bastion, or scheduler environment. Summary: RUN handover should demonstrate authorized access and useful operation while retaining the ability to reject identities that fail policy.

40-MINUTE GUIDE
0–10: classify nine results by trust, authentication, and command.
10–20: solve Cais and Ria; define diagnosis and renewal before the next session.
20–30: plan Farol KRL publication and recovery; include positive and negative tests.
30–40: decide on Lago’s profile and assign pending actions.

DELIVERABLE
Requirement | evidence | permitted test | rejection test | owner | next step.

RUN THE PREVIOUS LESSON’S CODE
python3 ssh-sessions.py --ssh /path/ssh --sshd /path/sshd --sshd-session /path/sshd-session --sshd-auth /path/sshd-auth --keygen /path/ssh-keygen --output ssh-sessions-evidence.json
Use matching OpenSSH 10.5p1 executables and Python 3.
Recorded runtime: Python 3.13.1, OpenSSH 10.5p1, OpenSSL 3.6.1, built without PAM.
POSIX lab account; loopback only, temporary keys, and fixed command.
Does not change accounts, personal keys, or the system SSH service.
IN PRACTICE

Farol needs to confirm that an allowed credential authenticates and a revoked one remains rejected after repairing list publication.

Common pitfalls

Testing only issuance, letting an alternate key hide rejection, confusing validity with revocation, or making a critical restriction ignorable without preserving policy.

Related topics: Certificate operations · Change management and recovery

Take this idea with you

Access acceptance needs identity, trust, authorization, and operational result. Negative controls demonstrate that restrictions remain enforced.

Create account

Reference: OpenSSH server configuration · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary