AuthorizedKeysCommand

AuthorizedKeysCommand is an OpenSSH configuration option that lets the server call an external command to retrieve authorised public keys during authentication. In controlled environments, it supports dynamic key validation instead of relying only on static key files, which helps align SSH access with current identity and metadata state.

Expanded Definition

AuthorizedKeysCommand is an OpenSSH server-side setting that delegates public key lookup to an external program at login time. It is used when authorised keys should come from a current source of truth such as an inventory service, directory, or policy engine rather than a static file on disk.

The practical boundary is important: the command does not replace SSH public-key authentication itself, and it does not grant access on its own. It only supplies key material that sshd can evaluate during authentication. That means the security of the feature depends on the correctness, integrity, and availability of the command it invokes, plus the trust placed in whatever system feeds it data.

Definitions in the industry are stable at the OpenSSH level, but implementation patterns vary across vendors and operators. Some teams use it for fleet-wide key centralisation, while others use it to enforce context-aware access decisions tied to identity state, device state, or metadata. The distinction matters because the operational burden shifts from file maintenance to command hardening and output assurance. NHI Management Group’s Ultimate Guide to NHIs is a useful companion reference when the command is part of broader machine-identity governance.

Examples and Use Cases

AuthorizedKeysCommand appears most often where SSH access must stay synchronized with a changing identity source. It is especially useful when static key files would drift out of date or create excessive manual overhead.

• A bastion host queries a central service for the user’s current allowed SSH keys at login, reducing stale local key files.
• A fleet admin uses a directory-backed command so contractors lose access automatically when their source record changes.
• A platform team maps the command to metadata-driven approval logic, so only keys linked to the right environment or role are returned.
• An operations team uses the feature to keep key authorisation aligned with current state while accepting the tradeoff that authentication now depends on an external lookup path.
• A regulated environment uses it to make key approval auditable through a single service instead of scattered host files.

The main implementation tradeoff is centralisation versus dependency: the more dynamic the lookup becomes, the more carefully the command, its runtime, and its failure modes must be controlled. If the lookup path fails closed, legitimate access can be interrupted; if it fails open, the security model weakens.

Security Implications

Because AuthorizedKeysCommand runs during authentication, it becomes part of the trust boundary for SSH access. Misconfiguration can expose the server to key injection, overly broad key return sets, brittle access availability, or command execution risk if the invoked program is not tightly constrained.

The largest failure mode is treating the command as a convenience wrapper instead of a security-critical control point. If it returns stale keys, keys for the wrong subject, or keys from an unauthenticated data source, the server may authorise access that no longer matches current identity state. If the command is slow or unavailable, authentication can fail at scale and create an operational outage, especially on heavily used admin hosts or automated access paths.

For NHI-heavy environments, the risk is amplified because machine and service access often depends on repeatable key validation. NHIMG reports that 91.6% of secrets remain valid five days after notification, which underscores how slow revocation can persist when access controls are not tightly coupled to live state.

A practitioner should watch for drift between the command’s output and the real access policy, because that mismatch is often the first symptom of privilege creep or forgotten key paths.

Domain and Governance Relevance

AuthorizedKeysCommand matters most in access governance for SSH estates, especially where key management is too dynamic for static files and too sensitive to leave untracked. It shifts responsibility from local host administration toward a controlled identity lookup service, which changes who owns access correctness and who must monitor failure.

In NHI governance, that shift is especially significant. Machine access often outlives the business event that created it, so dynamic key retrieval can reduce stale standing access only if the source of truth is current, authoritative, and auditable. Otherwise, the command can centralise inconsistency instead of removing it.

For practitioners, the real governance question is not whether the command works, but whether the external authority behind it has clear ownership, revocation discipline, and logging that can support access review. When those controls are weak, the feature can make SSH access look centralised while still hiding unmanaged privilege paths.

Practitioner Guidance

Why practitioners should care: Treat AuthorizedKeysCommand as part of the authentication control plane, not as a convenience feature. Its value comes from keeping SSH authorisation in sync with live identity state, but that only holds when the command source is authoritative and tightly governed.

Common misunderstanding: Teams sometimes assume dynamic key lookup automatically improves security. In practice, it only replaces one trust store with another, so the command’s integrity, latency, and failure behaviour matter as much as the keys themselves.

Governance implication: Assign explicit ownership for the lookup service, the command path, and the data it returns. If those responsibilities are vague, access review and revocation will drift even when the SSH configuration looks clean.