Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 ' (' 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 ',' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':
share|improve this question
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 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 6 '12 at 0:13
up vote 33 down vote accepted

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.

share|improve this answer
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 6 '12 at 0:38
@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 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 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 6 '12 at 0: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 6 '12 at 0:45
"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 and bitbucket's is mentioned in… – sundar Oct 7 '13 at 9:52
@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 Oct 7 '13 at 15:17

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.

share|improve this answer
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. – Jim Feb 24 at 13:08

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,

share|improve this answer
But disabling the warning is not recommended - it is there for a purpose, providing very useful security information. – Rory Alsop May 6 '12 at 7:50

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

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .