Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Is there a way to temporarily ignore my ~/.ssh/known_hostsfile?

mbp:~ alexus$ ssh 10.52.11.171
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in /Users/alexus/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/alexus/.ssh/known_hosts:155
RSA host key for 10.52.11.171 has changed and you have requested strict checking.
Host key verification failed.
mbp:~ alexus$ 

NOTE:

.. by a few answer(s)/comment(s) i realize that my question is a bit misleading, so short it is expected behavior), so it's normal (in my case) there is a valid reason behind it on why I want to see "ignore it")

share|improve this question
7  
You're asking the wrong question. You should not "ignore" the problem; you should figure out what is going on and solve it. –  Michael Hampton Dec 7 '13 at 20:07
    
Why is this expected behavior? –  Thorbjørn Ravn Andersen Apr 14 at 21:23

4 Answers 4

up vote 7 down vote accepted

You can use ssh -o StrictHostKeyChecking=no to turn off checking known_hosts momentarily. But I'd advise against this. You should really check why the host key has changed.

Another option is to add a specific entry to your ~/.ssh/config for the host in question. This might be valid approach if you have a certain host which generates new host keys every time it reboots and it gets rebooted for a valid reason several times a day.

Host <your problematic host>
  StrictHostKeyChecking no
share|improve this answer
    
that is expected behavior) so it's normal (in my case) –  alexus Dec 7 '13 at 20:22
    
@alexus If it's "expected", then you can apply the option to a specific hostname/IP for which you expect it to happen. –  chrylis Dec 7 '13 at 20:25
    
@alexus And remember that if you do this, you pretty much lose all the protection that ssh provides. You may as well be using telnet, as it would be trivial for someone to MITM you and capture all your traffic. –  Michael Hampton Dec 7 '13 at 20:44
1  
Single letter spelling error: advice is a noun; you want the verb form, advise. –  TRiG Feb 4 at 11:04

If you have reinstalled the server and therefore the Identification has changed, you should just delete the specified line 155 from /Users/alexus/.ssh/known_hosts and go ahead.

If you switch between different private networks, you should use hostnames to connect instead, as the ssh client will also save keys depending on the hostname. Add something like this to your /etc/hosts:

10.52.11.171 server1
10.52.11.171 server2

and then use ssh server1 when connected to subnet 1 and ssh server2 when connected to subnet2. This way, both servers can have different hostkeys.

share|improve this answer
    
What if you switch between two private networks and connect to two same IP? –  alexus Dec 7 '13 at 22:51
    
I've edited my answer. –  etagenklo Dec 7 '13 at 23:05
1  
@alexus Then you need IPv6 :) But that would have been useful information in your original question. –  Michael Hampton Dec 7 '13 at 23:06

To completely ignore your known hosts file in a POSIX environment, set the GlobalKnownHostsFile and UserKnownHostsFile options to /dev/null:

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null user@host

Setting the StrictHostKeyChecking=no option will allow you to connect but SSH will still show a warning:

ssh -o StrictHostKeyChecking=no user@host

As others have noted, it's probably better to address the underlying issue. You could consider SSH certificate authentication to verify hosts, for example.

share|improve this answer

Log in to all of your servers, (and if RedHat) rm -f /etc/ssh/ssh_host_* and then restart SSHD.

This will create new SSH host keys that do not need to be ignored.

I can think of only one instance where SSH keys cloned on multiple servers is not only desired but also does not throw any warnings. Multiples of one A record. All hosts with the A record have the same key.

share|improve this answer
1  
This answer is incorrect. The fingerprint is local on the client. –  tristan Apr 14 at 21:35

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.