The first SSH connection to a server asks for trust before any login command, password, or private key authentication can safely finish. Verifying the server's host key fingerprint first keeps that trust decision tied to the intended machine instead of a spoofed endpoint on the network.
OpenSSH host keys are long-term server identity keys, separate from the user keys that allow login. A server-side reference fingerprint from the console, inventory, configuration management, or the server owner can be compared with the public key presented to the client before the key is added to ~/.ssh/known_hosts.
ssh-keyscan can collect a public host key without logging in, but it does not prove the key is trustworthy by itself. Treat the scan as an untrusted observation until its SHA256 fingerprint matches the independent reference exactly, including the key type and host name or port pattern being checked.
Steps to verify SSH host key fingerprints before connecting:
- Get the trusted host fingerprint from the server console or administrator record.
$ sudo ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:Ms3RRxFWAIRm9x0+dmqbqQm/Ntu1y4e+SU/S8nSbSTM root@server01 (ED25519)
The example uses the ED25519 host key. Use the same host key type that the server owner publishes, such as /etc/ssh/ssh_host_rsa_key.pub or /etc/ssh/ssh_host_ecdsa_key.pub.
- Scan the server's ED25519 public host key from the client.
$ ssh-keyscan -q -t ed25519 host.example.net > host.example.net.pub
ssh-keyscan only reads the key presented on the network. Do not add the file to known_hosts until the fingerprint matches a trusted reference.
- Print the fingerprint of the scanned host key.
$ ssh-keygen -l -E sha256 -f host.example.net.pub 256 SHA256:Ms3RRxFWAIRm9x0+dmqbqQm/Ntu1y4e+SU/S8nSbSTM host.example.net (ED25519)
For a non-default port, scan with ssh-keyscan -q -p 2222 -t ed25519 host.example.net and later search for [host.example.net]:2222 in known_hosts.
- Compare the two SHA256 fingerprint strings.
Stop if the fingerprints differ, the key type changes unexpectedly, or the host name and address do not match the intended server.
- Prepare the client SSH directory.
$ install -m 700 -d ~/.ssh
- Add the verified host key to the client trust file.
$ cat host.example.net.pub >> ~/.ssh/known_hosts
If the client already has an old entry for the same host, resolve the changed-key warning before appending a replacement.
Related: How to fix the SSH remote host identification has changed warning - Confirm that OpenSSH can find the trusted host entry.
$ ssh-keygen -F host.example.net # Host host.example.net found: line 1 host.example.net ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGIym3LPoGkilByEQ5QysntAAfdWN+rJhwRh0CP/2I1d
- Connect with strict host key checking enabled.
$ ssh -o StrictHostKeyChecking=yes admin@host.example.net hostname server01
StrictHostKeyChecking=yes makes ssh fail instead of prompting if the host key is missing or different from the trusted entry.
- Remove the temporary scanned key file.
$ rm host.example.net.pub
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.