Whenever I connect to a new SSH server from my computer I get this message:

The authenticity of host '[censored]:censored ([]:censored)' can't be established.
RSA key fingerprint is SHA256:censored.
Are you sure you want to continue connecting (yes/no)?

Why does SSH ask me that?

Do I have any risk of connecting to a random SSH server?

Or is this just to make sure the server you are connecting to hasn't been hacked?

  • Are you using a password or a key to log in? – kasperd Feb 17 '18 at 1:19
  • 1
    There are several better ways to distribute host keys than trust-on-first-use; this is a relatively insecure workflow. Host keys can be distributed via LDAP; via signed DNS entries; can be signed with SSH certificate authorities; etc. Which is to say -- what you're seeing here indicates that your site is configured "the lazy way" (which almost all are!), which is less secure than going to further lengths to do things right. – Charles Duffy Feb 17 '18 at 15:54

It's asking you because it's never connected to this host before.

If you are in a secure environment, then you will know the remote host's fingerprint, and will compare it on the first connection - if the fingerprint matches what you know it should be, then great. If you're in a less secure environment, then you can just accept it on first connection.

Once you've said "Yes, I trust that host key, and want it to be associated with that hostname/IP", the SSH client will remember this for you... If for whatever reason (reinstall / new host keys / new machine / man in the middle) the key doesn't match on a subsequent connection, you will see a warning like below:

$ ssh baloo
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/attie/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/attie/.ssh/known_hosts:65
  remove with:
  ssh-keygen -f "/home/attie/.ssh/known_hosts" -R baloo
ECDSA host key for baloo has changed and you have requested strict checking.
Host key verification failed.

In this situation, if you know that the remote host has indeed been changed, then you can proceed... possibly verifying that the fingerprint is correct.

If you are unsure, or know that the remote host should not have changed, then it will clue you in to a potential attack.

| improve this answer | |
  • 4
    This is the TOFU principle: Trust On First Use – Patrick Mevzek Feb 16 '18 at 14:25
  • 2
    Agreed, TOFU isn't a great idea - especially if you need to be sure... Your opinion and approach will (should) depend on your thread model. – Attie Feb 16 '18 at 15:47
  • 1
    However, for the effectiveness of this, see cs.auckland.ac.nz/~pgut001/pubs/defending.pdf , pages 45-48. – Joker_vD Feb 16 '18 at 16:29
  • Interesting slides, thanks for sharing @Joker_vD – Attie Feb 16 '18 at 17:12
  • 1
    @PatrickMevzek The problem is that our entire model of computer "trust" is fundamentally at the granularity of a boolean, while in the real world a practical model of trust (such as what we intuitively use in inter-human relations) is more like a conditional probability: given a claim from an entity, we have some degree of confidence that the entity will follow it, and we limit our exposure to risk in proportion to that. – mtraceur Feb 16 '18 at 20:55

When you get this message SSH is simply saying "I have never seen this computer before so I can’t be sure it’s who it says it is. Do you trust it?" At which point you can say that you trust it and in the future your computer will remember and not ask you again.

Ideally to trust it you should manually compare the key provided with the key on the server (as you would trust a GPG key by checking that the person who you believe it belongs to can actually generate the public key). Although in reality people don’t bother with this (at least from my knowledge).

The real benefit comes from each subsequent time you connect to the server. If SSH complains about the server which you have already trusted not being the same server then there is a chance you are the victim of a MiTM attack.

Over all if you are on a network where you are confident there is no Man in The Middle attack going on and this is the first time you are connecting to the computer then you should be safe to accept the key. (although if you are working on some top secret government mission then maybe ask your system administrator to verify the fingerprint before connecting)

| improve this answer | |

Your Answer

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