b2KIT

Known Hosts Parser

Parse and decode SSH known_hosts file entries to display host, key type, and fingerprint information.

Tested tool guide Tested browser tools Checked August 16, 2026

What Known Hosts Parser does and how it behaves

Known Hosts Parser turns OpenSSH known_hosts records into readable host selectors, key-type labels, and public-key fingerprints. It helps distinguish the host expression that was saved from the key material associated with it. The important surprise is that a host field beginning with |1| is a salted hash, not encoded text that can be decoded back to a hostname. It can be matched against a candidate name, but its original name is not recoverable from the entry alone. Because known_hosts files can expose internal names and addresses, pasted data stays in the browser and is not uploaded.

How the result is produced

1

Record fields

The known_hosts format places an optional marker before a host field, a key-type field, Base64 public-key data, and an optional trailing comment. The parser reads the host selector and key-type label, then decodes the key field for fingerprinting. Literal names, addresses, wildcard patterns, negated patterns, bracketed host-and-port forms, and |1|-prefixed hashes have different meanings despite occupying the same host field.

2

Fingerprint meaning

The fingerprint is derived from the decoded SSH public-key blob, not from the visible hostname or comment. Identical key blobs therefore produce identical fingerprints when listed under different host selectors. The result supports exact comparison with another fingerprint using the same fingerprint convention, but it does not establish who controls the key or whether the saved host association remains current.

Good uses

  • Inspect the exact record named in an SSH host-key warning, then compare its saved fingerprint with replacement-key information supplied by the server administrator.
  • Inventory the key types and fingerprints recorded for a server before a planned host-key rotation, especially when names, addresses, and aliases have separate entries.
  • Compare entries for a hostname, an address, and a non-default-port alias to determine whether all three selectors currently store the same public key.

Limits and checks

  • A |1|-prefixed host token cannot be decoded to reveal its original name. A suspected hostname can be tested against it, but the token itself does not disclose that name.
  • A matching fingerprint demonstrates key equality under that fingerprint format. It does not authenticate the server unless the comparison value came through a separate trusted channel.
  • The host field can contain a wildcard, negation, comma-separated selector list, address, or [host]:port form. Do not automatically interpret every displayed value as one literal DNS hostname.

Common questions

Can the parser recover a hostname from a hashed known_hosts entry?

No. OpenSSH hashed host fields store a salted one-way value in the |1|... form to reduce hostname disclosure if the file is exposed. The parser can display that token and its associated key information, but it cannot reconstruct the hostname. If you already suspect a particular host, OpenSSH tooling can test that candidate against the file.

Does a matching fingerprint prove that a changed SSH key is safe?

Not by itself. The parser identifies the recorded public key with a compact fingerprint for comparison. Accept a changed key only after checking the new fingerprint through a trusted channel, such as the server administrator or a documented provisioning source. A difference may indicate a legitimate rotation, a rebuilt machine, an incorrect destination, or an attack.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools