87

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")

alexus
  • 12,342
  • 27
  • 115
  • 173
  • Why is this expected behavior? – Thorbjørn Ravn Andersen Apr 14 '14 at 21:23
  • 16
    I can't speak for the user, but one example would be a situation where you are developing a automated install process (such as a kickstart), where your iterative workflow involves building, connecting, testing, modifying the build process, and rebuilding from scratch over and over again. – Goladus Apr 17 '15 at 20:30
  • 19
    @MichaelHampton - I get this all the time as VMware and VirtualBox recycles IP addresses for guests. For me, it is the correct question :) –  Jul 31 '15 at 09:26
  • 1
    FWIW I keep searching for this answer because I have a system in my LAN where I use a dropbear (with a different host key) to enter the disk encryption password during startup. – Zulan Nov 22 '15 at 17:33
  • 1
    @jww This is the wrong question/solution for your scenario. Instead you should be configuring SSH to ignore the IP address but still check the host key. See for example [here](https://serverfault.com/questions/193631/ssh-into-a-box-with-a-frequently-changed-ip) – Jon Bentley Mar 05 '19 at 13:36
  • @Goladus Ideally your install process should insert a pre-created host key that doesn't change. I'm not familiar with kickstart, but this is trivially achieved in Vagrant, for example (where you create/destroy instances from a base machine that never changes) – Jon Bentley Mar 05 '19 at 13:38
  • 1
    @JonBentley That requires the extra step of pre-creating a host key which may not be what the user wants for their particular scenario. Of course the real point is that it's a simple question with a simple answer, the asker shouldn't be required to explain in detail why this is the best solution in his situation, even if it does seem odd and you want to suggest potentially superior solutions. I just speculated one potential scenario to make the point. – Goladus May 24 '19 at 02:53
  • 1
    @Goladus Of course, I completely agree - there is nothing more annoying that a "why would you want to do that?" comment when legitimate reasons exist and the commenter just hasn't used their imagination. My comment was only meant to elaborate on your example, not to disagree with the overall point. Hence I upvoted your comment when I replied to it. I commonly want the OP's scenario where I am connecting to host that will only exist temporarily and I don't want to litter my known hosts file with pointless entries. – Jon Bentley May 24 '19 at 13:05
  • Excellent writeup here!: https://www.shellhacks.com/disable-ssh-host-key-checking/ – Gabriel Staples Nov 01 '19 at 16:23

7 Answers7

100

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
  • that is expected behavior) so it's normal (in my case) – alexus Dec 07 '13 at 20:22
  • 1
    @alexus If it's "expected", then you can apply the option to a specific hostname/IP for which you expect it to happen. – chrylis -cautiouslyoptimistic- Dec 07 '13 at 20:25
  • 2
    @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 07 '13 at 20:44
  • 1
    This no longer works (at least for OpenSSH_5.3p1) – draeath Jan 12 '17 at 16:36
  • `-o StrictHostKeyChecking=no` removes the ability to log in with a password. Doesn't the lack of a flag for this go directly against unix principles of allowing the user to force behavior? I'm currently trying to login to a local machine with a local IP. The host key changed because I reformatted said machine. Everything here makes sense and nothing is a security risk under the circumstances. – Wowfunhappy Sep 26 '19 at 23:28
64

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.

MattB
  • 756
  • 7
  • 5
  • 3
    This can be a better answer than the currently [highest upvoted one](http://serverfault.com/a/559886/34399) because it allows to use password authentication which would be disabled otherwise (of course, you should understand what exactly you are doing before typing in your password...) – VZ. Apr 08 '15 at 21:55
  • 1
    I'm a little confused here: shouldn't you *also* use `-o StrictHostKeyChecking=no` *in addition to* the `-o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null` options?--for a final answer of: `ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host`? – Gabriel Staples Nov 01 '19 at 16:28
  • Related writeup I found online: https://www.shellhacks.com/disable-ssh-host-key-checking/ – Gabriel Staples Nov 01 '19 at 16:31
  • `-o UserKnownHostsFile=/dev/null` (in combination with `StrictHostKeyChecking=no`) allowed me to silence `WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED` which was happening when the host was being powered off and on again (and in this case regenerating keys). Thanks! – fabiomaia Sep 17 '20 at 08:55
5

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.

etagenklo
  • 5,694
  • 1
  • 25
  • 31
4

Some people say its not right, you don't shold do this and so on, but i need this also to test couple of embedded devices over and over again. You need to disable StrictHostKeyChecking=no, this is right, but also reset known hosts file to /dev/null. Here an exemple with autologin and ps on remote device.

sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host 'ps ax'
eddso
  • 41
  • 1
3

-o StrictHostKeyChecking=no only works if host isn't already present in known_hosts file.

I think it is cleaner (no warnings), if you expect hosts key to change maybe due to vm cloning, to enforce ignoring of those kind of hosts like this:

# Handle possible SSH key changes
host_key=$(ssh-keyscan -t rsa ${host_ip})
grep "${host_key}" ~/.ssh/known_hosts >/dev/null || {
    ssh-keygen -R ${host_ip}
    echo ${host_key} >>  ~/.ssh/known_hosts
}

# connect as normal way
ssh root@${host_ip} "hostname"
Jose Sa
  • 31
  • 1
-1

My alias:

ssh='ssh -q -o StrictHostKeyChecking=no -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null'
Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
user609483
  • 11
  • 6
    You should never ignore such messages 100% of the time. Doing so exposes you to MITM attacks. – Michael Hampton Dec 31 '20 at 20:23
  • 1
    In addition to what Michael said: while you might live in a danger with it, you better never recommend this wrong approach to anybody else, at least without BIG RED DISCLAIMER this is very insecure and dangerous. – Nikita Kipriyanov Jan 16 '21 at 15:34
  • if you are going to do this, i don't recommend you call your alias just ssh – mekb May 02 '22 at 08:58
-3

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.

Niels
  • 3
  • 4