19
2
Whenever I connect to a new SSH server from my computer I get this message:
The authenticity of host '[censored]:censored ([0.0.0.0]: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?
29
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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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
SHA256:Su0uy/4BcRcpmyLfxO9ndlcda52F8uct6yWNp7Sa92M.
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.
Attie
Posted 2018-02-16T13:03:05.997
Reputation: 14 841
4This is the TOFU principle: Trust On First Use – Patrick Mevzek – 2018-02-16T14:25:08.730
2Agreed, 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 – 2018-02-16T15:47:42.247
1
However, for the effectiveness of this, see https://www.cs.auckland.ac.nz/~pgut001/pubs/defending.pdf , pages 45-48.
– Joker_vD – 2018-02-16T16:29:33.443Interesting slides, thanks for sharing @Joker_vD – Attie – 2018-02-16T17:12:31.787
@Attie You can also use certificates instead of keys for SSH, and then you go back to the HTTP world PKI model of trust. – Patrick Mevzek – 2018-02-16T17:24:31.253
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 – 2018-02-16T20:55:11.753
@mtraceur you are describing the PGP web of trust model... https://en.wikipedia.org/wiki/Web_of_trust
– Patrick Mevzek – 2018-02-16T20:55:59.040@PatrickMevzek I think that's closer to my idea, but isn't that still fundamentally boolean in how it's used? Ultimately you either say "yes I trust the key" or "no I don't" - there are no tools that meaningfully behave differently based on a more granular notion of trust that I'm aware of. What I'm thinking of would involve a web-of-trust based on machines adjusting trust-assessments of other machines using machine learning algorithms, and communicating their trust-assessments to each other (which themselves would be only weighed by each machine in proportion to some trust-rating). – mtraceur – 2018-02-16T21:21:32.800
@PatrickMevzek I'm also thinking that such a system would have to be far more wholistic than just focused on one protocol like SSH or TLS or PGP. Operating system would need to be dynamically factoring in any deviations from expected protocols they detect, down to the lowest network levels, and any other data points of concern, and expose this with sufficient granularity to userspace programs. We're starting to side-track now, but I wanted to make sure it was clear what I meant about "boolean" trust models being insufficient. If you want to discuss this further, let's take it to chat? – mtraceur – 2018-02-16T21:24:22.607
@mtraceur No, it is not boolean. There is a scale of trust, but probably not enough for your case. We are off-topic now here. – Patrick Mevzek – 2018-02-16T21:38:09.633
9
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)
KNejad
Posted 2018-02-16T13:03:05.997
Reputation: 363
Are you using a password or a key to log in? – kasperd – 2018-02-17T01:19:26.073
1There 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 – 2018-02-17T15:54:36.487