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 'examplehost.example.org (192.0.2.123)' 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.
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 184.108.40.206 service are free alternatives.
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 examplehost.example.org
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:
examplehost.example.org IN SSHFP 1 1 9bd1755b811ba9c9a4416400e7b379d403ca8d11 examplehost.example.org IN SSHFP 1 2 44ec99231d0cf174e0d36c4ee691d55ec65c31c754e4348250d4162c148bde82 examplehost.example.org IN SSHFP 3 1 c926ddf5ecbfbcc7dca7d8b6b0fc4c5002c6d60a examplehost.example.org IN SSHFP 3 2 307f3924ad32abe24d97594f2949718adf9d185a96312fcc9a885c20da7f7bd4 examplehost.example.org IN SSHFP 4 1 7d66e7ef5340329337e58e576c54468dd6246c99 examplehost.example.org IN SSHFP 4 2 491f54c3864c4509e4734651ed45365cecdec28a1edc6866212fdfac0fa83b4f
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:
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 yourvps.example.com +short
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:
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 email@example.com
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.
You may sometimes encounter this:
$ ssh firstname.lastname@example.org The authenticity of host 'examplehost.example.org (192.0.2.123)' 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 examplehost.example.org ... ;; 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.
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.