I would like to disable strict host key checking in ssh
for Ubuntu 11.04. How to do it?

- 39,982

- 81,947
7 Answers
In your ~/.ssh/config
(if this file doesn't exist, just create it):
Host *
StrictHostKeyChecking no
This will turn it off for all hosts you connect to. You can replace the *
with a hostname pattern if you only want it to apply to some hosts.
Make sure the permissions on the file restrict access to yourself only:
sudo chmod 400 ~/.ssh/config

- 36,264
- 56
- 94
- 147

- 15,807
-
7Make one - the entire contents of the file are in my quote above. Note it's in the
.ssh
subdirectory of your homedir as well. – Caesium Dec 14 '11 at 14:44 -
Is the indentation required? My entries look like blocks divided by a empty line. – Andi Giga Jun 20 '17 at 10:04
-
22This is unwise in many cases, often you just want to disable it once:
ssh -o UserKnownHostsFile=/dev/null
– odinho - Velmont Aug 29 '17 at 09:34 -
3mkdir -p ~/.ssh && echo "Host *" > ~/.ssh/config && echo " StrictHostKeyChecking no" >> ~/.ssh/config – Sankarganesh Eswaran Apr 25 '18 at 12:24
-
Awesome, I was stuck in fixing ~/.ssh/known_hosts but it never existed. Luckily I found this thread and can log in now. I'm just wondering how can i log in to other machine but not just one specific type of machine which i launched by shared ami from another aws account. Thanks – Satys May 06 '18 at 12:08
-
1
-
It should be noted that host keys still get added to
~/.ssh/known_hosts
even withStrictHostKeyChecking
set tono
. – x-yuri Sep 13 '21 at 00:46 -
doesn't work, see https://askubuntu.com/questions/1462362/for-ssh-command-line-tool-why-is-stricthostkeychecking-no-not-effective – tribbloid Apr 05 '23 at 05:50
Rather than adding it to your ~/.ssh/config
file for all Host *, it would be a safer to specify a particular host.
You can also pass a parameter on the command-line like this:
ssh -o StrictHostKeyChecking=no yourHardenedHost.com
This will automatically add the host key to your known_hosts file if it's not already there.
If there's a mismatch, it will display a big warning and not update known_hosts. It will also disable password-based authentication to prevent MITM attacks. Private key authentication will still automatically get through though, which you may not want.

- 3,317
- 2
- 22
- 28

- 5,900
-
1Note that you generally only need to do this once per host since it says this the first time:
Warning: Permanently added 'frxxx.blaps.net,10.11.12.13' (RSA) to the list of known hosts.
– MarkHu Jul 24 '13 at 00:49 -
48That won't work. It should be
ssh -o UserKnownHostsFile=/dev/null
instead. – qwertzguy Oct 29 '14 at 02:51 -
5@qwertzguy It does work. Your option will make it so that the host key is lost each time, which is useful and more secure, but not what the question asked for. – Jon Bentley Nov 30 '15 at 00:04
-
@qwertzguy Could you add this as an answer, yours is really the best for quick'n'dirty "just connect I know what I'm doing"? Didn't wanna ninja-steal your answer. – odinho - Velmont Aug 29 '17 at 09:32
-
-
3use both works for me, ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no – netawater Nov 12 '17 at 05:35
-
Fun fact: When using SFTP, using
-o whatever
precludes the use ofuser@host
notation for determining which user to connect as. – Throw Away Account Jan 30 '18 at 02:08 -
I don't use
sftp
much, but it worked same way for me on MacOS, Debian, and FreeBSD when I tried them today. What distro are you using? – MarkHu Jan 31 '18 at 21:24 -
I wish there was a way to add multiple host keys for a single host - if we have multiple fixed hosts behind a load balancer, I know which hosts to expect, but I can't ssh directly to said hosts. For now I do the above to disable strict host checking... – Cinderhaze Nov 15 '19 at 21:09
-
It should be noted that host keys still get added to
~/.ssh/known_hosts
even withStrictHostKeyChecking
set tono
. – x-yuri Sep 13 '21 at 00:51 -
3
It's worth pointing out that setting in your ssh config:
StrictHostKeyChecking no
Will mean hostkeys are still added to .ssh/known_hosts - you just won't be prompted about whether you trust them, but should hosts change I'm willing to bet you'll get the big warning about it. You can work around this problem by adding another parameter:
UserKnownHostsFile /dev/null
This will add all these "newly discovered" hosts to the trash bin. If a host key changes, no troubles.
I would be remiss not to mention that circumventing these warnings on hostkeys has obvious security ramifications - you should be careful that you're doing it for the right reasons & that what you're connecting to actually is what you mean to connect to and not a malicious host, since at this point you've eroded a major part of the security in ssh as a solution.
For example if you were to try and set this with the commandline, the full command would be:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host
That would be silly though - given that the working examples above for ssh config files is likely to make more sense in all cases.

- 2,028
- 1
- 12
- 8
-
1
-
1I think this is the right answer. This works well for connecting to hosts on a private local network. – Steve Davis Jan 14 '15 at 14:39
-
10Could be convenient to have an alias to
ssh -o StrictHostKeyChecking=no -o UserKnownHostFiles=/dev/null user@host
. In my case I useissh
to connect to hosts where I know the host key changes. – RubenLaguna May 02 '16 at 13:53 -
2@ecerulm - just a small typo: it's
UserKnownHostsFile
notUserKnownHostFiles
. – Grey Panther Oct 02 '17 at 10:16 -
like a Gem, finally someone understands the generosity in completion and conclusion – sg28 May 16 '20 at 00:04
-
When you are running this in a script in a Docker container, there is never a known_hosts file. You don't want a prompt because its unattended. The whole file system gets dumped at the end of the docker run. So the security issues don't apply. – Lee Meador May 20 '20 at 00:37
-
3@LeeMeador There isn't a
known_hosts
file in your Docker containers because nobody put one there. Not because there can't be one or never is one. There can be one. You can copy one in at build time, or mount one at docker run time, or fetch one from inside the container using another secure mechanism. If this security issue is important enough to your organization, then you can create a discovery and delivery system in your CI/CD processes to have an updatedknown_hosts
file in your Docker images. – ErikE Jul 13 '20 at 09:50 -
@ErikE Good point. Perhaps I should have said "typically not" instead of "never" but my point was actually that creating the known_hosts file on the fly in a Docker container reduces the security blast radius if the container spins down before too long. Doesn't apply to long lived containers. May or may not apply in k8s if instances are spun up and removed a lot. – Lee Meador Aug 21 '20 at 20:36
-
If you're facing the "REMOTE HOST IDENTIFICATION HAS CHANGED!" warning, you might want to try to ignore it (ssh to the server, e.g. to check if the public key is accepted, or to see what's there). Given that you're using public key authentication (don't send the password), and not using ssh agent forwarding, it should be safe. That's one use case I can think of. But you should assume you're connecting to some other server. – x-yuri Sep 13 '21 at 01:23
FYI. I prefer to disable host checking just when using cssh.
alias cssh='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'
-
1
-
1
-
1
-
2
alias relay='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null 11086695@172.26.19.19 -p 2222'
work for me – arganzheng Jul 25 '18 at 08:12
If you want to disable on a one time basis use:
ssh -o UserKnownHostsFile=/dev/null
That will work also if the host key changes and will make sure not to save the key as trusted for added security.

- 663
From what it sounds like,
NoHostAuthenticationForLocalhost yes
may be good enough, for you. AND you'd still be able to maintain that semblance of security.

- 172,746

- 217
- 2
- 4
https://askubuntu.com/a/87452/129227 suggest to modify the config file which helps. But instead of opening things up for any host I wanted this to be done per host. The script below helps automating the process:
example call
./sshcheck somedomain site1 site2 site3
sshcheck script
#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers
#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'
red='\033[0;31m'
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'
#
# a colored message
# params:
# 1: l_color - the color of the message
# 2: l_msg - the message to display
#
color_msg() {
local l_color="$1"
local l_msg="$2"
echo -e "${l_color}$l_msg${endColor}"
}
#
# error
#
# show an error message and exit
#
# params:
# 1: l_msg - the message to display
error() {
local l_msg="$1"
# use ansi red for error
color_msg $red "Error: $l_msg" 1>&2
exit 1
}
#
# show the usage
#
usage() {
echo "usage: $0 domain sites"
exit 1
}
#
# check the given server
#
checkserver() {
local l_server="$1"
grep $l_server $sconfig > /dev/null
if [ $? -eq 1 ]
then
color_msg $blue "adding $l_server to $sconfig"
today=$(date "+%Y-%m-%d")
echo "# added $today by $0" >> $sconfig
echo "Host $l_server" >> $sconfig
echo " StrictHostKeyChecking no" >> $sconfig
echo " userKnownHostsFile=/dev/null" >> $sconfig
echo "" >> $sconfig
else
color_msg $green "$l_server found in $sconfig"
fi
ssh -q $l_server id > /dev/null
if [ $? -eq 0 ]
then
color_msg $green "$l_server accessible via ssh"
else
color_msg $red "ssh to $l_server failed"
color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
read answer
case $answer in
y|yes) ssh-copy-id $l_server
esac
fi
}
#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
os=`uname`
case $os in
# Mac OS X
Darwin*)
pingoption=" -t1";;
*) ;;
esac
pingresult=$(ping $pingoption -i0.2 -c1 $server)
echo $pingresult | grep 100 > /dev/null
if [ $? -eq 1 ]
then
checkserver $server
checkserver $server.$domain
else
color_msg $red "ping to $server failed"
fi
done
}
#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
if [ -f $sconfig ]
then
color_msg $green "$sconfig exists"
ls -l $sconfig
fi
}
sconfig=~/.ssh/config
case $# in
0) usage ;;
1) usage ;;
*)
domain=$1
shift
color_msg $blue "checking ssh configuration for domain $domain sites $*"
checkconfig
checkservers $*
;;
esac

- 624
-
2
grep $l_server $sconfig > /dev/null; if [ $? -eq 1 ]; then
should be replaced withif ! grep -q "$l_server" "$sconfig"; then
. 1) Don't check exit codes unless required, instead just useif
directly. 2) grep has a-q
option. Use it instead of> /dev/null
. 3) All environment variable expansion should be double-quoted. Also, consider avoiding abbreviations and consider naming compound words likecheckserver
ascheck_server
orcheckServer
so IDEs with spell check don't complain. – ErikE Jul 13 '20 at 09:58 -
@ErikE - please post your improved version - I'll happily upvote it. – Wolfgang Fahl Jul 13 '20 at 12:20
-
ssh -o UserKnownHostsFile=/dev/null
– odinho - Velmont Aug 29 '17 at 09:35