Question

MITM: The authenticity of host can't be established.

Hi,

I’ve searched through the questions and am surprised that I haven’t seen an adequate answer to this question yet so maybe I’m missing something.

I created a new Ubuntu droplet and when I try to SSH into it I’m presented with the following warning:

The authenticity of host 'x.x.x.x' can't be established.
ECDSA key fingerprint is SHA256:XwYwckT3ivmDkwGBBRN93ANuzYpvlEvo4DQ+qZo7MB8.
Are you sure you want to continue connecting (yes/no)?

SSH is warning me that there could be a man-in-the-middle attack occurring (thank you SSH!). In order to avoid this I need to verify the fingerprint of my new droplet through a secure channel (i.e., the DigitalOcean web interface). The only promising option I see in the web interface is the Console, which I presume will allow me to log in and view the server logs where I can see the server fingerprint. However, I can’t log in through the console because I added an SSH key to my droplet at creation time and no password was set.

Does this mean that I have to forgo the security of adding an SSH key at droplet creation time so that I can log in via the console to verify my server fingerprint, and then after that add a SSH key manually? It’s considered bad practice to rely on passwords without SSH keys these days so this surprises me.

Thanks for your help in keeping my droplets secure from man-in-the-middle and password attacks.

Subscribe
Share

Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

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.

Accepted Answer

I tried creating a droplet again, this time with Debian instead of Ubuntu, and I see the server fingerprints in the console before logging in. I don’t know if it’s because I chose Debian this time or if I just didn’t notice them last time but either way I’m happy now.

Thank you for putting the time into such a verbose response. Unfortunately, no one has answered my question yet. You’re both advising me to ignore a possible man-in-the-middle attack which is bad security practice.

It’s possible to verify the server fingerprint on Amazon EC2 during the first connection so I know it can be done and that people other than myself do care about it. See http://ubuntu-smoser.blogspot.com/2010/07/verify-ssh-keys-on-ec2-instances.html

Message you see is okay if you see message for first time. And as you say that you created new Droplet, message is valid.

What is this message? SSH have file called known_hosts which saves fingerprint for each server you connect to. If you never connected to that server via SSH, you’ll see following warning. Just answer yes to continue and save host for next time. When you login again, you’ll not see warning.

If you see warning anytime after first connecting, that is problem and you must verify is everything okay. In this case you’ll not even be able to connect to Droplet.

So as this is first time from this PC, it’s secure to continue.

Message you see is okay if you see message for first time. And as you say that you created new Droplet, message is valid.

What is this message? SSH have file called known_hosts which saves fingerprint for each server you connect to. If you never connected to that server via SSH, you’ll see following warning. Just answer yes to continue and save host for next time. When you login again, you’ll not see warning.

If you see warning anytime after first connecting, that is problem and you must verify is everything okay. In this case you’ll not even be able to connect to Droplet.

So as this is first time from this PC, it’s secure to continue.

I received the below message - please check it

➜ ~ git:(master) ✗ ssh-copy-id root@xxx.xxx.xx.xxx /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys Permission denied (publickey). ➜ ~ git:(master) ✗

@Seriously

Short of disabling StrictHostKeyChecking, which isn’t recommended, the first time you connect to a new host (i.e Droplet/VPS, Dedicated Server, etc), you’re going to see a message like this as the host you’re connecting to isn’t recognized by your local machine.

When a machine isn’t recognized by your local machine, this means that the known_hosts file on your local machine doesn’t contain a line such as:

101.111.22.111 ecdsa-sha2-nistp256 ....

Where 101.111.22.111 is the IP of the machine you’re connecting to, which is how your local machine knows and keeps track of whether or not you’ve connected to this machine before.

After confirming the connection, your local machine will store a line such as the above (with a valid key) which it will then use to verify future connections against.

If you’re not re-imaged your Droplet, and you’re not potentially the target of a MITM attack, you won’t see this message pop up again.

If you do re-image your Droplet (i.e. reinstall the OS), you will be asked to the same again as the key for the machine will change. Connecting to the machine after the re-image should also fail and state that the key in your known_hosts file doesn’t match the key provided by the server, in which case you would need to delete the existing key from the known_hosts file and try to connect again.

In regards to security, if you’re looking for the most secure means of connection, then you should do the following.

1). Deploy Droplets with a passphrase protected SSH Key that’s between 4096 and 8192 bits.

2). Disable password-based logins entirely (thus forcing the use of SSH Keys).

3). Setup a working sudo user complete with a unique SSH Key.

4). Disable root logins.

5). Always login to SSH with the sudo user (a given due to #4).

Even with the above, each new user that connects to the host machine is still going to see that message if they’ve never connected before.

Thank you for answering.

What makes it OK if I see the message for the first time? You write “as this is first time from this PC, it’s secure to continue.” How do you know that? How do you know there isn’t a man in the middle attack occurring the first time?