How to Authenticate SSH Servers with SSHFP – 20ms –

SSH is a the default tool when remotely connecting to a Linux dedicated server or VPS. It creates a secure connection to the server with all the data transmitted encrypted safely, allowing you to manage the server through a remote terminal session.

Securely Connecting to Your Server

One of SSH’s key features is the use of keys to identify the server you are connecting to, meaning that you can be certain you are connecting to the correct server and not another server pretending to be that one. Unfortunately, users who connect to many servers can be accustomed to seeing the warning message that a server’s key is unknown, so they begin to just hit ‘Yes’ to accept them without ever checking the authenticity of the server’s identity.

SSHFP presents a potential solution to this problem. This works by using the DNS system to publicly advertise the key fingerprint of the server, allowing any user to verify that the server they are connecting to is the correct one by comparing the key fingerprint presented by the server with the one held in DNS. As this is a feature supported by SSH by standard, there’s nothing that needs to be installed on client PCs. Once enabled, you’ll only ever see a warning about a server’s SSH identity key if there’s no SSHFP record for it in DNS, or if there’s a problem with the key. The downside to this method is that it requires you to be using DNSSEC with your DNS in order to work, so if you are using DNSSEC here’s how to get SSHFP working.


First, you need to configure your domains with SSHFP records that allow the SSH keys on the servers to be identified. Fortunately, the ssh-keygen tool makes this a very simple process. On the server you wish to identify you simply need to run:

ssh-keygen -r $(hostname)

The -r flag tells ssh-keygen to display the DNS resource record, while $(hostname) presents it with your server’s hostname. Provided you have your server’s hostname set up correctly with the fully qualified domain name, you should see an output like this: IN SSHFP 1 1 b4049d10454f2f5cb74688b5be2843ee08a2add5 IN SSHFP 2 1 f52df2cea30e6a435f3fdb4be70c72acdb73bfe0

These lines just need to be copied into your DNS configuration, although if you aren’t using BIND as your nameserver you may need to consult the documentation to ensure that the format given by ssh-keygen is correct. For BIND users, note that you’ll need to put a full stop at the end of the domain name when pasting these records into your DNS record. Once this is saved and your name server is serving these records, you can check for them by digging for them:


Note you’ll need to change to your correct domain information. This should return the SSHFP records that you previously set. If this works then you can move on to the next step. If it doesn’t, then you’ll need to check your DNS configuration to ensure the records are being returned correctly.

Once the DNS is configured, the last step is to configure SSH on your local machine to accept SSHFP records for server identification. This can be done by editing the global SSH configuration on your computer, or your user’s ssh config. I’m using nano in my example, but other editors are available:

nano ~/.ssh/config

With the file open you need to add the following line:

VerifyHostKeyDNS yes

This means that it will accept a matching DNS entry for a server’s SSH identity key every time. It’s also valid to set this value to “ask” instead of “yes”, whereupon it will ask if you want to accept that match. If you save and exit that file then the next time you attempt to connect to a server SSH will attempt to identify it using SSHFP if possible before falling back to asking you to manually accept the host key. Note that if you want other people who are connecting to your server to benefit from SSHFP then you’ll also need to inform them to make this change to their local SSH configurations in order for them to use it.

Never miss another post. Sign up for the weekly 100TB newsletter and follow us on Facebook and Twitter.

Originally published at

0 Comment


Comments are closed.