SSH Host Key Verification: Know Which VPS You Are Connecting To

An SSH connection authenticates in two directions. Your user credential proves that you may access an account; the server's host key helps your client recognize the server. A first-connection fingerprint prompt is therefore a trust decision. Accepting whatever appears without verification loses the protection that the prompt is designed to provide, especially when connecting to a new address or recovering from a DNS problem.

Obtain the fingerprint independently

Use an authenticated management channel, such as the authorized server console, to inspect the server's public host-key fingerprint. Compare the algorithm and complete fingerprint with the SSH client's prompt. The public fingerprint is appropriate to compare; the server's private host key should remain on the server and should not be copied into tickets or chat.

OpenSSH's ssh-keygen can display fingerprints for public key files. Select the actual host public key used by your installed server rather than assuming one algorithm or filename applies everywhere. If multiple algorithms are offered, make sure you compare the matching algorithm.

Distinguish observation from verification

A tool that retrieves a key over the same untrusted network path shows what that path presented. It does not independently prove the key belongs to your intended server. This distinction matters for scripts that populate known-host files automatically. The expected identity must come from an approved source, not from an unverified first response treated as authoritative.

For a team, maintain a protected inventory of server identity fingerprints and the event that established them. Record the hostname, assigned address, environment, and verification date. Keep the inventory's update permissions narrower than the group of people who merely need to read it.

Investigate a changed-key warning

A legitimate reinstall can replace host keys, but so can connecting to the wrong machine. When a warning appears, stop and confirm whether a rebuild, address reassignment, or intentional host-key rotation occurred. Verify the replacement fingerprint through the trusted management path. Check that DNS and the destination address still match the intended VPS.

Only after that verification should you update the specific stored identity associated with the host. Do not disable host-key checking globally or erase the entire known-hosts file to make a single warning disappear. Those actions discard useful identity history for unrelated servers.

Include identity in rebuild procedures

Add a host-key verification step to your VPS rebuild checklist, alongside application recovery and access testing. Notify authorized operators through the team's established process when identity changes. For automated jobs, plan how the verified replacement reaches their trust configuration before resuming work. A deployment that can authenticate its user but cannot verify its server should fail visibly rather than silently weakening its connection policy.

Keep host identities distinct from user-key rotations in the change record. Replacing an operator's laptop key should not require everyone to trust a new server identity. If both change during a migration, document and verify each event independently.

The OpenSSH client configuration manual and key utility manual describe the controls. See LayerOne docs for console access and our recovery planning guide for rebuild preparation.