Two files, one name lookup: reconciling six laptops' worth of SSH trust
- date
- 20260830 to 20260831
- what happened
- Consolidating the file of trusted host keys across six administrative laptops, which had diverged independently to between 95 and 159 entries each, surfaced three real problems: two machines shared an identical host key because one had been cloned from the other's disk image and never regenerated its own identity; entries that looked like obsolete duplicates were deliberate aliases a shared configuration depended on; and the standard tool for removing one bad entry removes a whole matching line, silently dropping a second name if the line listed more than one.
- what it cost
- One alias broken on two machines temporarily during the cleanup, from removing entries that looked invalid but were deliberate. The deeper risk found but never triggered: a retired machine's key left in place, later reused by a different machine at the same address, raises a warning about a possible attacker against a perfectly legitimate new host.
- what changed
- The trust file was split in two: a personal file that absorbs day-to-day trust on first use, and a shared, curated file distributed through configuration management, holding only reconciled and verified entries. A convention was adopted for any host expected to change network location or name over its life: a placeholder name, tied to the current address only through configuration.
- the check now
- Before deleting an entry that looks like a stale duplicate, check whether it is a deliberate alias in the shared configuration. When merging several machines' trust files, resolve a conflicting key by asking the live host for its own fingerprint, never by majority vote among the copies, and validate the merged file with a real connection before distributing it.
Trust on first use, SSH’s default model for remembering which cryptographic key belongs to which host, works fine for one machine talking to a stable set of hosts. It works badly for a small fleet of administrative laptops that have each independently accumulated a partial, diverging record of the same infrastructure: between 95 and 159 entries each, no two alike, and no way to tell a deliberate entry from an accident.
Reconciling six such records over 20260830 and 20260831 did what a reconciliation exercise should. It surfaced real problems that had been sitting inside the divergence. Two machines shared an identity they should never have shared, because one had been cloned from the other’s disk image and never given its own.
It also demonstrated how easy it is to make things worse while cleaning up. Entries that looked like leftovers from an old naming scheme were, on closer inspection, deliberate: one stable trust anchor for a host reachable under several real names. And the obvious tool for removing a single bad entry deletes the entire line it matches, so an entry naming two hosts loses both.
The lasting fix is architectural rather than procedural. Separate a personal, freely growing trust file from a curated, shared, reviewed one, and give any host expected to move a stable alias that never has to change even when the host’s real name does. Then a future move costs one line of configuration rather than a fresh trust prompt on every laptop, and the curated file stays something a person can actually read and reason about.
Source: node0 lessons v0.1, lesson 4.20. Sanitized: checklist v0.1, 20260921; host names, fingerprints; voice pass 20260921. Part of oznog.com/node0.