Known Hosts File

How the known hosts file works

The known hosts file is an SSH trust record, not a general-purpose inventory. It stores previously seen host keys so the client can recognise the same server on later connections and alert the user when a presented key changes unexpectedly.

That design makes the file part of SSH’s anti-spoofing path. It helps the client detect when a connection may be going to a different machine, a reinstalled host, or an attacker who can intercept traffic and present a substitute key.

Why host key pinning matters

Unlike password prompts or MFA, this check protects the transport relationship itself. The first successful connection creates or updates trust-on-first-use expectations, and later sessions depend on the stored key matching the server’s current presentation.

When the host key is stable, the client gains a simple integrity check: the same hostname should present the same key unless there has been a legitimate operational change. That makes unexpected key drift a meaningful signal rather than a cosmetic warning.

The mechanism is especially valuable in environments where SSH is used for administration, automation, bastions, or deployments. If an attacker can replace the server’s key in the client’s view, they may be able to impersonate the host and observe or alter subsequent SSH traffic.

What changes trigger a warning

A changed host key can reflect benign events such as rebuilds, host replacement, platform migration, or key rotation. It can also reflect a serious trust failure, so the warning should be treated as a verification event rather than something to dismiss automatically.

Operationally, the important question is whether the change was expected and authorised. If it was not, the safe assumption is that the client has lost assurance about the server identity it is reaching.

That is why the file is often paired with host key verification discipline, controlled rollover procedures, and documented change handling. The value comes from distinguishing routine infrastructure churn from an unexpected identity change on the wire.

How organisations should manage it

The known hosts file is strongest when host keys are managed deliberately instead of left to accumulate ad hoc. SSH Key and SSH Certificate Management Guide is useful for understanding how host key sprawl, orphaned keys, bastions, and rotation interact with SSH trust.

For environments using OpenSSH certificates, the trust model shifts from remembering every individual host key to validating certificates and the issuing authority. SSH Protocol and Certificate Authority Guide helps explain how host certificates, principals, revocation, and phased rollout reduce the operational burden of raw key pinning.

When a real-world host key exposure occurs, the lesson is usually the same: the client-side trust record must be updated in step with host key rotation, not left to silently drift. GitHub RSA SSH host key exposure 2023 illustrates why host key changes have security consequences even when no abuse is immediately observed.

How to respond when the key changes

A changed key should be investigated against an asset record, deployment timeline, and approved maintenance activity before any trust update is made. If the change was not planned, the connection should be treated as potentially unsafe until the server identity is confirmed through an independent channel.

If the change is legitimate, the old record should be replaced in a controlled way so the client does not keep raising false alarms. If the change is not legitimate, the event should be treated as a possible man-in-the-middle indicator and the surrounding SSH trust chain reviewed.

In practice, the known hosts file is a small control with an outsized role: it helps turn SSH from a blind encrypted session into one that can detect unexpected server identity changes.

Risk and Threat Considerations

The main risk is that a stale or poisoned trust record can either block legitimate operations or, worse, create a false sense of continuity when a server has actually changed. Because SSH relies on the stored host key to confirm server identity, a malicious replacement key can support impersonation and interception attempts.

Failure mechanism: An attacker or unintended infrastructure change causes the client to see a different host key than the one previously recorded, which breaks the assumed relationship between hostname and server identity.

Impact: The client may refuse the connection, prompt for manual override, or continue only after a trust decision that should be independently verified; in the worst case, a user who ignores the warning could connect to an impersonating host.

Practitioner Guidance

Why practitioners should care: Treat known hosts entries as security state, not housekeeping. Each entry is part of the SSH trust boundary, so changes should be handled with the same discipline as any other identity or endpoint trust update.

What to watch for: Repeated host key changes, first-connection prompts in places that should already be trusted, and ad hoc edits to the file are all signals that the SSH trust model may be deteriorating.

Practitioner takeaway: Keep host key updates tied to approved change events, and verify unexpected key changes through an independent path before trusting the new fingerprint.

Related resources from NHI Mgmt Group

• How should a known_hosts file be stored and protected?
• SSH Known Hosts File
• What breaks when DLP only looks for known file patterns?
• What breaks when data protection tools only look for file patterns and known sensitive identifiers?