AuthorizedKeysFile

How AuthorizedKeysFile Works

AuthorizedKeysFile is part of OpenSSH server-side authentication policy. It tells sshd where to look for a user’s approved public keys, which makes the file path itself a security boundary: if the server reads the wrong location, a user may lose access, gain unintended access, or inherit keys that were never meant for that account.

The directive can point to one file or multiple files, and OpenSSH evaluates them as part of public key authentication. In practice, that means administrators are not just choosing a path, they are choosing the source of truth for which keys are trusted for a given account.

Why It Matters for SSH Trust

Because this setting governs which keys are accepted, it directly affects both access control and account assurance. A weak or overbroad configuration can cause key acceptance to diverge from the account owner’s intent, especially when home directories are shared, permissions are loose, or account provisioning is inconsistent.

The security value of AuthorizedKeysFile comes from precision. A restrictive and predictable key location reduces ambiguity during audits, limits the chance of a stale or unintended key being honoured, and makes the authentication path easier to reason about when debugging access problems or investigating suspicious logins.

Common Configuration Patterns

Many deployments use a per-user location under the home directory, but OpenSSH also supports alternate paths and patterns for different administrative models. Centralised or template-driven layouts can be useful when environments need uniform key handling, but they also increase the importance of file ownership, read permissions, and change control.

Multi-file configurations are sometimes used to separate administrator-managed keys from user-managed keys, or to layer inherited keys with local exceptions. That flexibility is useful, but it also means administrators should understand which file wins, how missing files are handled, and whether the intended path is actually reachable by the daemon at runtime.

Operational Consequences and Misconfiguration Risk

Misconfiguring AuthorizedKeysFile is often an availability problem first and a security problem second. If the path is wrong, unreadable, or inconsistent with account policy, legitimate users may be locked out. If the path is too permissive or points at a location that untrusted parties can alter, an attacker may be able to introduce a key that SSH will trust.

To verify exposure, organisations should confirm the effective server configuration, inspect file ownership and permissions, and compare the configured path with the actual locations where keys are stored. Access reviews should also consider whether old keys remain present in any referenced file after an employee, contractor, or automation account changes role or leaves the environment.

Risk and Threat Considerations

AuthorizedKeysFile becomes dangerous when the server trusts a key file that can be modified, replaced, or populated outside the intended administrative process. That can lead to silent persistence, account takeover, or hard-to-notice privilege abuse through a valid SSH login rather than an obvious exploit chain.

Failure mechanism: An attacker or careless admin changes the referenced file path, or gains write access to one of the referenced key files, and sshd then accepts an unexpected public key as legitimate.

Impact: The affected account can be accessed without password compromise, and any key added to an administrative or service account may provide durable, low-noise access until the file is corrected and the key is removed.

Practitioner Guidance

Why practitioners should care: Treat this setting as part of SSH authentication governance, not as a simple file-path preference. The configured location should be explicit, stable, and consistent with the organisation’s key lifecycle and account ownership model.

What to watch for: Review whether the referenced files are writable only by the right owner, whether multiple paths are intentionally required, and whether any key source can be updated outside the expected control process. If the configuration is used for privileged or shared accounts, the review should be even stricter.

Practitioner takeaway: The safest configuration is the one that makes key acceptance obvious, auditable, and hard to alter without leaving evidence.