Related

Is it possible to configure an sftp user for uploading and editing but NOT downloading files? Question Question
Set umask for another user Question Question

Question

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

Posted February 13, 2017 18.2k views
SecurityUbuntu 16.04

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.

Add a comment
Seriously
By:
Seriously
Add a 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.

×
6 answers
Seriously February 15, 2017

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.

Reply Report
xMudrii February 13, 2017

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.

Reply Report
Seriously February 14, 2017

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

Reply Report
  • gp1bot March 26, 2017

    I’ve recently starting seeing this on all my droplets. Weird. Didn’t notice it a couple months ago.

    I’ve gone ahead and cleared out the SSH keys and reissued new ones via the Console and my local machine, just in case they snagged a ssh key via a MITM attack.

    Better safe then sorry

    Reply Report
Seriously February 13, 2017

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?

Reply Report
jtittle1 February 14, 2017

@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.

Reply Report
  • jtittle1 February 14, 2017

    @Seriously

    To extend my comment above, and something I do on my own deployments, you should create unique users for each purpose, each of which will have their own unique SSH Key (if they need SSH access, otherwise set their shell accordingly).

    Beyond that, I don’t assign the sudo user to anything specifically. That means that this specific user doesn’t own any directories other than its own /home/username/* directories.

    The sudo user does not run services, is not a user that owns public-facing or web-accessible directories, and is used exclusively for updates, upgrades, and modifications as needed.

    Additional basic users are created for each public-facing and/or web-accessible directory that would house content for one of my websites. SFTP is setup for these users, but short of being able to write to their own files (as they should), they can’t do much else.

    Reply Report
fevicks March 13, 2017

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) ✗

Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help