Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to setup passwordless ssh on an Ubuntu server with ssh-copy-id myuser@myserver, but I'm getting the error:

Warning: the ECDSA host key for 'myserver' differs from the key for the IP address '192.168.1.123'

What's causing this, and how do I fix it? I tried deleting the .ssh directory on the remote machine, and running ssh-keygen -R "myserver" locally, but this doesn't resolve the error.

share|improve this question

7 Answers 7

up vote 29 down vote accepted

Remove the cached key for 192.168.1.123 on the local machine:

ssh-keygen -R 192.168.1.123
share|improve this answer
3  
Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse. –  Chris K Jan 16 at 7:29
    
/home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work –  Wolfgang Fahl Jul 25 at 6:55

(OK, to Mark0978 point, I have edited this to try to better answer the question)

Question: What's causing this, ... ?

So the ssh server host key changed. What caused the change? It is hard to say. Here are some guesses:

  • Did sshd on myserver start using ECDSA keys, so it is a new key type?
  • Was myserver recently re-installed?
  • Was sshd on myserver recently re-insalled so a new ssh host key was generated?
  • Did someone re-generate or replace the sshd host key?
  • Has the IP address of myserver changed so that a different host is answering to that IP address?

Question: ... and how do I fix it?

As others have already answered, remove the cached ECDSA host key for myserver that your account has cached.

share|improve this answer
    
Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question. –  Mark0978 Apr 3 '13 at 14:18

I do lots of ssh-ing around between my LAN computers and my two webhosting accounts, so I've sorted out all kinds of odds and ends with SSH, including authentication problems using ssh -v to see where and what went wrong.

Having just resolved this issue and not being happy with the answers, I wanted to really know "why" myself...

The trigger for my case is: installed new server OS at work and upon installing openssh-server package, a new set of host keys were generated on work's server. Previously, all of my server OSs were Ubuntu and this time it changed to Debian (and I suspect there is a nuanced difference in permissions).

When all OSs were Ubuntu and I reinstall a server's OS, upon the first SSH in to it, I get this kind of warning, which I prefer over the silent warning above!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Then I open up ~/.ssh/known_hosts on the computer initiating the ssh, delete that line, reconnect and this happens:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

That bit about :11122 is the port number I route SSH from on the firewall

I checked backups from a former Ubuntu server and diff'd against my new Debian install:

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

So yes, likely, the host started using ecdsa keys recently, which based upon Ubuntu's changes lately, I would blame on an update. Ubuntu's shift away from the rock-solid linux OS I counted on is why I installed Debian this time around.

I read a security.SE q/a on ecdsa and have already removed that line from sshd_config my new Debian server. (and ran service ssh restart)

share|improve this answer
    
+1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means? –  bgoodr Feb 9 at 16:43
    
@bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean. –  Chris K Feb 10 at 7:00

The prompt occurs every time because the IP addresses change all the time when using dynamic addressing. Try to use static IP so you only have to add the key only once.

share|improve this answer
    
Good point, did I miss where someone mentioned dynamic ips? –  Chris K Jan 16 at 20:13

The thread here may help.

Essentially, you want to remove both the RSA and ECDSA keys for that host, then use ssh-keyscan to put them back into your known_hosts file in a way that won't cause this conflict. It worked for me when I had the same issue.

share|improve this answer

In my case ssh-keygen -R ... didn't fix the warning. I had extra information like this:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

I simply manually edited ~/.ssh/known_hosts and deleted line 8 (the "offending key"). I tried reconnecting, the host was permanently added, and everything was fine after that!

share|improve this answer

Are You using the same user for connecting?

If You are logged in local PC like user John and connecting to the server B like user Adolf@B and everything is OK, it does not mean, that everything is OK if You are logged to local PC like user Jane and connecting to the server B like user Adolf@B!

(I have the same problem now:)

-------------------------------- add ------------------------------------------

If You want login on server B as user Beda from PC A without password. Try this commands, all from PC A:

ssh-keygen -t rsa

This command generates the key and store the key to the file. Pleas, leave empty passphrase.

ssh Beda@B mkdir -p .ssh

This command create the directory, if they do not already exist. If existing, do not print error message.

cd ~/.ssh

This command change directory to Your users home directory ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

This command is printing file id_rsa.pub (Your public key) into authorized_keys on the server. IMPORTANT: Beda is Your username on the server which You are connecting, B is Your server IP.

Now, You can connect on the server B withou password or passphrase:

ssh Beda@B

Have a nice time with.

Petr

share|improve this answer

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.