2

When first connecting via SSH with keys to a newly minted Digital Ocean droplet VM running FreeBSD (per this tutorial), we get a message about “The authenticity of host blah-blah can’t be established”. I understand this means my computer has no stored fingerprint against which to compare. So my SSH client has no way of knowing if the SSH server on the other side is legitimate or not.

At this point, we have two choices:

  • We can blindly forge on by accepting this connection per the TOFU “Trust On First Use” anti‑security model. If we are the subject of a Man in the Middle attack, we are falling prey to their trap.
  • Or we can discover the fingerprint of the server by some other means, to compare against the fingerprint being presented here in this first connection.

Amazon provides such a mechanism for their EC2 instances, to learn the new server’s fingerprint, as discussed here.

➥ Is there such a mechanism for a Digital Ocean “droplet” virtual machine instance, to learn the server’s fingerprint?

2

I know this is an old question, but I ran across this exact same problem today, and the OP's spot-on with the TOFU anti-security model, so here's what I used to avert the risk of MITM.

Normally, as the question implies, there really isn't a way to verify keys without somehow talking to the server admins. However...

...if you do have access to the server, you can display the fingerprint of an SSH key by running ssh-keygen -lf on either the public or the private key...

...and fortunately, at present DigitalOcean provides a web-based console to log directly into a droplet, thus giving you access to the server in question. To get to the console:

  • Head to your Account Dashboard.
  • In the sidebar, under the "Manage" heading, select "Droplets."
  • Select the droplet for which you want to verify the fingerprint.
  • It will probably bring up the "Graphs" subsection by default, but you'll want to select the "Access" subsection.
  • From there you should see options to "Launch Console" or "Reset Root Password."

Now, since the DigitalOcean console expects you to log in as root, you'll need a root password. So if, like me, you chose to use the more secure SSH authentication when initially setting up the droplet, you can spare yourself some frustration and start by selecting "Reset Root Password." Once DigitalOcean sends you the new root password, proceed as follows:

  • Select "Launch Console." To log in, the username is root, and the password is what you set (or the reset code DigitalOcean sent you). Tip: the console does accept copy-pasting, which is useful for password reset codes. Also, for a reset you'll immediately be asked to confirm the reset code and select a new password, so be prepared for that.
  • Once you're in, cd to wherever your droplet's OS would store system-level SSH keys (for me, on an Ubuntu 18.04, it was under /etc/ssh; I used the method found in this answer).
  • From there, run the following bash script (or similar for your OS's shell) to see all the fingerprints of all the keys: for file in *; do ssh-keygen -lf $file; done; (I did this as a 1-liner, punctuated as shown, and it worked for me; no clue if it's idiomatic bash-script. If it encounters non-key or password-protected private-key files, it'll note the fact and pass them by harmlessly. It was lifted with slight modifications from this helpful site)
  • Compare the output shown with the original SSH authenticity challenge. If it doesn't match, you know there's a risk of Man in the Middle, and should not accept the key.

If anyone knows of an easier way, e.g. getting fingerprint info via DigitalOcean correspondence or some hidden part of the Dashboard, feel free to post another answer, and I'll gladly upvote it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.