1

When I used ssh-genkey on macOS to generate the pair of key files (one named with .pub), that tool reported a SHA256 hash as a public key fingerprint.

When first connecting to my server, a Digital Ocean droplet virtual server instance running FreeBSD initialized with the contents of my .pub public key file, on first trying to connect with ssh 1.2.3.4 I get the message:

The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.

ECDSA key fingerprint is SHA256:tjdoQBGbHexAm+uwZ5rZwxyJH0nxjMC08QtO47QGQjE.

This does not appear to match the SHA256 returned by ssh-keygen when I created the key files.

Some sites seem to say I should ignore this issue. They claim the key fingerprint that appears when connecting to my server via ssh is unrelated to the fingerprint of the ssh public key file’s content I uploaded to Digital Ocean for use in creating that server instance. I find this difficult to fathom.

  • What point is there in Digital Ocean insisting I supply a SSH public key to use in configuring my new server if it is ignored or is irrelevant?
  • What stops a Man-In-The-Middle attack if I am to ignore the fingerprint reported during the first attempt at establishing a ssh connection/session?
  • Why does ssh even report a key fingerprint if we are to ignore it?
Community
  • 1
Basil Bourque
  • 137
  • 6

1 Answers1

3

There are two separate keys at play here:

  1. Your personal client ssh key that you generated on your laptop, the private key is on your laptop, and therefore this key identifies that a connection is originating from your laptop.
  2. The server's ssh key which was generated on the server during first-time boot (at least I assume so since you say you only uploaded a public key), the private key is on the server, and therefore this key identifies that the connection is terminating at your server.

Your core question seems to be: What does Digital Ocean do with the public key I uploaded during VM creation?

For an authoritative answer, you'd have to read Digital Ocean's documentation, but my guess is that they stick it in /home/user/.ssh/authorized_keys so that your public key (aka your laptop) is the only one that's allowed to connect to that machine. See this guide for more info.

To answer your 2nd and 3rd questions: ssh clients follow the Trust On First Use (TOFU) paradigm, and inherit all the strengths and weaknesses of it. It's not ideal, but it's probably at least as good as what would happen if you tried to switch ssh to certificates: half the ssh servers in the world would use the default cert that ships with openssh.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • I disagree; the OpenSSH/OpenBSD people are quite security conscious and would not ship an easily abused default. Instead far more than half of servers would use a key&cert copied from the first 3 websites listed by Google for the query "where can I get an SSH cert"? (Contrast with the Apache DHparams found by Logjam -- and the Sun-Java ones which were just as bad until IIRC j8.) – dave_thompson_085 Oct 16 '21 at 00:02