Use SSHFP Records to Verify SSH Host Keys

Updated on March 9, 2021
Use SSHFP Records to Verify SSH Host Keys header image

SSHFP records allow you to store a fingerprint of your server's host keys in DNS. Instead of manually verifying host keys, the SSH client can then look up the host key fingerprints in DNS and match them to those presented by the server.

If you've used OpenSSH before, you are probably used to seeing this:

The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:MH85JK0yq+JNl1lPKUlxit+dGFqWMS/MmohcINp/e9Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This message shows the server's SSH host key fingerprint, verifying the server you connect to is the correct system. To ensure that you connect to the correct SSH server, you should manually verify this host key the first time you connect to a server by comparing it to the one stored on the server. SSHFP automates this process with DNS.


  • Linux VPS running an SSH server
  • Linux computer with the OpenSSH client or another Linux VPS
  • Domain name with DNSSEC set up
  • A and (optionally) AAAA records pointing to your VPS
  • DNSSEC-capable DNS resolver

DNSSEC is required for SSHFP records to work, as it allows the SSH client to trust the information stored in DNS records. Enabling DNSSEC is covered in the Introduction to Vultr DNS. You should also check that the DNS resolver used by your computer supports DNSSEC. If it doesn't, Google Public DNS or Cloudflare's service are free alternatives.

1. Generate SSHFP Records

Log on to your VPS and run the following command, replacing the example name with your server's Fully-Qualified Domain Name (FQDN).

# ssh-keygen -r

Your FQDN should be the same as the A record on your domain that points to your server's IP address. You must run this from the server because the SSHFP records are generated from the SSH server's public key. You'll see output similar to: IN SSHFP 1 1 9bd1755b811ba9c9a4416400e7b379d403ca8d11 IN SSHFP 1 2 44ec99231d0cf174e0d36c4ee691d55ec65c31c754e4348250d4162c148bde82 IN SSHFP 3 1 c926ddf5ecbfbcc7dca7d8b6b0fc4c5002c6d60a IN SSHFP 3 2 307f3924ad32abe24d97594f2949718adf9d185a96312fcc9a885c20da7f7bd4 IN SSHFP 4 1 7d66e7ef5340329337e58e576c54468dd6246c99 IN SSHFP 4 2 491f54c3864c4509e4734651ed45365cecdec28a1edc6866212fdfac0fa83b4f

2. Update your Domain's DNS Records

Add the SSHFP records you generated with the ssh-keygen command to your domain's DNS records. You should create a new SSHFP record for each line. Make sure that the hostname of the SSHFP record is the same as the hostname of your server.

If you're using Vultr DNS, your DNS entries should look similar to this:

Screenshot of DNS entries

3. Test your new DNS Records

DNS records can take some time to propagate across the internet. You can check whether your new SSHFP records are live by using the dig command. You may have to install it; on Debian and Ubuntu, this can be done using apt-get install dnsutils.

$ dig SSHFP +short

4. Enable DNS Verification

OpenSSH does not verify SSHFP records by default. On the computer used as the SSH client, create the file .ssh/config in your home directory and add the following line:

VerifyHostKeyDNS yes

5. Connect to your SSH Server

If you have previously connected to the server, delete the line starting with the hostname from the .ssh/known_hosts file in your home directory.

Then, use the ssh command as usual:

$ ssh

Despite the host key for your server no longer being in the known_hosts file, you shouldn't be prompted to verify the host key anymore. That means the SSHFP records are working.

Common Issues

Matching host key fingerprint found in DNS

You may sometimes encounter this:

$ ssh

The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:MH85JK0yq+JNl1lPKUlxit+dGFqWMS/MmohcINp/e9Q.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This message usually indicates an issue with DNSSEC. OpenSSH can find the SSHFP records but is not able to validate them using DNSSEC. You should check that DNSSEC is set up correctly for your domain using a tool like DNSViz. You should also check that your DNS resolver supports DNSSEC. You can do this using dig:

$ dig


;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


Look for the flags section and check for the ad flag, indicating that the response has been DNSSEC validated. If the ad flag doesn't show, check the default DNS servers for your system. Some ISP or home router DNS servers may not fully support DNSSEC.

Considerations for macOS and Windows

The macOS DNS system currently does not seem to support DNSSEC correctly, so you may see the same issue if you try to connect from a macOS device. You could alternatively try connecting using another Linux VPS.

The latest OpenSSH builds for Windows do not support DNS verification.