An AI agent that uses SSH to run a permitted command or deliver a file should not require an indefinitely accepted private key on every destination. OpenSSH user certificates allow a server to trust a certificate authority’s public key, then check a short-lived statement binding a worker’s public key to named login principals, validity limits and restrictions. This is ordinary engineering for today’s automated systems, not proof that artificial superintelligence exists. The protective mechanism combines cryptographic verification with narrowly configured account authorisation. A legitimate signature on its own does not grant access to every login or operation.
The complete practical sequence is to identify a worker, generate or securely assign its key pair, approve a role, sign the public key under a protected CA, configure the destination’s permitted issuer and principals, verify the remote host, and authenticate by proving possession of the worker private key. Every issued credential should have a traceable identity and expiry. The destination still enforces account permissions, command limits and audit logging. A certificate cannot determine whether a requested action is sensible or whether retrieved instructions are malicious.
Contents
- What the certificate mechanism solves
- The four identities people commonly confuse
- Certificate fields and signatures
- CA trust must have an explicit owner
- Principals are operational roles
- A fifteen-minute certificate example with checked units
- The difference between authentication expiry and job expiry
- Host-key verification is a separate mandatory gate
- Revocation and Key Revocation Lists
- Certificate renewal without fleet-wide bursts
- Issuer outages, clocks and fail-closed behaviour
- Machine identity versus a language-model instruction
- Logging, serials and measurable outcomes
- Testing the path that must fail
- A migration plan with a reversible boundary
- Transfer problem: twelve archive workers, three gateways
- Limits and the transferable lesson
- Frequently asked questions
- Primary references
- Related reader pathways
What the certificate mechanism solves
Traditional authorized_keys files can become an administrative tangle. With twenty workers and fifteen hosts, distributing one allowed public key to every worker-host pair creates twenty multiplied by fifteen, or three hundred, placements if all workers genuinely need all hosts. A shared CA trust structure can reduce repetitive public-key distribution, although it adds responsibility for issuance security and principal mapping. This is a hypothetical configuration count, not measured administrator time and certainly not a recommendation to give every worker access to all fifteen machines.
The four identities people commonly confuse
SSH access has several identities that must not be collapsed into one. The first is the server host identity, verified through a known host key or a trusted host-certificate model. The second is the worker public key paired with a protected private key. The third is the user-certificate principal, which states a signed role or identity that accepting servers may authorise. The fourth is the remote operating-system account and its permissions. A connection can pass one check and fail another, and each check answers a different security question.
The host identity asks whether an agent is really talking to the expected machine. The worker key proves that the party initiating authentication controls a certain private key. The certificate signature asks whether the recognised CA authorised particular attributes of that public key. Principal matching asks whether the specified destination account accepts one of those roles. After login, filesystem permissions and command restrictions decide what the account can do. An operator who records only SSH succeeded cannot infer that the operation itself was authorised.
Suppose an archive uploader is signed with principal report-upload, and the server maps that principal to account ingest. It should not thereby gain permission to log in as root or reach a payroll directory. This requires a narrow mapping and narrow permissions on ingest. If the same CA is trusted elsewhere, that is not automatically a vulnerability, but a loose fallback principal can create privilege sprawl. Good diagrams therefore label the signer, principal, target account, destination and allowed command separately.
Certificate fields and signatures
OpenSSH’s ssh-keygen manual describes certificates as a public key, identifying fields, principal names, options and a CA signature. The private key is not placed in the certificate. A user certificate is different from a host certificate, and both are different from the X.509 certificates ordinarily associated with browser TLS. When authenticating, the worker offers its user certificate and demonstrates control of the related private key. The server validates the signer, permitted principal, validity interval and other constraints before accepting the requested account.
The documented ssh-keygen signing flags include -s to name the CA signing key, -I for a readable certificate identity, -n for the comma-separated principals, -V for a validity interval and -z for a serial number. Inspection uses ssh-keygen -L. These values serve different purposes. A key ID is useful to human operators and log processors; a serial allows precise correlation and revocation; principal names restrict the accounts that may accept the certificate; and time limits reduce the period during which a stolen credential can be used for fresh authentication.
An educational command shape is ssh-keygen -s ca_key -I nightly-export-20261026 -n export-writer -V +15m -z 42017 worker.pub. The example is not instructions to place a production CA key on a worker. Signing should occur only inside a protected issuance service after a separate approval check. Review the certificate with the installed OpenSSH version before deployment. Always understand which name identifies a logging record, which name authorises a remote account, and which key must remain secret.
CA trust must have an explicit owner
The TrustedUserCAKeys directive in sshd_config specifies a file of CA public keys accepted for user-certificate authentication. A server may trust a small number of well-governed signers rather than carry every worker’s public key. That creates a powerful issuance boundary. Anyone who can cause a trusted CA to sign an excessively broad certificate may create credentials accepted on many hosts. Keep signing private keys in a hardened service or protected device, restrict who can request credentials and log every certificate policy decision.
There is another trust route: a CA can appear as a cert-authority entry in an account’s authorized_keys file. The principal rules are not automatically identical between the two arrangements. The OpenBSD sshd_config manual explains that AuthorizedPrincipalsFile applies to CA keys listed under TrustedUserCAKeys, whereas a principals= key option is relevant when the CA is trusted through authorized_keys. A security review must therefore inspect the actual acceptance configuration rather than assume that one principals file restricts every possible path.
The same organisation might use different signers for staging and production. This can reduce accidental trust crossover if production servers never accept the staging signer. Separate issuers are not a substitute for destination checks: both the credential request and its acceptance need bounded roles. Document CA key rotation, emergency retirement, disaster recovery and who approves new principals. A short-lived worker certificate cannot compensate for an unaudited signer that will issue arbitrary principals indefinitely.
Principals are operational roles
A principal string is an input to an acceptance policy, not a magical operating-system group. A certificate with principal report-reader may be accepted for an archive account if that destination explicitly allows it. The server still applies Unix permission checks, access-control lists and forced commands after authentication. Conversely, adding report-reader to a certificate does not make a file read-only. Readers should trace the complete route from signer approval through principal mapping to the effective permissions of the destination process.
An unfortunate naming shortcut is to issue all agents a broad principal called automation and configure privileged accounts to accept it. That turns the CA into a near-universal key issuer. More defensible names encode the task or environment, such as test-artifact-read or production-report-upload, and server-side rules accept only the relevant strings. If an operation changes from uploading reports to deleting them, treat it as a change of authorisation rather than silently reusing the same label.
Before issuing a certificate, the service should verify who owns the workload, which environment it belongs to, which job is approved and which destination accounts that job requires. This record should not be derived solely from text provided by the agent itself. A signed certificate reflects an issuer decision, but that decision can be wrong if its upstream inventory or group membership is stale. Principal policy needs periodic review when services move, staff roles change or permissions expand.
A fifteen-minute certificate example with checked units
Take a fictional certificate valid from 10:00:00 to 10:15:00 on the same local date. The allowed start-to-end window is fifteen minutes multiplied by sixty seconds per minute, giving nine hundred seconds. At 10:04:00 the certificate has eleven minutes until expiry. At 10:12:00 it has three minutes. An attempted fresh authentication after 10:15:00 should fail the validity check when clocks and implementation behave correctly. The example concerns authentication attempts; it does not promise an ongoing SSH process will be killed exactly at expiry.
Suppose an attacker acquires the worker’s private key and its current certificate at 10:04. Without earlier detection and enforcement, the nominal remaining window for starting authenticated sessions is at most eleven minutes, ending at 10:15. This is materially different from a static key that may remain accepted for months. It is not a guarantee of harmlessness: an attacker can inflict damage quickly, and sessions opened before expiry may survive. Restrict what the account can do, monitor sessions and make revocation operational.
Imagine renewal scheduled at 10:10 with a one-minute jitter on either side. The renewal request begins between 10:09 and 10:11, leaving four to six minutes before the nominal 10:15 expiry. That is scheduling margin, not a service-level guarantee. If issuance takes longer, the host clock drifts or a network partition blocks the signer, the certificate may expire before a replacement is available. The safe response is to stop opening new privileged sessions and clearly report an issuance outage.
The difference between authentication expiry and job expiry
A common assumption is that a fifteen-minute SSH user certificate automatically creates a fifteen-minute execution limit for every remote command. That is unsafe. Certificate validity is evaluated during the authentication process, and ongoing sessions are not universally rechecked for expiry at each subsequent operation. A process established at 10:14 may remain active after 10:15 unless additional session, command or application policies end it. A strict job deadline therefore needs its own enforceable timeout and cleanup behaviour.
For a sensitive import, the destination application might grant a short operation-specific lease and confirm the lease before each destructive step. This second control addresses long-running activity that an expired initial credential does not necessarily stop. The design should also decide what happens to partially written files or transactions when a lease ends. An SSH login succeeds at one point in time; safe work may require continuing evidence of authorisation and bounded effects over many minutes.
This distinction is useful beyond SSH. A user’s badge might open a laboratory door, but opening the door does not approve every experiment performed inside. Similarly, authentication can prove possession of a key without proving that a retrieved instruction to delete a folder was trustworthy. Agents need task approval, argument checks, least-privilege remote accounts and logging of actual effects. These controls are complementary, not replacements for short-lived certificates.
Host-key verification is a separate mandatory gate
A user certificate authenticates the connecting agent to a server, but does not show that the receiving server is genuine. Agents must validate an expected server host key or a properly governed SSH host-certificate chain before exchanging sensitive material. Disabling StrictHostKeyChecking simply because an unattended job fails can allow a network adversary to impersonate the destination. Good configuration treats an unknown host key as an identity exception requiring independent review rather than an inconvenience to suppress.
For new infrastructure, distribute trusted host keys or an approved host CA through a protected configuration channel. When a host key changes, verify the event against infrastructure inventory and approved rotation, not solely against DNS. Keep host key fingerprints in logs so an incident reviewer can explain which machine was contacted. The site’s separate SFTP host-identity article examines pinned remote host keys in depth; SSH user certificates solve the other side of the connection.
Connection dashboards should record both outcomes independently: server identity verified and worker user certificate accepted for a permitted role. The first protects against credential delivery to a hostile destination; the second limits who may enter the accepted destination. Neither confirms that the resulting file transfer was correct. Add checksums, accepted paths and application-level acknowledgements when files matter. Labelling a connection secured without identifying which security property was tested is not enough.
Revocation and Key Revocation Lists
Short validity windows reduce exposure, but incident responders sometimes cannot afford to wait for the clock. OpenSSH supports a RevokedKeys configuration and key revocation lists, commonly called KRLs. Its ssh-keygen tool supports creating and checking these lists. The operational chain includes identifying the affected key or certificate, authorising a response, constructing valid revocation material, distributing it to every affected server and testing that rejected credentials really fail. An unpropagated revocation record does not protect a host that never received it.
Consider the earlier theft at 10:04. Suppose detection is confirmed at 10:05, human or automated approval takes one minute, and protected KRL deployment takes another two minutes. Under these invented assumptions a gateway could enforce revocation around 10:08, four minutes after theft and seven minutes before natural expiry. Real detection and distribution times vary; the computation illustrates the need to measure the full incident-to-enforcement path, not merely how fast a file can be generated.
The OpenBSD server documentation specifically warns that an unreadable RevokedKeys file can cause public-key authentication to fail for all users. It also recommends consistent contents and atomic replacement instead of editing revocation material in place. Test distribution and file permissions before relying on KRLs. Remember that revoking a credential for new authentication is separate from terminating sessions established earlier. Incident runbooks should explicitly address both outcomes.
Certificate renewal without fleet-wide bursts
Automation fleets can overwhelm an issuer if all machines renew on the same schedule. Suppose one hundred and twenty worker certificates last fifteen minutes and requests are uniformly spread over that nine-hundred-second period. The mean arrival rate is 120 divided by 900, or approximately 0.133 requests per second, which is eight per minute. By contrast, renewing all one hundred and twenty at the same instant presents a queue of one hundred and twenty requests. The average number of renewals can be identical while short-term capacity requirements differ enormously.
Uniform spreading is an explanatory model, not a prediction about a real fleet. Measure request bursts, issuance latency, failure rates and certificates that expire before a job reconnects. Assign per-worker offsets or bounded jitter that preserve a margin before expiry. Retries should be capped and staggered, with explicit handling when the issuer returns a delayed or ambiguous response. Avoid a fallback that quietly restores unrestricted shared static keys whenever the signer is slow.
Issuance also benefits from transaction identity. A client whose network connection times out after the signer completed its work should reconcile the original request rather than blindly create serial after serial. Use an approved request identifier and inspect any existing still-valid result before repeating work, where the issuer’s API permits. This is a workflow reliability rule, not a claim that OpenSSH itself offers an HTTP idempotency protocol. SSH certificates are the credential format; the signing service must manage request semantics.
Issuer outages, clocks and fail-closed behaviour
The server’s view of time affects whether a certificate is presently valid. A host with a slow clock can reject a newly issued credential whose valid-after time it believes is in the future, while a badly drifting clock can undermine expiry expectations. Track clock synchronization and log enough timestamp context to distinguish a validity rejection from a missing principal or invalid signature. Do not solve an apparent clock failure by disabling validation or issuing certificates that never expire.
Suppose a worker has three minutes left and the issuer becomes unavailable for seven minutes. It is possible for the current certificate to expire before replacement, and any new connection should be denied. Queuing work, stopping unapproved retries and escalating the outage are appropriate availability responses. If the task has a firm deadline, report that the deadline cannot be met under safe authentication, rather than silently reusing a retired credential.
Longer renewal overlap can improve availability but also increase the time for which issued credentials remain usable. There is no universal correct certificate lifetime; it depends on task risk, issuer availability, clock behaviour, revocation latency and session controls. Make the trade quantitative. Report the percentage of renewals completed before expiry with the number of attempts as denominator, and measure recovery times from real outages. A single successful test does not establish fleet reliability.
Machine identity versus a language-model instruction
An AI agent may decide to call an SSH tool after reading external text. That text can contain false instructions, borrowed credentials or demands to bypass controls. A signed SSH user certificate cannot determine whether the requested task originated in a human-approved workflow or a malicious document. Authorising the worker’s login is not the same as approving the content of a command. Implement a separate task-policy gate that binds allowed commands, destinations and data classes to a trusted job.
A simple defence is to run exports under an operating-system account that cannot open a privileged shell or write outside its approved directory. Use forced commands where suitable, validate every argument and keep forwarding disabled when unnecessary. For a document upload, verify the destination path and file type through deterministic application policy. Prompt wording cannot increase Unix permissions if the remote account has none, but unsafe shell argument handling can still create vulnerabilities inside the approved account.
Record the source of the job instruction, the approval identifier, the certificate serial and the actual remote command class as separate audit fields. This lets reviewers distinguish legitimate scheduled work from abnormal behaviour even if both used valid credentials. Do not log private keys or secrets in the process. A useful security architecture makes each boundary observable: trusted instruction, issued identity, accepted principal, narrow remote execution and confirmed result.
Logging, serials and measurable outcomes
An audit event should identify the destination host, server trust state, issuer CA fingerprint, certificate key ID, serial, principal, requested account, timestamp, outcome and bounded command category. The key identifier makes events readable; the serial distinguishes separate certificates with otherwise similar labels. Neither value is a secret. A log that says SSH login succeeded without linking to the issuance record cannot explain which approved worker and policy were involved.
Suppose three workers all carry a key identifier daily-report but certificates have distinct serials 42017, 42018 and 42019. An access event associated with 42018 can be reconciled with an issuance record and a particular worker. If the issuer reuses every serial indiscriminately, that correlation becomes less reliable. Enforce the chosen uniqueness scope and maintain a tamper-resistant mapping between issuance requests and certificate output. Store only enough personally identifying information to fulfil the audit purpose.
Measure failure rates with denominators. Forty rejected attempts among four thousand login attempts represents 40/4000 = 0.01, or one percent, not forty percent and not necessarily forty separate incidents. Separate invalid principal, expired certificate, unknown CA, revoked key, host identity mismatch and network timeout. Trends can then identify incorrect policy, deployment regressions or abuse. Security dashboards must not combine expected denials with successful unauthorised effects as though both are equivalent failures.
Testing the path that must fail
A pilot should prove that a valid certificate reaches only the intended remote account. Equally important, test an expired certificate, a certificate not yet valid, an untrusted CA, an incorrect principal, a revoked serial, a mismatched private key and an agent connecting to an unexpected host key. Each should produce the expected denial with an informative diagnostic record. Check the installed server version and actual effective configuration; local development acceptance is not evidence of every production server’s behaviour.
Test post-login restrictions separately. A read-only exporter must not obtain a normal shell if it only needs a forced export command. Deny unwanted forwarding, pseudo-terminal access and filesystem traversal, and test malformed filenames or command parameters. Confirm that an agent cannot obtain a broad role merely by asking the issuer for it. Security comes from limiting the effects of a successful login as well as checking the signature.
An isolated exercise can simulate a signer outage, a bounded test clock offset, withdrawal of CA trust, and revocation propagation among several gateways. Record whether retries remain bounded, whether all hosts converge on the same KRL, and whether existing sessions need separate termination. These are suggested validation tasks, not a claim that a particular organisation has performed them. Restore tested access through an approved runbook rather than an emergency wildcard principal.
A migration plan with a reversible boundary
Inventory which agents use SSH, which accounts they reach, where private keys live, and what jobs each account can perform. Distinguish interactive human administrators from unattended workers, and avoid broadening permissions as part of a credential-format migration. Identify unmanaged authorized_keys entries, shared usernames, dormant servers and hosts whose SSH versions differ. The objective is an explainable access graph before introducing a signing authority that can affect many machines.
Build one pilot with a single limited worker and destination. Configure its trust anchor and principal mapping, issue a short-lived certificate, confirm server host identity, test a permitted command and then try denials. Review logs and expiry. Add a second host with different policy to ensure principals really control the boundary. Establish an authorised rollback that does not quietly bypass host verification or grant broader access than the pre-migration state.
Expand in stages, checking renewal latency, KRL consistency, audit coverage and the count of surviving long-lived static credentials. Assign an owner to CA custody, an owner to issuer policy, an owner to each host’s acceptance rules and an owner to emergency revocation. Revisit the mappings after reorganisations or new agent capabilities. A migration is complete only when obsolete keys are retired safely and the new system is monitored as an ongoing service.
Transfer problem: twelve archive workers, three gateways
Consider a school archive service with twelve approved export agents and three destination gateways. If every worker originally requires a static allowed-key entry on each gateway account, the all-to-all model creates twelve times three, or thirty-six, relationships. A common approved CA can reduce repetitive individual key distribution, while gateway-specific principal restrictions determine which worker roles actually belong on each host. Do not interpret thirty-six relationships as thirty-six equally justified permissions; real needs may be a smaller subset.
Suppose credentials last ten minutes, issued at 14:00 and expiring at 14:10. Renewal is targeted at 14:07 with thirty seconds of scheduling jitter. Requests begin from 14:06:30 through 14:07:30, leaving between two and a half and three and a half minutes before the expiry. Now assume the issuer fails at 14:06 and remains unavailable for five minutes. Agents whose credentials expire at 14:10 cannot open fresh SSH sessions safely during the remainder of that outage. They should queue the transfers and raise a credential-service failure.
If worker seven is suspected compromised at 14:04, the response is not merely to shorten future certificates. Revoke relevant issued credentials or the key, block new issuance for that workload identity, propagate validated revocation policy to all three gateways, inspect already-running connections and report what was confirmed. A gateway missing the revocation update may behave differently from the others. That is why destination inventory, distribution acknowledgements and explicit incident checks matter as much as cryptographic signing.
Limits and the transferable lesson
Certificates prove a bounded claim about a key under a chosen signing authority. They do not inspect whether an AI-generated answer is true, whether uploaded data is complete, whether source code is safe or whether a remote instruction was approved. A trusted signer can make a mistaken authorisation decision if its identity inputs are stale. A server can also accept a correctly signed certificate for an excessively powerful account. These are policy and application failures, not cryptographic signature failures.
Short expiry reduces a stolen credential’s opportunity for fresh authentication but does not guarantee rapid detection, revocation or termination of sessions. Issuer availability, clock alignment and KRL distribution can fail independently. An organisation should plan each boundary with a measurable response and a recovery path that does not widen privilege. A badge showing an authorised identity is not a substitute for rules about what that identity may do.
For parents and tutors, this example illustrates a broader principle of digital literacy: verify who is speaking, check what they are allowed to request, impose useful time limits, and retain evidence of what happened. These are separate reasoning questions. Modern AI-agent infrastructure benefits from exactly the same disciplined distinctions. Understanding them is more valuable than imagining a single certificate, password or model capability could solve every form of trust.
Frequently asked questions
Are OpenSSH certificates ordinary website TLS certificates?
No. OpenSSH user and host certificates have their own format, separate from X.509 certificates used for many TLS connections. Their trust configuration, principals and signing workflows are different; selecting the wrong model can lead to invalid implementation assumptions.
Does the issuer need to be online for every login?
Not typically. A server verifies the presented signed credential using previously configured trust material and other local checks. The issuer needs to be available when issuing or renewing certificates; revocation material and policy changes still need reliable distribution.
Does expiry end existing SSH sessions?
Do not assume so. Treat expiry as a validity gate for new authentication and enforce separate command or session timeouts when a task requires a strict maximum execution period.
Can a valid certificate authenticate as root?
It should do so only if the acceptance policy and account configuration explicitly allow that outcome, and such permission needs exceptional justification. A signature alone is not a warrant for administrative access.
Does renewing a certificate also rotate the private key?
Not necessarily. One key pair can receive multiple certificates with different serials and lifetimes. If a private key is compromised, block further issuance and rotate or revoke the affected key, not just its current certificate.
What if the KRL file is unreadable?
The OpenBSD server documentation warns that public-key authentication may be refused for everyone when a configured RevokedKeys file cannot be read. Validate permissions and make changes with atomic file replacement.
Can an agent fall back to an old shared SSH key?
Only through an independently approved, tightly limited recovery path. An automatic unrestricted fallback can bypass the purpose of short-lived issuance and make incident response harder.
What is the simplest reliable mental model?
Four questions: is the destination genuine, does this worker control the signed key, is this principal permitted for the requested remote account, and is the requested operation allowed? Treat a separate failure at any layer as a reason to stop rather than weaken the next check.
Primary references
These upstream references define the format, acceptance checks, revocation behaviour and protocol. The exact original URLs are displayed for version-aware verification; this article has not replaced primary documentation with assertions from a commercial secondary source.
OpenBSD ssh-keygen manual — https://man.openbsd.org/ssh-keygen
OpenBSD sshd_config manual — https://man.openbsd.org/sshd_config
OpenBSD SSH client config manual — https://man.openbsd.org/ssh_config
IETF RFC 4252 SSH Authentication Protocol — https://datatracker.ietf.org/doc/html/rfc4252
OpenSSH project release notes — https://www.openssh.org/releasenotes.html
Related reader pathways
The following independently checked published eduKateSG articles cover neighbouring but distinct mechanisms. SSH host identity establishes whom the agent connects to, while OAuth mTLS and DPoP concern other API credential designs. This guide owns the separate SSH user-certificate authentication mechanism.
Agent SFTP Host Identity — Pinned Keys, Safe Rotation and Verified Transfers
Agent OAuth mTLS — Certificate-Bound Tokens and Gateway Trust
Agent DPoP Tokens — Signed Proofs, Nonces and Replay-Safe APIs