How to verify droplet's SSH public key fingerprint?

Posted August 27, 2018 4.4k views

Before SSHing to a droplet for the first time, is there a way to verify the public key fingerprint? This question was asked last year, but there wasn’t any good way to do this back then. Any updates?

As the previous asker suggested, “Ideally it would be part of the response body when a new droplet is created or have its own API call”. The fingerprint could also be displayed in the web interface for each droplet.

1 comment

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
3 answers

I found another solution for this: when creating the droplet, enable “User data” and put in a script which installs a web server and publishes the server’s SSH key fingerprint. You can verify the key hasn’t been modified in transit using an HMAC with a shared secret. Here’s an example script:


# install web server
apt-get -y update
apt-get -y install apache2

# put the public ssh key fingerprint in the default webroot
ssh-keygen -lv -f /etc/ssh/ssh_host_ed25519_key > /var/www/html/key
chmod o+r /var/www/html/key

# generate the HMAC of /var/www/html/key
cat /var/www/html/key | openssl dgst -sha256 -hmac "SECRET" > /var/www/html/hmac
chmod o+r /var/www/html/hmac

Replace SECRET.

Then you can access http://your-droplets-ip/key to see the public key and http://your-droplets-ip/hmac to get the HMAC.

To make sure that a MITM hasn’t modified the key file in transit, you can verify the HMAC on your computer:

curl -s http://your-droplets-ip/key | openssl dgst -sha256 -hmac "SECRET"
curl -s http://your-droplets-ip/hmac

The output of these commands must be identical.

Alternatively, you can also have the script email you the key & hmac.


Hey friend!

Currently the only way to do this would be to log in through the web console and check it there before accepting it over SSH. I suppose no matter how you spin it, you’re accepting something remote as truth, so I don’t know the most flawless answer. It is an interesting thought experiment, I fear it will plague my mind for the remainder of the evening.


  • Hi, thanks for your reply. The problem is that you can’t log in through the web console if you add your SSH key when creating the droplet.

    If the droplet’s SSH fingerprint was displayed in the web interface, then the only thing you’d need to trust would be the website (there’s no way around that, after all, but that’s what the EV certificate is for). In the current situation, you also need to (blindly) trust every new key you receive when logging in through SSH. This really should be addressed, it’s an important security issue.

    • Thank you for pushing for this @orric. I’m experiencing this right now and it’s a huge hassle… this should be absolutely trivial and as you suggest shown to the user during the droplet creation process!

    • There’s a rather awkward way, at least with Ubuntu 18.04:

      1. Shut down
      2. Switch to boot from the Recovery ISO
      3. Start up
      4. Open the Console
      5. When the menu shows up, choose “mount drive”
      6. Choose chroot
      7. You can now use ssh-keygen -l -f /etc/ssh/ to dump the fingerprint, change the key file and/or add -E md5 as needed

      Even more awkwardly the console is a canvas, so you can’t copy the fingerprints (or the whole key) easily. I didn’t check if the recovery ISO has net access to send keys out somewhere.

      • Thanks! Good to know.

        I also found that the fingerprints are shown in the web console right after the VM is created (with Debian 9, at least). You can see them without having to log in. The problem is that, as you said, the console is a canvas element, so you can’t copy text from it.

        If anyone knows a way to copy text from the web console, please leave a comment.

        • You could print an image of the screen and then read it off a text converter. It does a pretty good job when it comes to the private keys which are particularly long.

how about as @orric suggests, but instead of your own server display it in the webconsole? e.g.

When creating the droplet, enable “User data” and put in a the following script?

ssh-keygen -lv -f /etc/ssh/ssh_host_ecdsa_key >> /etc/issue

And then clicking the console in the control panel to see the key fingerprint in the pre-login banner?
Obviously edit key file to taste.