← SSH: secure access and production diagnosis
07 / 8 · 45 MIN

Manage identities in known_hosts

Look up hashed entries and scope trust changes by name, port, and alias.

Identify the entry before changing trust

An authorized rebuild of batch.example.test can change its server key. In this lesson’s case, the port is 2222 and the new fingerprint was confirmed through a known management channel. The task is to update the correct reference while retaining the others. Record the name, port, and any HostKeyAlias used by the client. Lookup is not necessarily the name appearing in the ticket. Alternating warnings between environments can result from both using one trust alias, mixing identities that should have distinct references.

Look up hashed names

The lab creates a disposable host key and an isolated known_hosts file containing [batch.example.test]:2222 and other.example.test. After ssh-keygen -H -f on that file, names no longer appear as plaintext. A -F lookup using the bracketed form finds the first entry; the plain-name query does not match the alternate port. Hashing neither encrypts server private material nor validates key legitimacy. It transforms the name representation for this storage. Absence from a text search does not establish absence of a usable entry.

Remove only the intended reference

The experiment uses -R with [batch.example.test]:2222 on the temporary file. A new lookup confirms that entry disappeared while other.example.test remained. The observation establishes removal scope, not authentication of a replacement server. In a real intervention, trust in the new key comes from independent confirmation and the change process. Do not delete the entire file to bypass a warning. The accept-new option also does not mean silently accepting a changed known key. Distinguish a previously unseen identity from divergence against already recorded trust.

Review authority scope

When host certificates are used, a @cert-authority entry associates a CA with name patterns. That delegation needs review: trusting a CA for *.example.test is broader than trusting it only for batch.example.test. A correct signature does not decide whether granted scope matches team responsibility. The certificate’s presented name and client policy also need checking. This lesson discusses that decision from documentation; the runner does not open sessions with host certificates. Keep that distinction when presenting evidence to security or operations.

Retain and clean diagnostic artifacts

Hashing the current file does not automatically remove names from other copies. The -H operation retains previous content in a.old copy. In the runner, the entire temporary directory, including that copy and disposable keys, is removed afterward. In a real investigation, apply appropriate retention and access to useful artifacts. Share only necessary evidence, such as logical name, port, and confirmed fingerprint. Summary: locate the entry, verify new identity against a trusted reference, and change the necessary scope. Connect this lesson with bastions, inventory, changes, and certificate trust.

IN PRACTICE

The hashed port-2222 entry was found and removed; the other host entry remained.

Common pitfalls

No grep result as missing entry; -R as validation; hashing as cleanup of every copy.

Related topics: SSH connection and server identity · Key authentication and remote accounts · Effective configuration and reproducing failures

Take this idea with you

Managing the file and establishing trust are related decisions requiring different evidence.

Create account

Reference: ssh-keygen(1) · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary