132

What does this message mean? Is this a potential problem? Is the channel not secure?

Or is this simply a default message that is always displayed when connecting to a new server?

I am used to seeing this message when using SSH in the past: I always entered my login with a password the normal way, and I felt fine about it because I wasn't making use of private/public keys (which is much more secure than a short password). But this time I have set up a public key with ssh for my connection to bitbucket but I still got the message. I am aware that the passphrase prompt at the end is a different, supplementary security measure, for the decryption of the private key.

I'm hoping somebody can give a nice explanation for what is meant by this "authenticity can't be established" message.

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':
Steven Lu
  • 3,668
  • 4
    This really is one of those "means precisely what it says" messages. It means ssh has no way to tell that you are really talking to bitbucket.org. If you configured some way for it to know, then it's not working. If you didn't, then it's telling you that you didn't. – David Schwartz May 06 '12 at 00:13
  • Verify your keys by following this tutorial https://www.linode.com/docs/guides/verifying-the-authenticity-of-remote-host/ – igor Feb 13 '23 at 10:27

7 Answers7

104

It's telling you that you've never connected to this server before. If you were expecting that, it's perfectly normal. If you're paranoid, verify the checksum/fingerprint of the key using an alternate channel. (But note that someone who can redirect your ssh connection can also redirect a web browser session.)

If you've connected to this server before from this install of ssh, then either the server has been reconfigured with a new key, or someone is spoofing the server's identity. Due to the seriousness of a man-in-the-middle attack, it's warning you about the possibility.

Either way, you have a secure encrypted channel to somebody. No one without the private key corresponding to fingerprint 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 can decode what you send.

The key you use to authenticate yourself is unrelated... you wouldn't want to send authentication information to a fraudulent server who might steal it, and so you should not expect any changes depending on whether you're going to use a passphrase or private key to login. You simply haven't gotten that far in the process yet.

Ben Voigt
  • 7,236
  • So, even if there is a malicious third party, and I dismiss the message, all I'm going to be doing is sending him my public key, and he will still not be able to decrypt my data? So now the only ways my data can be compromised are if (1) my private key is compromised or (2) bitbucket's servers are compromised or (3) my bitbucket account is compromised. So long as they limit login attempts (which I'd be really surprised if they don't do) there really aren't that many reasons to be paranoid at this point, eh? – Steven Lu May 06 '12 at 00:38
  • 14
    @Steven: You're not sending him your public key, he already has that. What you're doing is using your private key to authenticate a challenge... if he connected to the real bitbucket.org claiming to be you, received the real challenge, and used that challenge when challenging you, he could then fool you into sending him a valid response which he then uses to gain access to your account on the real bitbucket.org. He still doesn't have your private key, so he can't login at any future time, or to any other resource that key unlocks, but he does have one login session. – Ben Voigt May 06 '12 at 00:44
  • That's what I meant in my answer when I said "you wouldn't want to send authentication information to a fraudulent server". – Ben Voigt May 06 '12 at 00:45
  • Also, any data you send while logged into the fraudulent server he will have access to, since you negotiated your session key with him. – Ben Voigt May 06 '12 at 00:46
  • 3
    "If you're paranoid, verify the checksum/fingerprint of the key using an alternate channel."

    For the paranoid (and for the record), github's fingerprint is on https://help.github.com/articles/generating-ssh-keys and bitbucket's is mentioned in https://confluence.atlassian.com/display/BITBUCKET/Use+the+SSH+protocol+with+Bitbucket#UsetheSSHprotocolwithBitbucket-KnownhostorBitbucket%27spublickeyfingerprints

     – Sundar R Oct 07 '13 at 09:52
  • @sundar: But watch out for my accompanying note -- does an https session established through the same network count as an independent channel? I don't think so. – Ben Voigt Oct 07 '13 at 13:59
  • 3
    @BenVoigt Yeah, I understand that, the truly paranoid would of course get to those pages through a different unrelated network, or maybe fly to github headquarters and get the fingerprint in person :) – Sundar R Oct 07 '13 at 15:17
47

Let us say you meet someone to exchange some business secrets. Your advisor tells you that you have never meet that person before, and that it can be an impostor. Furthermore, for the next meetings with him, your advisor is not going to warn you anymore. That is what the message means. The person is the remote server, and your advisor is the ssh client.

I don't think it is paranoid to double-check the identity of the person before sharing secrets with her. For instance you could open a web page with a picture of her and compare it with the face in front of you. Or check her identity card.

For the bitbucket server, you could use a different, more trusted computer and get the picture of its face from it, and then compare it with the one you get in the computer you are using now. Use:

 ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

If the faces match, you can add the key to the file e.g. ~/.ssh/known_hosts (standard location in many Linux distributions) with:

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

and the ssh client will not warn you as it already knows her face. It will compare the faces anytime you connect. That is very important. In the case of an impostor (e.g. a man-in-the-middle attack), the ssh client will reject the connection because the face will have changed.

Ivan Ogai
  • 686
  • 2
    This answer is very helpful – 101010 Jan 21 '17 at 03:32
  • 9
    This should be the accepted answer:

    ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

    Thanks Ivan!

     – Rod May 28 '17 at 20:59
  • 2
    @Rod: You'd choose the accepted answer based on a command which is both totally unnecessary (you can modify known_hosts by just typing "yes" to the original warning, as already shown in the question) and dangerous (the key you added to your file isn't necessarily the same one you looked at, because you fetched it twice!)? – Ben Voigt Nov 06 '17 at 00:30
  • @BenVoigt what this solution provides that typing "yes" does not is that this solution is fully scriptable. I assume most people can figure out how to respond to the "(yes/no)?" prompt. I came across this Q&A while trying to figure out how to solve this problem without human intervention (for a server set-up script). In my excitement I guess I didn't notice that the OP's question is a little different than mine, but IMO this is still the most useful/non-obvious answer in the thread. – Rod Feb 22 '18 at 04:23
  • 1
    @Rod: No, it's not useful. Lowering your security is bad. Finding faster ways of lowering your security is the exact opposite of useful. – Ben Voigt Feb 22 '18 at 04:40
  • @BenVoigt Adding the known valid key of a host you need to ssh to or scp from isn't lowering security, and frankly this version isn't "faster" then accepting the "yes" prompt when doing it manually.

    TBH, assuming there is some legitimate need to ssh/scp to another server, I'm not sure what alternative you are proposing. "Don't do that" is a nonsensical answer in this case.

     – Rod Feb 22 '18 at 16:47
  • @Rod: If you're going to script certificate pinning, put the actual known-correct public key in the script (for example as a here-doc). Don't automate the process of fetching it insecurely. The output of ssh-keyscan -H is not a "known valid key". – Ben Voigt Feb 22 '18 at 17:11
7

There is another easy way Simply touch a config file under /root/.ssh and add the parameter

StrictHostKeyChecking no

Next time when you login to a server, they RSA key will be added to known_hosts and won't ask for "yes" for authenticity confirmation

Chris Long
  • 115
  • 6
Usman
  • 79
  • 1
  • 1
  • 4
    This is not recommended. It is easy but not the correct way to deal with the situation. – Vikas Jun 22 '17 at 15:38
5

I simply had to create the known_hosts text file in ~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

After doing this, it added the host and I never saw the message again.

Cfinley
  • 1,435
Brian
  • 83
  • I don't think that really changes anything. The warning is shown when the server itself has changed. For example if you provision a new virtual machine that you're connecting to for the first time. Whether or not you have a known_hosts file (with the correct permissions) doesn't stop it from asking you about the authenticity of the new server... Unless you have somehow already fetched the pub key signature for this server and put it into your known_hosts, which is the one normal way to skip the check (though just saying "yes" to the check is often faster to achieve the same) – Steven Lu Jul 16 '14 at 17:54
  • Thanks. I had known_hosts, but kept getting the warning. I just had to change the permissions on known_hosts for the warnings to stop. – ArcaneDominion Feb 24 '16 at 13:08
  • 8
    Please don't do this. Can be a serious security hazard. Your host file should only be writable by you. The second command is basically allowing anybody in your computer to spoof server identities. – Stolz Mar 07 '17 at 01:57
  • "The warning is shown when the server itself has changed."

    Or when the server has never been visited before.

     – Rod Feb 22 '18 at 04:25
  • I can confirm that in Kubuntu 20.04 this solved my issue. Creating the known_hosts not only removed the message but also allowed me to create a network location in Dolphin which I was unable to do previously due to another error. Thank you – Lewis Morris Feb 19 '21 at 19:43
  • 3
    This second command is very dangerous and should not be used! – Vincent Dec 07 '21 at 03:46
2

This message is just SSH telling you that it's never seen this particular host key before, so it isn't able to truly verify that you're connecting to the host you think you are. When you say "Yes" it puts the ssh key into your known_hosts file, and then on subsequent connections will compare the key it gets from the host to the one in the known_hosts file.

There was a related article on stack overflow showing how to disable this warning, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established.

Community
  • 1
Mike
  • 66
  • 12
    But disabling the warning is not recommended - it is there for a purpose, providing very useful security information. – Rory Alsop May 06 '12 at 07:50
1

Apart from the answers already given (you never connected to this host before), there is also the distinct possibility that you never connected FROM the current host before (to that host); this is only psychologically different; you think you are connecting from host A (to B), while really you are trying to connect from host X (to B). This can for example happen when you first ssh-ed from A to X and then from the same terminal try to ssh to B thinking you're still on A.

Carlo Wood
  • 131
  • 1
    I wonder if using ssh agent forwarding can also suppress the warning if host A knows about B but X doesn't, but the agent forwarding takes place between A and X. Most environments (which provide ssh) and terminal apps support agent forwarding, it helps cut down on the number of ssh keys you have to manage to just your end-devices. – Steven Lu Nov 05 '17 at 18:36
0

In my case password less login was not working because of my home directory permissions because I changed the default settings. Finally, here is what worked for me. my home directory permissions are

/home/username 

drwxr----x. 18 username     groupname  4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------   2 username groupname     29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys
drmaa
  • 189