SSH known_hosts Lines Generator

known_hosts and the trust-on-first-use problem

Every time SSH connects to a server it asks: "is this the same machine I talked to last time?" The answer lives in ~/.ssh/known_hosts, a file of one record per line that pins the server's host public key. If the key the server presents matches the line, the connection proceeds silently; if not, OpenSSH refuses with the loud "REMOTE HOST IDENTIFICATION HAS CHANGED!" banner. That single check is what stops a man-in-the-middle from sitting between your laptop and a trusted server while still serving valid TCP — without the pinning, the attacker just presents their own key and harvests your session.

File format

Each non-hashed line has three or four fields separated by spaces:

github.com,140.82.114.3 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkV...
[gitlab.example.com]:2222 ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...

The host can be a hostname, an IP, or both joined by a comma. Non-standard ports use the [host]:port bracket form. The key type (ssh-ed25519, ssh-rsa, ecdsa-sha2-nistp256, etc.) precedes the base64 public key blob. A single server may have several lines, one per key type — OpenSSH picks the strongest match.

Hashed hostnames for privacy

Modern OpenSSH defaults to HashKnownHosts yes: the hostname is replaced with a |1|salt|HMAC-SHA1 blob so an attacker who steals the file cannot enumerate the servers you have visited. Convert an existing file with ssh-keygen -H. Lookups still work because SSH hashes the host it is connecting to with the same salt and compares. Removing a stale entry uses ssh-keygen -R hostname, which handles both plain and hashed formats.

First-connection risk and how to skip it

TOFU is only as safe as the first contact. If the very first time you connect there is already a MITM, you happily pin the attacker's key forever. Mitigations, in increasing strength:

• Verify out-of-band — compare the fingerprint shown by SSH with one published by the provider. GitHub lists theirs at docs.github.com/.../githubs-ssh-key-fingerprints.
• SSHFP DNS — set VerifyHostKeyDNS yes and the server publishes its fingerprint via DNSSEC-signed SSHFP records.
• Pre-distribute the file via config management (Ansible, Puppet, Chef) or a system-wide /etc/ssh/ssh_known_hosts.
• SSH certificates — a CA signs both host and user keys; clients trust the CA, not individual fingerprints. HashiCorp Vault SSH, Teleport, Smallstep and BastionZero all do this.

Fingerprints: SHA-256 vs MD5

When SSH prompts you to accept a new host it prints something like SHA256:dGhpc2lzbm90YXJlYWxoYXNo. The modern format is base64-encoded SHA-256; the older colon-separated MD5 (16:27:ac:a5:...) is gone since OpenSSH 6.8 (2015). Compute it yourself with ssh-keygen -lf /path/to/key.pub. Search for a known host without revealing all entries: ssh-keygen -F github.com.

FAQ

Can I edit known_hosts by hand? Yes — it is plain text. Append a line in the correct format and SSH will pick it up. Remove with ssh-keygen -R hostname if hashed.

Why is the hostname an unreadable hash? Privacy. Hashing prevents an attacker who reads the file (malware, backup leak) from listing every server you log into.

I see a strange fingerprint on first connection — accept? Verify out-of-band first. Compare against the provider's published value or an SSHFP DNS record. A mismatch on a server you already pinned is a hard stop — investigate before forcing past it.

What if the host key legitimately changes? Server rebuild or rotation. Run ssh-keygen -R host, reconnect, verify the new fingerprint against an authoritative source, then let SSH pin it again.

Is there a fleet-wide alternative? SSH certificates. A CA signs server keys, clients only trust the CA — no per-host known_hosts to maintain.