Force ssh to not print “Remote host identification has changed” warning
Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
add a comment |
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
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
ssh
edited Jan 30 at 16:41
Pro Backup
2,07863258
2,07863258
asked Jan 23 '14 at 8:59
coffeMugcoffeMug
7,288112948
7,288112948
add a comment |
add a comment |
5 Answers
5
active
oldest
votes
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 a comment |
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 setLogLevel
toERROR
, 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 assh0
script/alias/function forssh -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
add a comment |
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 triedssh -o StrictHostKeyChecking=no
but the warning is there again.
– coffeMug
Jan 23 '14 at 9:04
Have you triedsssh -o "StrictHostKeyChecking no" ...
that is the format theman
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
add a comment |
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
add a comment |
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.
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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 a comment |
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 a comment |
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.
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.
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
add a comment |
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
add a comment |
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 setLogLevel
toERROR
, 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 assh0
script/alias/function forssh -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
add a comment |
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 setLogLevel
toERROR
, 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 assh0
script/alias/function forssh -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
add a comment |
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.
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.
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 setLogLevel
toERROR
, 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 assh0
script/alias/function forssh -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
add a comment |
4
It's probably better to setLogLevel
toERROR
, 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 assh0
script/alias/function forssh -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
add a comment |
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 triedssh -o StrictHostKeyChecking=no
but the warning is there again.
– coffeMug
Jan 23 '14 at 9:04
Have you triedsssh -o "StrictHostKeyChecking no" ...
that is the format theman
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
add a comment |
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 triedssh -o StrictHostKeyChecking=no
but the warning is there again.
– coffeMug
Jan 23 '14 at 9:04
Have you triedsssh -o "StrictHostKeyChecking no" ...
that is the format theman
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
add a comment |
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.
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.
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 triedssh -o StrictHostKeyChecking=no
but the warning is there again.
– coffeMug
Jan 23 '14 at 9:04
Have you triedsssh -o "StrictHostKeyChecking no" ...
that is the format theman
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
add a comment |
1
Yes I know that, but is there a command line option to skip printing this kind of warnings? I triedssh -o StrictHostKeyChecking=no
but the warning is there again.
– coffeMug
Jan 23 '14 at 9:04
Have you triedsssh -o "StrictHostKeyChecking no" ...
that is the format theman
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
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Jun 4 '15 at 23:10
Clever GuyClever Guy
9112
9112
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Dec 15 '17 at 21:42
Dr. Edward MorbiusDr. Edward Morbius
1212
1212
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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