Until now I generated all SSHFP resource records on the SSH destination server itself via ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third-party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:

Generating SSHFP Records

I found and forked a small bash script that scans the SSH public keys from the remote server and generates the appropriate resource records. Note that the output depends on the type of public keys the server uses, e.g., RSA, ECDSA or even Ed25519. (For an overview of different SSH key fingerprints have a look at this at-a-glance picture.) I am only using the SHA-256 hashes. You can ignore the SHA-1 output (shorter line with “1” in the 5th column). Download the script and make it executable:

And call it with the DNS name or IP address of the destination:

Verifying the Output!

This is really important:

Example 1: Palo Alto Networks Firewall

In the previous example, I generated the SSH fingerprints for a Palo Alto Networks firewall. Logging into their CLI I could verify both fingerprints (sha1 and sha256) for the single RSA public key:

Example 2: Fortinet FortiGate Firewall

Another example shows the generation of the SSHFP records for a FortiGate firewall:

As you can see, it offers two public keys (4th column). “1” for RSA and “4” for Ed25519 (refer to DNS SSHFP Resource Record Parameters), both hashed (5th column) with “1” for SHA-1 and “2” for SHA-256. Unfortunately, FortiGate is not really helping in displaying the required fingerprints:

First, their output shows the fingerprints for RSA and DSA while SSH to the device used RSA and Ed25519. Hence, the Ed25519 fingerprint is missing.

Furthermore, it’s not trivial to compare the fingerprints from the FortiGate to the SSHFP records since the FortiGate outputs MD5 while SSHFP uses only SHA-1 and SHA-256 (and you still cannot “decrypt” a hash to its input). My workaround was to download the complete public key with nmap --script ssh-hostkey --script-args ssh_hostkey=full fg, save it to a file, show the fingerprint in MD5 ssh-keygen -l -E md5 -f fg-rsa.pub, compare it to the CLI output from FortiGate (was correct), and compare the fingerprint in SHA-256 to the SSHFP record. The latter also required transforming the base64 output from ssh-keygen to a hex output for SSHFP using this online converter. WTF. However, everything was correct and I now know as well that the RSA public from this FortiGate is correct.

Example 3: Cisco IOS Router

As a third example I generated the SSHFP records for a Cisco Router 2811 (Version 15.1(4)M12a):

You cannot display the fingerprints directly but you can display the complete SSH key with show ip ssh :

I saved the key (the line that starts with ssh-rsa) into a file and used ssh-keygen again to generate the SSHFP records using this public key. Hence I was able to compare and verify the fingerprints:

Workaround for DSA Keys

Unfortunately, I did not succeed in scanning a DSA fingerprint with ssh-keyscan at all.

Example 4: Juniper ScreenOS Firewall

For example, when connecting to an old Juniper ScreenOS firewall only ssh-dss can be used. (OpenSSH 7.0 has disabled the support for DSA per default due to its weak security.) I tried it with ssh-keyscan but it did not output anything

while the Nmap script ssh-hostkey in fact was able to retrieve it:

For the sake of completeness here is the ssh-keyscan with -vvv. Maybe someone can tell me why it does not succeed? My question at Server Fault is here. I also tried to set the “KexAlgorithms +diffie-hellman-group1-sha1”, “HostKeyAlgorithms +ssh-dss” and “PubkeyAcceptedKeyTypes +ssh-dss” within the /etc/ssh/ssh_config file but this did not change anything for ssh-keyscan.

As a workaround I used the  --script-args ssh_hostkey=full for the just mentioned Nmap script to retrieve the complete public key:

I then saved this pubkey (“ssh-dss AAAAB3Nza… … … DczuqA==”) into a file and used it to generate the SSHFP records:

And again, do not forget to verify the public key / fingerprint with the device itself. In this example it was an old Juniper ScreenOS firewall which shows the same fingerprint (e7:5b:…) as captured with Nmap above:

Cheers! ;)

Featured image “Condor Business Class Inseat Entertainment” by Condor.com is licensed under CC BY-NC-ND 2.0.