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, 2018 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. Feb 17, 2018 at 15:54

2 Answers 2


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.

  • 5
    This is the TOFU principle: Trust On First Use Feb 16, 2018 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, 2018 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, 2018 at 16:29
  • @Attie You can also use certificates instead of keys for SSH, and then you go back to the HTTP world PKI model of trust. Feb 16, 2018 at 17:24
  • 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, 2018 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)

You must log in to answer this question.