Authorized_Keys File

What the Authorized_Keys File Does

The authorized_keys file is the server-side trust list for SSH public-key login. Each entry represents a public key that the account is allowed to use, so this file functions as both an access-control record and a security boundary. Its job is simple, but its accuracy directly determines whether SSH accepts or rejects a key-based login attempt.

Because SSH compares the presented key against this file during authentication, the file is only effective when it contains the right keys and is protected with the right ownership and permissions. If it is too broad, stale, or writable by the wrong process or user, an attacker may gain or preserve access without ever needing a password.

How SSH Uses the File During Login

When a client offers an SSH public key, the server checks whether that key matches an authorized entry for the target account. If the key is present and the surrounding conditions are valid, authentication succeeds without a password prompt. If it is missing, malformed, or unreadable due to misconfiguration, the login fails even when the key itself is valid.

This makes the file part of the authentication path, not just a static configuration artifact. In practice, it is the server-side proof that a given key is trusted for a specific identity, which is why administrators often treat it as a controlled access list rather than a convenience file.

Why File Ownership and Permissions Matter

The file must be protected so that only the intended account owner or trusted administrative process can modify it. SSH is sensitive to insecure ownership and permission states because the presence of an extra key, an altered entry, or an unsafe directory path can undermine the trust model. On Linux hosts, this is part of the broader permission and account-control picture described in the Linux Fundamentals for Defenders Guide.

It is also common for authorised key changes to be a persistence mechanism after compromise. An attacker who can write to the file, or influence the process that writes it, can add their own key and keep access long after passwords are changed. The related abuse pattern is covered in the MITRE ATT&CK T1098 Account Manipulation Guide.

Operational Management of SSH Keys

The file is only as safe as the key lifecycle around it. Over time, organisations accumulate dormant keys, duplicate entries, and keys that belong to former staff, contractors, or automation paths that no longer exist. Good practice is to treat the file as a live inventory of who can authenticate, then keep that inventory aligned with current ownership and access need.

That is why key governance usually extends beyond the file itself to rotation, revocation, and inventory hygiene. NHIMG’s SSH Key and SSH Certificate Management Guide focuses on sprawl, orphaned keys, certificates, and safe retirement, while the OpenSSH Server Hardening Guide covers server-side controls that reduce the chance of weak SSH access paths.

Detecting Misuse and Recovery After Compromise

When SSH access is abused, the authorized_keys file is one of the first places to inspect because it can reveal unauthorized persistence, tampering, or unexpected key additions. Review it alongside login logs, file modification history, and related persistence locations on the host. A compromised key can remain useful until it is removed, so incident response should assume that access may survive beyond a password reset.

Host-based visibility helps here. The osquery Guide is useful for finding SSH keys on endpoints at scale, and the Linux Forensics Guide helps investigators determine whether the file changed during the compromise window, who changed it, and whether there are signs of follow-on persistence.

Risk and Threat Considerations

An insecure authorized_keys file can turn a normal SSH login control into a durable persistence mechanism. The main risks are unauthorized key insertion, stale keys that outlive their owners, and permission mistakes that let the wrong process alter trust decisions. In cloud and automation-heavy environments, the same pattern can also become a lateral-movement path when a stolen key is reused across hosts or environments.

Failure mechanism: If an attacker or untrusted process can modify the file, or if orphaned entries are left in place, SSH may continue to trust keys that should no longer work. That allows long-lived unauthorized access without password guessing or repeated exploitation.

Impact: The result can be account takeover, stealthy persistence, and broad host access that survives routine credential changes. In environments with shared automation or administrator keys, one bad entry can expose multiple systems at once.

Practitioner Guidance

Why practitioners should care: Treat the file as a privileged access control asset, not a convenience list. Its contents should be owned, reviewed, and retired with the same discipline used for other authentication material, because a single stale key can quietly preserve access after every other control looks healthy.

What to watch for: Unexpected new keys, duplicate entries, home directories with unsafe permissions, and automation that writes to the file without change control are all warning signs. When those conditions appear, verify whether the key still has a valid business owner and whether the host should still trust it.

Practitioner takeaway: The safest SSH posture is not just “use keys”, it is “continuously govern which keys are trusted and why.”

Related resources from NHI Mgmt Group

• Authorized Keys
• Authorized_keys
• What should security teams do first when a file transfer application exposes hardcoded machine keys used to sign ViewState?
• What is the difference between controlling SSH access with PAM and controlling it with authorized keys on the destination host?