119

We are attempting to speed up the installation of oracle nodes for RAC installation. this requires that we get ssh installed and configured so that it doesn't prompt for a password.

The problem is: On first usage, we are prompted for

RSA key fingerprint is 96:a9:23:5c:cc:d1:0a:d4:70:22:93:e9:9e:1e:74:2f.
Are you sure you want to continue connecting (yes/no)? yes

Is there a way to avoid that or are we doomed to connect at least once on every server from every server manually?

0

7 Answers 7

169

Update December 2019:

As Chris Adams pointed out below, there has been a fairly significant change to Openssh in the 6.5 years since this answer was written, and there is a new option that is much safer than the original advice below:

* ssh(1): expand the StrictHostKeyChecking option with two new
   settings. The first "accept-new" will automatically accept
   hitherto-unseen keys but will refuse connections for changed or
   invalid hostkeys. This is a safer subset of the current behaviour
   of StrictHostKeyChecking=no. The second setting "off", is a synonym
   for the current behaviour of StrictHostKeyChecking=no: accept new
   host keys, and continue connection for hosts with incorrect
   hostkeys. A future release will change the meaning of
   StrictHostKeyChecking=no to the behaviour of "accept-new". bz#2400

So instead of setting StrictHostKeyChecking no in your ssh_config file, set StrictHostKeyChecking accept-new.


Set StrictHostKeyChecking no in your /etc/ssh/ssh_config file, where it will be a global option used by every user on the server. Or set it in your ~/.ssh/config file, where it will be the default for only the current user. Or you can use it on the command line:

ssh -o StrictHostKeyChecking=no -l "$user" "$host"

Here's an explanation of how this works from man ssh_config (or see this more current version):

StrictHostKeyChecking

      If this flag is set to “yes”, ssh will never automatically add host keys to the $HOME/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed.  This provides maximum protection against trojan horse attacks, however, can be annoying when the /etc/ssh/ssh_known_hosts file is poorly maintained, or connections to new hosts are frequently made.  This option forces the user to manually add all new hosts.  If this flag is set to “no”, ssh will automatically add new host keys to the user known hosts files.  If this flag is set to “ask”, new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed.  The host keys of known hosts will be verified automatically in all cases.  The argument must be “yes”, “no” or “ask”.  The default is “ask”.

4
  • 1
    +1, I also this for my servers. And just to be clear, the message in the question comes from the ssh client on the connecting client computer and not from the server. Commented Mar 2, 2012 at 20:53
  • 7
    This answer sounds like a security problem in the making.
    – SunSparc
    Commented Jun 15, 2016 at 20:59
  • 4
    This answer is a security hole waiting to happen unless you are careful to only enable it on networks which are known to be safe (i.e. it is never a good idea to have it in ~/.ssh/ssh_config). Modern versions of OpenSSH support StrictHostKeyChecking accept-new which automatically accepts a key from a new host without disabling security checks for every host which you've already connected to. Commented Dec 6, 2019 at 19:38
  • 1
    Thanks for mentioning this, @ChrisAdams. I've added an update to the answer to reflect this new (compared to the date of the original answer) option. Commented Dec 6, 2019 at 21:38
31

ssh-keyscan - Gather ssh public keys

If you already know the list of hosts you will connect to, you can just issue:

ssh-keyscan host1 host2 host3 host4

You can give the -H option to have it hash the results like ssh defaults to now

Also you can give -t keytype were keytype is dsa, rsa, or ecdsa if you have a preference as to which type of key to grab instead of the default.

Once you have run ssh-keyscan it will have pre-populated your known-hosts file and you won't have ssh asking you for permission to add a new key.

2
  • 1
    I'm a little puzzled about the "will have pre-populated" comment... known_hosts isn't created or modified after running this. You mean the contents can be piped to the file to populate it?
    – rschwieb
    Commented Mar 23, 2018 at 13:57
  • 8
    Confirming with techrepublic.com/article/… . ssh-keyscan -H myhost >> ~/.ssh/known_hosts, or for server-wide, /etc/ssh/ssh_known_hosts
    – cole
    Commented Aug 1, 2018 at 1:47
18

Ignore Host

Ignore the HostKeyChecking. For this I use e.g.:

ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null [email protected]

Add Host

Add the host's/server's fingerprint to .ssh/known_hosts prior to your first connect. This is the safer way.

4
  • Hi. Oracle issue the ssh command so I have no control over how it performs this. Commented Mar 2, 2012 at 22:49
  • 1
    Upvoted. Most of the answers I've seen miss the mentioning of dev nulling the known hosts file. This makes the command much more usable and won't ruin any existent config.
    – Alex
    Commented Feb 22, 2019 at 14:40
  • (2) Sure, adding the fingerprint to the known hosts file is the ideal approach — but how does one do it?   (1) Why is it beneficial to set the user known hosts file to /dev/null?   Wouldn’t it be better to do ssh -oStrictHostKeyChecking=no [email protected] once to get the server’s fingerprint into the $HOME/.ssh/known_hosts file, so subsequent connections will proceed without a request for confirmation? Commented Jun 24, 2019 at 19:13
  • known_hosts does not contain fingerprints, so adding the fingerprint won't work. You need to add the key blob, as with ssh-keyscan -- which has exactly the same security weakness as StrictHostKeyChecking=no Commented Jun 25 at 1:07
12

You can add the fingerprint to each server's known_hosts. For a single user:

cat ~/.ssh/known_hosts
echo "$SERVER,$PORT ssh-rsa $SERVER_KEY_FINGERPRINT" >> ~/.ssh/known_hosts
2
  • 3
    This is no more the right way to do it since when hashing was introduced.
    – Deim0s
    Commented Apr 20, 2015 at 9:38
  • This was never right. known_hosts contains the key blob, not the fingerprint, and for non-default port and not hashed (@Deimos) the syntax is [server]:port not a comma Commented Jun 25 at 1:09
5

Execute the following snippet before trying.

mkdir -p ~/.ssh     
echo "Host *" > ~/.ssh/config     
echo " StrictHostKeyChecking no" >> ~/.ssh/config

ps: Strictly not for production servers, beware of ManInMiddle

2
  • This may (read "usually will") not create the (.ssh) directory with mode 700, which I think it needs...? Add chmod 700 ~/.ssh ?
    – Tom Hundt
    Commented Nov 21, 2019 at 19:32
  • could you please change the first echo to >>? otherwise someone running your command will get their pre-existing .ssh/config wiped out.
    – stason
    Commented Sep 6, 2023 at 17:13
0

I like Tim's answer for one off type things however, if this is a host you intend on connecting to on a regular basis I would create an entry in your ~/.ssh/config (create it if the file does not exist).

# this example shows wildcard for IP
# you can even use more than one wildcard 10.0.*.* for example
Host 192.168.56.*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
# you can even alias it, which is really useful when scp'ing/rsyncing foo:/path/to/remote
Host foo
    HostName foo-long-192-10-135-55.hostname.not-going-to-remember.doh
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
-2

Removed both the all the existing keys from known_hosts and Ran it again. This time the right key has been added and no more having the issue.

2
  • You removed what key from known_hosts? The user in the question has not yet connected to the host, so the hosts key would not be there.
    – Kusalananda
    Commented Mar 10, 2023 at 12:06
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Mar 10, 2023 at 16:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .