Use DNSSEC to Verify SSH Host

Are you secured ?

When setting up a new server, you might want to configure a SSH server to connect easily to it. While doing so, the first time you connect, you will be prompted to accept the new host in your known host file. While a lot of people simply accept this new host a MITM attack is definitely possible with this setup.

I will show you how to secure every new host connection with DNSSEC.

What is the problem ?

The host signature that the ssh client is showing you when first connecting to a ssh server is not verified by anything. That’s why the prompt asks you if you want to trust this signature. It is not secured and you are supposed to verify it with the admin who gave you priviledge to the server. If you don’t verify it you can become the target of a Man in The Middle attack. Such attacks happen when someone is listenning and interfering on the network between the server and you. DNS spoofing would be a good way to redirect your connection attempts to the poisoned server for example.

When the attacker sees the start of the ssh connection, it takes the packets sent by the server and act as client from its point of view. Then it acts as the server before sending you the rest of the data. The server thinks it is communicating with you and you think you are communicating with the server but it’s not what is happening. The attacker can now listen to every packets from your server to you. Every file you send over scp, every command you play. Moreover, it can simply connect to the server by itself and run any command as you. Normally such situations only happen when first connecting to your ssh server because after that the ssh key is stored in ~/.ssh/known_hosts. However, if you take the risk of accepting the keys without verification the first time you can be left with the wrong signature for the host and an unsecured connection.

What is DNSSEC ?

Ok we talked about the risks, and I mentionned DNSSEC earlier. What is this thing ?

DNSSEC or “Domain Name System Security Extensions” is a way to authenticate DNS responses and avoid DNS spoofing for good. DNSSEC works as a key signing chain of trust starting at the root DNS server level. From there all following DNSSEC keys are verifying the lower levels of DNS server keys until they reach your own name servers. Then your name server can sign the data it transmits and the client can verify the authenticity of the response.

How to configure DNSSEC verification for my server FQDN ?

Now we will run ssh-keygen -r $(hostname --fqdn) on our server to display the records we need to add to our DNS zone. Such entries are known as SSHFP entries. That’s these entries that we will use later on to verify the server key.

Simply copy the result of your command in your DNS zone and activate DNSSEC in the settings of your name server. Most NS provider will offer this option nowadays. If yours don’t, you should really change provider. If you manage your own name servers, there should be an option to activate it. Check your documenation !

How to verify it when connecting with my SSH client ?

Ok now we have :

We can now connect to our server using : ssh -o VerifyHostKeyDNS=yes example@example.com

With the flag “-o” we use an option that can also be specified in a host config like so :

Host example.com
    VerifyHostKeyDNS yes
    Hostname example.com
    User yourusername

This option makes the ssh client check the validity of the host signature against the SSHFP record that we put in our DNS. Even better, it does it everytime a new connection is starting. Now everytime someone provision this host they can simply update the DNS record and you will have it working directly. No need to invalidate keys in your ~/.ssh/known_hosts anymore.

Conclusion

It is very good practice to use such a system to protect the authenticity of the ssh server you are responsible for. It is a very useful tool when working with a lot of other people in a constantly moving environement.