22

I've tried yes | ssh root@10.x.x.x to try to accept the RSA key fingerprint, but am still prompted if I'm sure I want to connect. Is there a way to make this automatic?

10

Add these to your bash startup file, or similar:

 #
 #  ssh + scp without storing or prompting for keys.
 #
 function sshtmp
 {
     ssh -o "ConnectTimeout 3" \
         -o "StrictHostKeyChecking no" \
         -o "UserKnownHostsFile /dev/null" \
              "$@"
 }
 function scptmp
 {
     exec scp -o "ConnectTimeout 3" \
         -o "StrictHostKeyChecking no" \
         -o "UserKnownHostsFile /dev/null" \
         "$@"
 }

Then use sshtmp, or scptmp in place of ssh and scp.

NOTE If you do go down this road you'll not be alerted that a host-key has changed and will lose security.

3
  • 4
    Thanks ssh -o "StrictHostKeyChecking no" root@10.x.x.x worked for me
    – VenomFangs
    Oct 21 '14 at 15:18
  • 20
    how is this the answer? The question was to accept the keys automatically, not ignore them! If this is asked and answered here then how do I find an answer to the actual question "Accept keys automatically"? Hate to do a downvote but come-on people, this is not the way stack-exchange should be!
    – JohnnyB
    Oct 7 '15 at 15:38
  • @JohnnyB take a look at my answer. It is not the cleanest solution, but it actually permits the key to be automatically accepted
    – RDP
    Dec 3 '16 at 2:34
28

OpenSSH 7.6 has introduced new StrictHostKeyChecking=accept-new setting for exactly this purpose:

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 "n", 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".

(OpenSSH 7.6 Release notes)

5
  • 2
    To save someone a few clicks, place "StrictHostKeyChecking=accept-new" in ~/.ssh/config to get this to work.
    – Urchin
    Feb 2 at 17:05
  • Don't add accept-new in config file! This can be a security issue if connecting to a unknown host, it will accepted by default, exposing you to a man-in-the-middle attack. If this setting is not set by default, that's because it's not safe! May 20 at 17:48
  • @ClémentMoulin-SimpleRezo, not quite true: if you connect to a truly unknown host, you don't know its fingerprint anyway, so you will hit "yes, trust it". I have yet to see somebody checking host fingerprints manually. If you have fingerprints distributed separately (e.g., SSH bastion host of your company or something like this), it's better to put them into "known_hosts" file so that SSH client checks them for you. So there are some use cases when this setting could lead to serious security implications, but they are pretty specific.
    – Klas Š.
    Jun 2 at 12:21
  • That's why SSH fingerprints can be distributed also by DNS, and of course, preferally using DNSSEC. Definetly disagree with your last comment. Host identification is the MOST important part of identification. Jun 2 at 15:33
  • I never said it wasn't. But you have no way to identify the host you connect to for the first time and know nothing about, so I can't see any security benefits. Yes, DNSSEC verification is nice, and if it exists and is enabled then there's an automated check, but I never met it in the wild (unfortunately). I wouldn't recommend people enabling StrictHostKeyChecking=accept-new by default for all hosts, but I don't see it as a breach either.
    – Klas Š.
    Jun 3 at 16:50
15

Using SSH Programmatically with known hosts key

If what you want is to be able to use programmatically AND avoid Man-In-The-Middle attack, then I suggest you get the known fingerprint using the command ssh-keyscan. Example:

$ ssh-keyscan -t rsa,dsa github.com 2>/dev/null
github.com ssh-dss AAAAB3NzaC1kc3MAAACBANGFW2P9xlGU3zWrymJgI/lKo//ZW2WfVtmbsUZJ5uyKArtlQOT2+WRhcg4979aFxgKdcsqAYW3/LS1T2km3jYW/vr4Uzn+dXWODVk5VlUiZ1HFOHf6s6ITcZvjvdbp6ZbpM+DuJT7Bw+h5Fx8Qt8I16oCZYmAPJRtu46o9C2zk1AAAAFQC4gdFGcSbp5Gr0Wd5Ay/jtcldMewAAAIATTgn4sY4Nem/FQE+XJlyUQptPWMem5fwOcWtSXiTKaaN0lkk2p2snz+EJvAGXGq9dTSWHyLJSM2W6ZdQDqWJ1k+cL8CARAqL+UMwF84CR0m3hj+wtVGD/J4G5kW2DBAf4/bqzP4469lT+dF2FRQ2L9JKXrCWcnhMtJUvua8dvnwAAAIB6C4nQfAA7x8oLta6tT+oCk2WQcydNsyugE8vLrHlogoWEicla6cWPk7oXSspbzUcfkjN3Qa6e74PhRkc7JdSdAlFzU3m7LMkXo1MHgkqNX8glxWNVqBSc0YRdbFdTkL0C6gtpklilhvuHQCdbgB3LBAikcRkDp+FCVkUgPC/7Rw==
github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==

Then you can forge a script to save it to a temporary file and use the UserKnownHostsFile option. The example below is a script, which can be called ssh_github:

#!/bin/bash

HOSTKEY='github.com ssh-dss AAAAB3NzaC1kc3MAAACBANGFW2P9xlGU3zWrymJgI/lKo//ZW2WfVtmbsUZJ5uyKArtlQOT2+WRhcg4979aFxgKdcsqAYW3/LS1T2km3jYW/vr4Uzn+dXWODVk5VlUiZ1HFOHf6s6ITcZvjvdbp6ZbpM+DuJT7Bw+                      h5Fx8Qt8I16oCZYmAPJRtu46o9C2zk1AAAAFQC4gdFGcSbp5Gr0Wd5Ay/jtcldMewAAAIATTgn4sY4Nem/FQE+XJlyUQptPWMem5fwOcWtSXiTKaaN0lkk2p2snz+EJvAGXGq9dTSWHyLJSM2W6ZdQDqWJ1k+cL8CARAqL+UMwF84CR0m3hj+wtVGD/J4G5kW2DBAf4/bqzP4469lT+dF2FRQ2L9JKXrCWcnhMtJUvua8dvnwAAAIB6C4nQfAA7x8oLta6tT+oCk2WQcydNsyugE8vLrHlogoWEicla6cWPk7oXSspbzUcfkjN3Qa6e74PhRkc7JdSdAlFzU3m7LMkXo1MHgkqNX8glxWNVqBSc0YRdbFdTkL0C6gtpklilhvuHQCdbgB3LBAikcRkDp+FCVkUgPC/7Rw==
github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+                                                                                                                                      PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+    2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ=='

TEMPFILE=$(mktemp)
echo "$HOSTKEY" > $TEMPFILE

ssh -o "UserKnownHostsFile $TEMPFILE" $@

rm $TEMPFILE

With this, you can just run ssh_github instead of ssh and it will connect even if there is no known_hosts file where you put the script.

2

I just use:

ssh -o StrictHostKeyChecking=no user@host

It can also be used with pssh:

pssh -O StrictHostKeyChecking=no -h list.text -l user -A -i "cmd"
2
  • This worked for me, is there a reason why it was down voted? Also requires OpenSSH 7.6+ Jul 2 '19 at 17:06
  • This is THE correct answer, directly answering the question in the context the asker frames . The relevant piece is ` -o StrictHostKeyChecking=no`. There's a caveat - consider the security implications - especially if you're sticking this into a script you'll forget about. (And if you're routinely dealing with this in a lab environment, there's better ways - you probably want to look at provisioning the hosts with certificates or public keys) May 24 '20 at 11:37
0

My 5 cents, because no one mentioned it:

First my use case - several servers upload to single "upload" server given as hostname "upload.domain.com". Upload is made with rsync+ssh. I wanted to be able to change "upload.domain.com" and everything to continue to work.

I did config file in .ssh directory:

cat > .ssh/config <<[end]
StrictHostKeyChecking no
[end]

You do not need to remove .ssh/known_hosts file, it prints message, but works anyway.


Update

I don't mean this to be crontab or something automatic.

I mean you have to create a file .ssh/config and put this line into it. Easiest way is via the command I show. You can use any other method thats easy for you, like text editors - vi, pico etc.

3
  • Overwriting .ssh/config with this single line? Sounds more like a prank to me., so luckily no one mentioned it before.
    – hakre
    Jul 28 at 19:42
  • Wait, this is not a crontab. You do that only once. See the update
    – Nick
    Jul 29 at 14:12
  • Okay, that adds more context. However this is just how ssh works - see ssh_config(5) - and so I wonder what it adds to the answers that have the StrictHostKeyChecking setting already. It perhaps falls into comment territory ... and there was some earlier critique that StrictHostKeyChecking no is not the answer.
    – hakre
    Jul 29 at 15:07
-1

You can use -y option: i.e. try

ssh -y root@10.x.x.x

-y Always accept remote host key if unknown

5
  • Welcome to Server Fault! Please use Markdown and/or the formatting options in the edit menu to properly type-set your posts to improve their readability. It is convention to format commands as "code".
    – HBruijn
    Dec 31 '16 at 16:26
  • Strange but in the man I see the following - -y Send log information using the syslog system module. By default this information is sent to stderr.
    – ALex_hha
    Feb 9 '17 at 20:22
  • I see the same in man. May 15 '17 at 11:39
  • this isn't a valid ssh option ? Where did you copy/paste this from ?
    – Flo Woo
    May 29 '17 at 8:46
  • 4
    This option only exists in dropbear SSH, not OpenSSH. Jun 19 '17 at 7:12

Your Answer

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

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