A known_hosts file should be stored with strict file permissions so only the intended user or automation account can read it. Protect it from unauthorised modification, because attackers who can alter host key entries can redirect SSH connections to malicious servers. Validate host key changes, back up trusted entries, and review ownership and integrity regularly.
What a secure known_hosts file protects
A known_hosts file is a trust anchor for SSH client connections. It records the host keys a client expects to see, so the client can warn when a server presents a different key. That makes the file part of connection integrity, not just a convenience file, and it deserves the same care you would give any other trusted security state.
The practical goal is to keep the file readable only to the account that needs it, and to keep its contents stable unless a deliberate, verified host key change is being introduced. If an attacker can tamper with the entries, they can suppress mismatch warnings or steer connections toward a rogue server that presents a trusted-looking key.
Because the file is a local record of trust, protection is mostly about file ownership, permissions, and change control. The safest pattern is to treat it as user-specific state unless a controlled automation account owns it, rather than making it broadly readable or writable on a shared system.
How to store it safely on hosts and in automation
Store the file under the home directory or automation workspace of the account that actually uses it, with permissions that prevent other users from reading or modifying it. On multi-user systems, the important distinction is not simply “exists on disk”, but “who can alter the trust record and who can observe it.”
For automation, the same principle applies to non-interactive accounts that initiate SSH sessions. If a deployment job, backup job, or service account relies on SSH trust decisions, that account should own the file and have the minimum filesystem access needed to use it. SSH Key and SSH Certificate Management Guide is a useful companion for understanding how SSH trust material should be governed across keys, certificates, and related access paths.
Backups should preserve trusted entries, but they should also be protected as sensitive configuration state. A backup that is easy to alter can become a second path to trust manipulation, so the backup location, restore process, and integrity checks need to be controlled together.
How host key changes should be handled
Host key changes should be treated as a verification event, not as an automatic update. A changed key can be legitimate, but it can also indicate server rebuilds, key rotation, load balancer changes, or a man-in-the-middle attempt. The right response is to confirm the reason for the change before accepting the new key.
When a known host key must change, the safest process is to verify the new fingerprint through a separate trusted channel, then update the entry intentionally. That discipline matters because once the client trusts the wrong key, later SSH sessions can be silently redirected. The GitHub RSA SSH host key exposure 2023 incident is a good reminder that even host keys themselves are security-sensitive material and need rotation handling when exposure occurs.
Regular review is also important. Compare stored host keys against current infrastructure inventory, remove stale entries when hosts are retired, and confirm that ownership and timestamps match expected administrative activity. A file that has not changed for months is not automatically safe, but unexplained changes are a stronger warning sign than most teams realise.
Risk and Threat Considerations
A compromised known_hosts file undermines SSH trust at the first connection check, which can make a malicious server look legitimate or make a legitimate mismatch harder to notice. The risk is highest where administrators or automation rely on SSH for privileged remote access, configuration updates, or deployment workflows.
Failure mechanism: An attacker who can write to the file can replace trusted host key entries, suppress warnings, or align a rogue host key with an expected entry, creating an opportunity for credential capture, session interception, or trusted-command execution against the wrong host.
Impact: The result can be redirected SSH sessions, exposed credentials or commands, and a weakened ability to detect server impersonation. In automation, the blast radius can include repeatable access across many jobs or environments if the same trust file is reused broadly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits which account can read or alter trusted SSH host records. |
| CM-5 — Access Restrictions for Change | Covers preventing unauthorised modification of trusted configuration state. | |
| IA-5 — Authenticator Management | Applies because SSH host trust entries function as authentication material for connections. | |
| Recommendation — Restrict known_hosts access to the owning user or automation account. Require authorised change control before host key entries are updated. Manage SSH trust material so host key changes are verified before acceptance. | ||
Practitioner Guidance
What to verify: Confirm the file owner is the intended human or automation account, the permissions block other users from reading or writing it, and the entries reflect current infrastructure. If the file lives in a shared location, treat that as a design problem rather than a minor hardening gap.
Decision rule: If a host key change is expected, verify the new fingerprint out of band before updating the file. If the change is not expected, treat it as a possible compromise path and investigate the server identity before trusting the connection again.
Practitioner takeaway: Protecting known_hosts is about preserving trust integrity, not just file confidentiality, so the file should be tightly owned, change-controlled, and checked whenever host identity changes.