I've tried yes | ssh [email protected] 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?

9 Answers 9


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.

  • 5
    Thanks ssh -o "StrictHostKeyChecking no" [email protected] worked for me
    – VenomFangs
    Commented Oct 21, 2014 at 15:18
  • 28
    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
    Commented Oct 7, 2015 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
    Commented Dec 3, 2016 at 2:34

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)

  • 3
    To save someone a few clicks, place "StrictHostKeyChecking=accept-new" in ~/.ssh/config to get this to work.
    – Urchin
    Commented Feb 2, 2021 at 17:05
  • 4
    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! Commented May 20, 2021 at 17:48
  • 6
    @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. Commented Jun 2, 2021 at 12:21
  • 3
    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. Commented Jun 2, 2021 at 15:33
  • 4
    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. Commented Jun 3, 2021 at 16:50

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:


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


ssh -o "UserKnownHostsFile $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.


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"
  • This worked for me, is there a reason why it was down voted? Also requires OpenSSH 7.6+ Commented Jul 2, 2019 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) Commented May 24, 2020 at 11:37
  • @ScottPrive, this answer is correct (esp. for 2017), but it's not the right one since at least 2018. StrictHostKeyChecking=accept-new is a much safer alternative for modern OpenSSH. Commented Jun 21 at 9:40

Use the StrictHostKeyChecking option, for example:

ssh -oStrictHostKeyChecking=accept-new $host 

This option can also be added to ~/.ssh/config:

Host *
    StrictHostKeyChecking accept-new

The benefit to the accept-newoption is that it will remember the host the first time you connect to it - and if it ever changes you will be warned.

This is not a blanket override. If host keys change you will still get a warning. If you absolutely do not care about getting MITM'ed you can use this instead:

ssh -oUserKnownHostsFile=/dev/null $h

This is a terrible idea for obvious reasons - anyone can create a script that can just harvest your password and use it to take over the real host.


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


echo "StrictHostKeyChecking no" >> ~/.ssh/config

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


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.

  • Overwriting .ssh/config with this single line? Sounds more like a prank to me., so luckily no one mentioned it before.
    – hakre
    Commented Jul 28, 2021 at 19:42
  • Wait, this is not a crontab. You do that only once. See the update
    – Nick
    Commented Jul 29, 2021 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
    Commented Jul 29, 2021 at 15:07

Use this command to add the host to ~/.ssh/known-hosts (and dont add duplicated ones) as guided here

e.g. adding gitlab.com

ssh-keygen -F gitlab.com || ssh-keyscan gitlab.com >> ~/.ssh/known_hosts
  • In the case of logging into termux's dropbear the command ssh-keyscan -p 8022 >> ~/.ssh/known_hosts was enough for me; my aim was to allow to remain the old key to let me log into termux on the old smartphone too. Commented Aug 28, 2023 at 4:24

you must add trusted host to file: ~/.ssh/config

you can easily achieve it this way, just change the value of TRUSTED_HOST for your hostname

export TRUSTED_HOST="github.com" && {cat | >> ~/.ssh/config } <<EOF
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR

In dropbear ssh you can use -y option: i.e. try

ssh -y [email protected]

-y Always accept remote host key if unknown

  • 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
    Commented Dec 31, 2016 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
    Commented Feb 9, 2017 at 20:22
  • I see the same in man. Commented May 15, 2017 at 11:39
  • this isn't a valid ssh option ? Where did you copy/paste this from ?
    – Flo Woo
    Commented May 29, 2017 at 8:46
  • 6
    This option only exists in dropbear SSH, not OpenSSH. Commented Jun 19, 2017 at 7:12

You must log in to answer this question.

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