Is there a way to avoid ssh printing warning messages like this?


Although the remote host identity has changed but I know it is fine and just want to get rid of this warning.


Four ways:

To just connect once to a system with a new host key, without having to answer questions, connect with the following option:

ssh -q -o "StrictHostKeyChecking no" this.one.host.name

To permanently remove the warning for all systems, edit your ~/.ssh/config file to add the following lines:

Host *
StrictHostKeyChecking no

To permanently remove all warnings for this one server, edit your ~/.ssh/config file and add the following lines:

Host this.one.hostname
StrictHostKeyChecking no  

To remove the warning for this one change for this one server, remove the host key for that server from ~/.ssh/known_hosts. The next time you connect, the new host key will be added.

  • In the second option that configuration must be done in the server side which we are connecting to right? – coffeMug Jan 23 '14 at 9:19
  • No, it's your own $HOME/.ssh/config that matters in both the second and third option. – Jenny D Jan 23 '14 at 9:43
  • This still prints a warning for me (although it does allow the connection). – Michael Mior Nov 26 '18 at 14:49

Add this to your ~/.ssh/config:

Host 10.*                            # use your own pattern here, eg. *.example.com, example.*.com
  StrictHostKeyChecking   no         # turn off the HostKey check                                                               
  LogLevel                ERROR      # keep it from printing to STDOUT
  UserKnownHostsFile      /dev/null  # (optional) add the host automatically to a black hole, otherwise it would be added to ~/.ssh/known_hosts and show you a warning/message at the top of your session. You may want it added to known_hosts if your shell uses `ssh` autocompletion, such as fish. 
  • 4
    It's probably better to set LogLevel to ERROR, so that you can see if there are any problems when connecting. – Strahinja Kustudic Jul 14 '17 at 15:34
  • Thanks you @StrahinjaKustudic. Just tested that and it worked. I updated the answer. For some reason I thought I tested that initially but guess I didn't, great improvement! – Elijah Lynn Jul 14 '17 at 18:57
  • 3
    MOD UP - only one that actually answered the question - this was the only answer to not just work, but SUPPRESS the WARNINGS. – Brad Jul 21 '17 at 18:56
  • Whoops, it appears users of fish shell won't be able to use the nice ssh autocompletion for previously connected hosts if they put UserKnownHostFile to /dev/null. Fish users and possibly everyone should not set that. – Elijah Lynn Dec 13 '17 at 17:48
  • You better make a ssh0 script/alias/function for ssh -o UserKnowHostsFile=/dev/null -o LogLevel=ERROR and use that expressly instead of dumping those options into ~/.ssh/config. You may forget about them and then wonder why the checks didn't work when you just wanted them to work. – Uncle Billy Jan 30 at 20:02

You can take the line for that host out of ~/.ssh/known_host (every host has a line as entry there).

Alternative is to use:

ssh -q -o "StrictHostKeyChecking no" ....

Just using -q would have ssh silently fail.

  • 1
    Yes I know that, but is there a command line option to skip printing this kind of warnings? I tried ssh -o StrictHostKeyChecking=no but the warning is there again. – coffeMug Jan 23 '14 at 9:04
  • Have you trieds ssh -o "StrictHostKeyChecking no" ... that is the format the man page indicates. – Timo Jan 23 '14 at 9:08
  • Not really, will give it a try. ;-) – coffeMug Jan 23 '14 at 9:15
  • 1
    @coffeMug I tried this out, but you also have to add -q. – Timo Jan 23 '14 at 9:50

Not adding host keys to the default $HOME/.ssh/known_hosts is sometimes desirable.

Use -o UserKnownHostsFile=/dev/null in addition to -q and -o StrictHostKeyChecking=no to keep known_hosts uncluttered. Here is an example:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -q user@scripts.local

An alternative suggestion is to identify why the host key is changing, and get it to stop doing that.

As an example: if you're building hosts in containers or through a provisioning system, ensure that these consistently use the same known host key per instance.

I'm well aware this isn't always possible, and hosts may be managed outside your scope of control, but those hostkey warnings are there for a reason and are significant. Reducing the exception count is a Good Thing.

Otherwise, I vote for StrictHostKeyChecking No in your ~/.ssh/config for the specific host in question only.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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