SSH Host Key Verification

Last updated: April 2026

Host key verification is a fundamental SSH security mechanism that protects you from connecting to an impersonator instead of your intended server. Every SSH server has a unique cryptographic identity — its host key. When you connect, RockTerm checks this key against its stored records to ensure you are reaching the genuine server.

How Host Key Verification Works

During the SSH handshake, the server presents its public host key to the client. The client then:

1. Looks up the server's hostname (or IP) in its local known_hosts file.
2. If a matching entry exists, compares the presented key to the stored key.
3. If the keys match, the connection proceeds. If they do not match, the client raises a warning and refuses the connection.
4. If no entry exists (first connection), the client asks the user whether to trust the new key.

The known_hosts file is located at:

• Windows: C:\Users\<username>\.ssh\known_hosts
• Linux/macOS: ~/.ssh/known_hosts

First Connection: Trust on First Use (TOFU)

When you connect to a server for the first time, RockTerm displays a dialog showing the server's host key fingerprint and key type (e.g., ED25519, RSA). You will see something like:

The authenticity of host '192.168.1.50 (192.168.1.50)' can't be established.
ED25519 key fingerprint is SHA256:xR3jK...example...9vZp.
Are you sure you want to continue connecting?

This is normal for a first connection. Ideally, you should verify the fingerprint through an out-of-band channel (e.g., compare it to a value provided by your system administrator, read from a console session, or published in an internal wiki). Once you accept, RockTerm stores the key in known_hosts and will verify it automatically on every future connection.

Viewing a Server's Host Key Fingerprint

If you have console or out-of-band access to the server, you can display its host key fingerprints:

# Show all host key fingerprints
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

Compare the output to what RockTerm displays during the first connection.

"Host Key Has Changed" Warning

If you see a warning like the following, it means the server's host key no longer matches the key stored in your known_hosts file:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

RockTerm will refuse to connect when this occurs. This is intentional and is the correct behavior.

Legitimate Causes

In most operational environments, a host key change has a benign explanation:

• Server was rebuilt or reimaged. A fresh OS installation generates new host keys.
• SSH was reinstalled. Removing and reinstalling the OpenSSH server package regenerates host keys unless the old key files were preserved.
• A different server is now at the same IP address. Common in environments that reuse IPs from DHCP pools, or after migrating a service to new hardware.
• The server was restored from a backup that contained different host keys than the ones you previously connected to.
• A load balancer or floating IP now points to a different backend node with its own host keys.

Security Warning: Man-in-the-Middle Attacks

A host key change can also indicate that an attacker has positioned themselves between you and the real server (a man-in-the-middle attack). The attacker intercepts your connection and presents their own key, hoping you will accept it. Once accepted, they can observe and modify all traffic in the session, including passwords, commands, and data.

Do not blindly accept a changed host key. Before clearing the old key, confirm with your team or server administrator that the server was legitimately rebuilt, reinstalled, or replaced.

Removing an Old Host Key

Once you have confirmed the host key change is legitimate, you need to remove the stale entry from known_hosts before reconnecting.

Using ssh-keygen

ssh-keygen -R hostname

This removes all keys associated with the specified hostname or IP. For example:

ssh-keygen -R 192.168.1.50
ssh-keygen -R server.example.com

If you connected by both hostname and IP, you may need to remove both entries:

ssh-keygen -R 192.168.1.50
ssh-keygen -R server.example.com

Using RockTerm

When RockTerm detects a host key mismatch, it displays a dialog with the old and new key fingerprints. If you are certain the change is legitimate, click Remove Old Key and Reconnect. RockTerm will remove the stale entry and prompt you to accept the new key as if it were a first connection.

Manual Editing

You can also open the known_hosts file in a text editor and delete the line containing the hostname or IP. Each line follows this format:

hostname,ip-address ssh-ed25519 AAAA...key-data...

If the file uses hashed hostnames (default on many systems), the hostname field will be a hashed value starting with |1|. In that case, use ssh-keygen -R rather than editing manually.

Host Key Types and Algorithms

Modern SSH servers typically generate multiple host keys:

• ED25519 — preferred; small, fast, strong
• ECDSA — supported on most modern systems
• RSA — broadest compatibility, especially with older clients and network devices

RockTerm negotiates the strongest mutually supported algorithm. You can view the key type and fingerprint in the connection details panel after connecting.

Best Practices

• Verify fingerprints on first connection through an out-of-band channel whenever possible.
• Preserve host keys during server rebuilds. Back up /etc/ssh/ssh_host_* before reimaging and restore them afterward to avoid triggering warnings for every user.
• Use configuration management (Ansible, Puppet, etc.) to deploy consistent host keys across server rebuilds.
• Investigate every host key warning. Treat it as a potential security incident until you confirm the cause.
• Distribute host keys via DNS (SSHFP records) for environments where out-of-band verification is impractical. Configure VerifyHostKeyDNS yes in your SSH client config.

← Back to Support Articles

Still need help?

If you're still experiencing issues, contact us or email info@rockriverresearch.com.