AuthorizedKeysCommand

What AuthorizedKeysCommand Does

AuthorizedKeysCommand changes how an SSH server discovers authorised public keys. Instead of reading only static authorised_keys files, the server invokes an external helper during authentication to fetch the current key set. That makes the access decision more dynamic, but it also moves part of the trust decision into the command, its inputs, and the data source it consults.

Why It Is Used in Controlled Environments

Teams use this option when key state needs to track a system of record, such as a directory, inventory, or access service, rather than being copied manually across hosts. That can reduce stale key sprawl, support faster revocation, and let SSH access reflect changes in ownership or employment state without waiting for file updates everywhere.

It is most useful when the organisation can operate the helper reliably and keep its output tightly scoped. If the helper is slow, inconsistent, or difficult to audit, the benefit of centralised key lookup can be outweighed by fragility or visibility gaps.

How It Changes SSH Authentication

With static authorised_keys files, the server checks local content already present on the host. With AuthorizedKeysCommand, authentication depends on an external lookup path that must succeed at connection time. That means the SSH server is no longer evaluating keys in isolation, it is also depending on the helper, the network path to the data source, and the integrity of the returned key material.

This matters because public-key authentication is only as trustworthy as the process that decides which keys are eligible. If the helper returns outdated, overly broad, or maliciously altered data, the server may authorise access that no longer matches policy.

Operational Boundaries and Control Expectations

Organizations usually pair this option with strict execution controls, logging, and a clearly defined source of truth. The helper should be deterministic, limited in scope, and run with the minimum access needed to retrieve keys. The surrounding SSH configuration should also distinguish key retrieval from broader account logic so that a failure in one dependency does not silently weaken the authentication model.

The main design trade-off is between freshness and simplicity. Static files are easier to reason about locally, while dynamic lookup improves central control but introduces an external dependency that must be monitored, protected, and tested like any other authentication component.

Risk and Threat Considerations

Dynamic key retrieval can expand the blast radius of a compromise because the helper becomes part of the authentication trust chain. If an attacker can tamper with the command, its environment, or the backend it queries, they may be able to inject an authorising key, suppress a revocation, or create access that looks legitimate to the SSH server.

Failure mechanism: The SSH server accepts whatever authorised key set the external command returns at login time, so weakness in the helper, data source, or transport can become an authentication bypass or persistence path.

Impact: A compromised or misconfigured lookup path can lead to unauthorized SSH access, delayed revocation, and harder post-incident review because the authoritative key decision happened outside the local authorised_keys file.

Practitioner Guidance

Why practitioners should care: AuthorizedKeysCommand is an access control decision point, not just a convenience setting. Treat the helper and its source data as security-sensitive components because they directly shape who can log in.

What to watch for: Watch for inconsistent key results, unexpected fallback behaviour, and changes to the helper binary, script, or execution environment. Those are often the first signs that the authentication path no longer matches policy.

Practitioner takeaway: Use this option only when you can monitor the lookup path as carefully as you monitor SSH itself.