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

I have a server (lets assume its ip be a.b.c.d) which allows users to login via ssh. Now I want to change the physical machine keeping the ip same. So that the new machine is still accessed by a user like this

$ssh a.b.c.d

Problem is, every time one user tries to login, she gets the following ssh-key mismatch error.

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
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:37
RSA host key for alumni has changed and you have requested strict checking.
Host key verification failed.

I know that user can delete line # 37 from the file ~/.ssh/known_hosts and next time she would get a yes/no prompt. What I want is that user should be kept unaware of this whole machine replacement thing and just get a prompt for password.

How to do that?

share|improve this question
Are you aware that this would defeat ssh's only protection against man in the middle attacks and could result in you sending your password right to the attacker instead of the intended machine? Unless you know for a fact that you are invulnerable to active attacks (for example, you are on the same secure internal network as the target machine) this destroys ssh's security model. – David Schwartz Jan 10 '13 at 15:25
Yes. Both the machines are in the same internal networks. Even the users are inside the same internal network. Given this situation, what are my options? – Souvik Pal Jan 10 '13 at 16:07
That's not enough. They have to be in the same secure internal network. That is, they must absolutely, 100% trust that no device is connected to that internal network that is not 100% secure, and they must 100% trust everyone who has control over those devices or can attach a device to that network. In other words, in almost any realistic scenario, this is a bad idea. – David Schwartz Jan 10 '13 at 16:53
It's a perfectly reasonable thing to do. I'm replicating the ssh server keys to another server for HA so that when I login I'm getting those errors. Besides I get emailed on failover. – Matt H Dec 12 '13 at 2:35
I agree with Matt. If you're in control of both machines and therefore the owner of the keys, moving the host key from one machine to another within your control IS NOT a man in the middle attack or risk. If the connecting user trusts your host key, it shouldn't matter. – Ross Mar 9 '15 at 13:16
up vote 5 down vote accepted

As Ethabell mentioned, you can copy over the current host keys to the new server.

You can find your host keys by opening your sshd_config file (On my Ubuntu 12.04 box its /etc/ssh/sshd_config). In the config file look for the HostKey entries. These entries will tell you where the host key files are located. You should be able to copy these files to the new server and update the new server's sshd_config to point to the copied keys (or just overwrite the files that already exist on the new server).

Also, note this section from the sshd_config man page, specifically the part about permissions:

Specifies a file containing a private host key used by SSH. The default is /etc/ssh/ssh_host_key for protocol version 1, and /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key and /etc/ssh/ssh_host_rsa_key for protocol version 2. Note that sshd(8) will refuse to use a file if it is group/world-accessible. It is possible to have multiple host key files. “rsa1” keys are used for version 1 and “dsa”, “ecdsa” or “rsa” are used for version 2 of the SSH protocol.

share|improve this answer
Thank you all, this seems to have solved the issue. – Souvik Pal Jan 10 '13 at 17:00

If you had the original host key you could restore it and this would stop the error.

Or, you could turn off StrictHostKeyChecking in your sshd config file.

... Doing this, however, is an awful, awful idea. If there is a way for you to just run ssh-keygen -R on client machines, that would be the best way -- because turning off host key checking is like saying, "Hey. Attack me." I get wanting obscurity when things change, but security should be priority #1 over obscuring changes.

share|improve this answer
Can you elaborate on how to restore host keys on newer machine? – Souvik Pal Jan 10 '13 at 16:09

You can try it like this

cat ~/.ssh/ | ssh <user>@<hostname> 'cat >> .ssh/authorized_keys && echo "Key copied"' 

Note that if the folder .ssh does not already exist, the above command will fail. In addition, it might be better when creating the file to set a minimum possible permission (basically read-write for owner only). Here is a more advanced command:

cat ~/.ssh/ | ssh <user>@<hostname> 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys && echo "Key copied"'

For more light on this problem you have to get to this website : SSH Host Key Change Error

share|improve this answer

You must log in to answer this question.

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