SSH Host Key Checker

About SSH Host Key Verification

When you connect to an SSH server for the first time, the server presents its host key — a cryptographic identity that helps you verify you're connecting to the legitimate server and not an imposter. SSH host keys come in several types (RSA, ECDSA, Ed25519), each with different security properties. Our SSH Host Key Checker connects to any SSH server, retrieves its host key, and displays the key type alongside SHA-256 and MD5 fingerprints for easy verification against known values.

How to Use

Enter the SSH server hostname or IP address.
Optionally change the port number (default is 22).
Click Check SSH to connect and retrieve the host key.
Compare the displayed SHA-256 and MD5 fingerprints with the server administrator's known values.

Use Cases

Fingerprint Verification: Verify SSH server fingerprints before first connection to prevent man-in-the-middle attacks.
Security Audits: Audit SSH server configurations to ensure they use secure key types (e.g., Ed25519 over 1024-bit RSA).
Server Inventory: Document SSH host key types and fingerprints across your server fleet for asset management.
Incident Response: Investigate SSH host key changes that may indicate a server compromise or key rotation.

Frequently Asked Questions

Verifying SSH host keys protects against man-in-the-middle attacks. When you connect to a server, checking the fingerprint against a trusted source (such as your server console or documentation) ensures you are communicating with the legitimate server.

Ed25519 is widely considered the most secure and efficient SSH key type due to its strong elliptic curve cryptography and small key size. ECDSA with a P-256 curve is also strong. RSA keys with 3072+ bit lengths remain secure but are less efficient.

A mismatched host key can indicate a man-in-the-middle attack, a server compromise, or a legitimate key rotation. If you did not expect a key change, contact your server administrator immediately and do not connect.

Run the ssh-keyscan command this page provides for your host and port, then hash the key it returns. That is the genuine host key fingerprint, obtained through the key exchange rather than guessed from a banner. Compare it against the key you recorded when the machine was provisioned, and treat any difference as something to explain before connecting.

Because the host key only arrives after the SSH key exchange completes, which requires a working SSH implementation rather than a socket read. This server does not have one available, and hand-rolling key exchange would be far worse than not attempting it. So the page does the part it can do honestly and hands you the command for the rest, rather than returning something that looks like the answer.

Because it was a hash of the identification banner, and the banner is a version string such as the protocol and software version. Every server running the same SSH build sends the same one, so every such server produced the same value — a number that looked exactly like a host key fingerprint and identified nothing. Removing it was the only honest option; there is no correct way to present a banner hash as a key fingerprint.

Inventory and rough version identification, which has real value. The software version tells you whether a host is running an SSH implementation with known issues, and it is one of the first things worth recording about a machine. It does not verify anything about identity — the banner is sent unencrypted and unauthenticated before any security is established, so it is informational rather than trustworthy.

Because it is not listening, which is exactly what you want. SSH is commonly disabled on web-facing hosts, and a closed port is a good result rather than a problem. Where SSH is genuinely required it is usually restricted to specific source addresses or moved to a nonstandard port, both of which mean a scan from elsewhere will show nothing — so verify from inside your network where the access exists.

What This Page Can And Cannot Read

Verifying an SSH host key means knowing what the server's key is and checking it against what you expected. That requires completing the SSH key exchange, which this page does not do — and the distinction matters more here than anywhere else on the site.

1Read the identification banner the server sends before anything else, and report the protocol version and software version from it. That is a real observation about what is running, and it is genuinely useful for inventory and for spotting an outdated SSH implementation.
2Not produce a host key fingerprint. The host key arrives after the key exchange, which needs a full SSH implementation. An earlier version of this page hashed the banner and labelled the result a fingerprint — so every server running the same SSH build returned an identical value. A number that looks like a host key fingerprint and is not one is exactly the kind of thing that gets trusted by mistake.
3Give you the command to get the real thing. The result includes the exact ssh-keyscan invocation for that host and port, so the genuine fingerprint is one command away and nothing here stands in for it.

A host that does not speak SSH on the probed port returns nothing rather than a fabricated result, which is the correct outcome for a web server and a useful confirmation that SSH is not exposed.

Technical Details

Key Types: RSA, DSA, ECDSA (P-256, P-384, P-521), Ed25519
Fingerprints: MD5, SHA-1, SHA-256 hash algorithms
Format: OpenSSH key format analysis
Security: Key size, algorithm strength, and best practices assessment

SSH Host Key