Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

when I upgraded my KVM virtual machine manager to the latest version I got a question prompt every time I try to connect remotely to my machines:

The authenticity of host 'kvm.local (ip address)' can't be established.
ECDSA key fingerprint is b5:fa:0a:d0:39:af:0a:60:fa:04:87:6c:31:1d:13:15.
Are you sure you want to continue connecting (yes/no)? 

And when changing any setting on a VM I was obliged to type yes and then type the root password in another dialog

using ubuntu 12.04 64bit

share|improve this question
1  
Is KVM booting a CD or an installed operating system on an image file? What is the IP address of the guest and how is it being determined (did you define it or does DHCP hand out a static address or is it dynamic)? Do you see it changing in the above message each time? How is the guest networking set up? –  John S Gruber Sep 20 '12 at 14:42
    
1. KVM is booting an image file the IP address of the guest is 192.168.x.x . there is no DHCP. Everything is static. the guest networking is setup in a bridged interface named br0 and all machines use the same bridge with different MAC addresses and IPs –  user91632 Sep 20 '12 at 14:48
add comment

2 Answers 2

up vote 0 down vote accepted

My problem is solved. But I didn't have time to mention it. After removing my ~/.ssh/known_hosts from the client and re-initializing the connection it asked me for the fingerprint only one time.

Then after rebooting the client it never asked me for the fingerprint again. Thanks for the hint @John S Gruber

share|improve this answer
add comment

I can think of several ways that this message can be produced repeatedly:

  1. You have turned off the StrictHostKeyChecking option in ssh on the client and the guest has been reinstalled, or has reinstalled its ssh server. When an ssh server package is installed it generates a new fingerprint and installs it in /etc/ssh. Note that newer versions off ssh hash the hostnames/addresses.

  2. If you were connecting to a new guest (at a new IP or name), or an old guest but at a new IP or name. While Kamil is using a bridged network, this problem can occur when default networking is used as the ssh command for various guests is directed to the host computer. The same is true for guests behind a NAT firewall where the source of the ssh is on the other side of the firewall. The solution is to use the hostkeyalias function of the client's ssh configuration files.

  3. Something is deleting or modifying your ~/.ssh/known_hosts file in the account from which you are initiating ssh.

So either the guest fingerprints are changing or there is a change in the mapping of guest->name->IP address, or the account you are ssh'ing from is forgetting their fingerprints.

  1. If you connect to the same guest twice in a row seconds apart and the The authenticity of host 'samename.local (same ip adress)' can't be established. ECDSA key fingerprint is xx:yy: ... message changes the fingerprint, and you can confirm that you reached the same guest by examining its contents (not by MAC address), you know the guest is changing its fingerprint. You should be able to confirm this by examining the times is ls -l of the guests /etc/ssh directory. If you were rebooting in between, and if it were from a CD (it's not) or an installation USB key or installation USB key image this would be understandable. You don't mention having to reboot these guests to get the error, either. So this possibility seems improbable.

  2. If you can see that entering the same ssh command gets you to a new guest by examining the contents of the guest you know you have a problem in name->ip->guest mapping. There's lots to go wrong here.

  3. If you see the same actual fingerprint over and over and see that the IP and name of the guest haven't changed you have a problem with your ssh client machine erasing all or part of the .ssh/known_host file. You can confirm that with the times in ls -l ~/.ssh/known_host. This seems improbable to me.

If you haven't disabled StrictHostKeyChecking on the ssh client it may help narrow this down, as well. That option, normally the default, will cause ssh to fail to connect if it goes to the same guest-guestname-guestip and the fingerprint has changed. I see that isn't the trouble you are having, which is confusing if you are connecting to the same place over and over.

The time I see this is when I ssh into my guests and they have been assigned new IP addresses or when I ssh into them from a different account. (Each account has its own known_hosts file--they are not computer-wide).

share|improve this answer
    
the ECDSA key fingerprint is always the same, never changed. I have deleted the ~/.ssh/known_host from the ssh client machine. Nothing changed. I saw the StrictHostKeyChecking disabled in the ssh server machine (kvm.local). the server ip address hasn't changed definitely. the server name hasn't changed. but maybe the mac address changed. thanks in advance. still I am stick with the problem –  user91632 Sep 21 '12 at 9:50
1  
So the target (guest) computer's fingerprint is always the same, and its name and IP address are always the same. That leaves possibility 3. Please enter ssh-keygen -lf ~/.ssh/known_hosts on your client. Since you just removed it it should only contain the finger print from the last connection. Then make another connection to the guest and after you do say to add the same key over again, then use ssh-keygen -lf ~/.ssh/known_hosts again and please post the results (the hostname is hashed and the fingerprint is from a public key). How is StrictHostKeyChecking set on the client? –  John S Gruber Sep 21 '12 at 14:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.