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?
- 529
- 2
- 6
- 10
8 Answers
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".
- 469
- 1
- 4
- 5
-
2To save someone a few clicks, place "StrictHostKeyChecking=accept-new" in ~/.ssh/config to get this to work. – Urchin Feb 02 '21 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! – Clément Moulin - SimpleRezo May 20 '21 at 17:48
-
2@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 02 '21 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. – Clément Moulin - SimpleRezo Jun 02 '21 at 15:33
-
1I 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 03 '21 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
:
#!/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.
- 358
- 3
- 6
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.
-
5Thanks `ssh -o "StrictHostKeyChecking no" root@10.x.x.x` worked for me – VenomFangs Oct 21 '14 at 15:18
-
20how 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 07 '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 03 '16 at 02:34
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"
- 175
- 8
- 111
- 4
-
This worked for me, is there a reason why it was down voted? Also requires OpenSSH 7.6+ – Xenocide8998 Jul 02 '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) – Scott Prive May 24 '20 at 11:37
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-new
option 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.
- 589
- 4
- 14
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.
- 786
- 2
- 12
- 37
-
Overwriting .ssh/config with this single line? Sounds more like a prank to me., so luckily no one mentioned it before. – hakre Jul 28 '21 at 19:42
-
-
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 '21 at 15:07
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
Host $TRUSTED_HOST
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
LogLevel ERROR
EOF
- 101
- 1
In dropbear ssh you can use -y
option: i.e. try
ssh -y root@10.x.x.x
-y
Always accept remote host key if unknown
- 589
- 4
- 14
- 35
- 1
-
Welcome to Server Fault! Please use [Markdown](http://serverfault.com/editing-help) 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 09 '17 at 20:22
-
-
-
5