Force ssh to not print “Remote host identification has changed” warning

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












21















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



"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",
"@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @r",
"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",


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










share|improve this question




























    21















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



    "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",
    "@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @r",
    "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",


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










    share|improve this question


























      21












      21








      21


      3






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



      "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",
      "@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @r",
      "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",


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










      share|improve this question
















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



      "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",
      "@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @r",
      "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@r",


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







      ssh






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 30 at 16:41









      Pro Backup

      2,07863258




      2,07863258










      asked Jan 23 '14 at 8:59









      coffeMugcoffeMug

      7,288112948




      7,288112948




















          5 Answers
          5






          active

          oldest

          votes


















          13














          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.






          share|improve this answer

























          • 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


















          22














          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.





          share|improve this answer




















          • 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


















          19














          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.






          share|improve this answer




















          • 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


















          9














          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





          share|improve this answer






























            2














            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.






            share|improve this answer






















              Your Answer








              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "106"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader:
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              ,
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );













              draft saved

              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f110557%2fforce-ssh-to-not-print-remote-host-identification-has-changed-warning%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown

























              5 Answers
              5






              active

              oldest

              votes








              5 Answers
              5






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              13














              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.






              share|improve this answer

























              • 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















              13














              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.






              share|improve this answer

























              • 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













              13












              13








              13







              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.






              share|improve this answer















              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.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Nov 1 '18 at 16:44









              mklement0

              1449




              1449










              answered Jan 23 '14 at 9:12









              Jenny DJenny D

              10.6k22746




              10.6k22746












              • 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

















              • 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
















              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





              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





              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





              This still prints a warning for me (although it does allow the connection).

              – Michael Mior
              Nov 26 '18 at 14:49













              22














              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.





              share|improve this answer




















              • 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















              22














              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.





              share|improve this answer




















              • 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













              22












              22








              22







              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.





              share|improve this answer















              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.






              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Dec 15 '17 at 21:36

























              answered May 18 '17 at 22:35









              Elijah LynnElijah Lynn

              437311




              437311







              • 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












              • 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







              4




              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





              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






              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




              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





              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





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











              19














              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.






              share|improve this answer




















              • 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















              19














              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.






              share|improve this answer




















              • 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













              19












              19








              19







              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.






              share|improve this answer















              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.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Jan 23 '14 at 9:52

























              answered Jan 23 '14 at 9:03









              TimoTimo

              4,7501826




              4,7501826







              • 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












              • 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







              1




              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






              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





              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





              Not really, will give it a try. ;-)

              – coffeMug
              Jan 23 '14 at 9:15




              1




              1





              @coffeMug I tried this out, but you also have to add -q.

              – Timo
              Jan 23 '14 at 9:50





              @coffeMug I tried this out, but you also have to add -q.

              – Timo
              Jan 23 '14 at 9:50











              9














              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





              share|improve this answer



























                9














                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





                share|improve this answer

























                  9












                  9








                  9







                  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





                  share|improve this answer













                  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






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jun 4 '15 at 23:10









                  Clever GuyClever Guy

                  9112




                  9112





















                      2














                      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.






                      share|improve this answer



























                        2














                        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.






                        share|improve this answer

























                          2












                          2








                          2







                          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.






                          share|improve this answer













                          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.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Dec 15 '17 at 21:42









                          Dr. Edward MorbiusDr. Edward Morbius

                          1212




                          1212



























                              draft saved

                              draft discarded
















































                              Thanks for contributing an answer to Unix & Linux Stack Exchange!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid


                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.

                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f110557%2fforce-ssh-to-not-print-remote-host-identification-has-changed-warning%23new-answer', 'question_page');

                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown






                              Popular posts from this blog

                              How to check contact read email or not when send email to Individual?

                              Displaying single band from multi-band raster using QGIS

                              How many registers does an x86_64 CPU actually have?