166

I want to connect to a host via SSH but I don't want the hostname to be added to my ~/.ssh/known_hosts.

How can I do that?

jonsca
  • 4,077
  • 15
  • 35
  • 47
Albert
  • 6,531
  • 11
  • 39
  • 51

7 Answers7

151
-o "UserKnownHostsFile=/dev/null"

should work.

Albert
  • 6,531
  • 11
  • 39
  • 51
  • 4
    Works as intended, but it will always report: "Warning: Permanently added 'hostname,ip' (RSA) to the list of known hosts." I made that go away with: 2>&1 | `grep -v "^Warning: Permanently added"` – Guillaume Boudreau May 18 '11 at 17:34
  • This is what I needed for my scenario - no DNS, LAN with DHCP, computers getting different addresses all the time. I will need to type 'yes' all the time, but otherwise it's great. – Tomasz Gandor Oct 03 '14 at 04:47
  • 6
    add -o "LogLevel ERROR" and it won't complain with Warnings anymore – John Sep 29 '16 at 02:37
  • 2
    Note: a request to suppress that message "Warning: Permanently added 'hostname,ip' (RSA) to the list of known hosts." was reported to the maintainers https://bugzilla.mindrot.org/show_bug.cgi?id=2413 – Ben Creasy Oct 04 '17 at 02:14
  • 2
    Piping to `grep` will merge stdout and stderr; also the exit status can change. If using `bash`, it will be better to use process substitution to get rid of the message: `ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]`. It will avoid the pipe and thus the corresponding changes in exit status handling. – Alex O Oct 10 '17 at 11:48
  • 2
    @John It is better to use one of the other methods in these comments, otherwise you are introducing a security flaw due to the potential to hide other, unrelated warnings – Jon Bentley Mar 05 '19 at 14:21
  • I suggest ALWAYS use the equals (=) between SSH option and value, because that is easier to parse and is consistent whether executed in a script or a terminal. Parsing issues could be a platform issue, but the whole issue can be avoided if one ignores the ancient openssh.com doc examples (which favor the "quoted with space separator" approach) and just use the simpler equals separator. – Scott Prive Nov 02 '21 at 13:30
  • Per https://bugzilla.mindrot.org/show_bug.cgi?id=2413 support for `UserKnownHostsFile none` was added in 8.5 – Ben Creasy Mar 17 '23 at 05:27
141

If you want this behavior because you're working with cloud servers (AWS EC2, Rackspace CloudServers etc.) or you're constantly provisioning new images in Vagrant you may want to update your SSH config instead of adding bash aliases or more options on the command line.

Consider adding something like:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET
  • Use as strict as regex for host as possible to be secure.
  • Setting the LogLevel to QUIET will keep the Warning which Guillaume mentioned from showing up
cclark
  • 1,511
  • 1
  • 9
  • 5
  • 3
    You really should try to not fully disable StrictHostKeyChecking, so cclark's answer is a great compromise for working with cloud servers. – Alex Recarey Sep 24 '12 at 16:39
  • This proved very helpful to me as I was using Shipit (a JavaScript deployment tool) against Vagrant. I couldn't easily get at the parameters Shipit was passing to SSH so this allowed me to sidestep the tool and tell it what I did and didn't want it to remember. – John Munsch Mar 11 '15 at 03:06
  • 1
    LogLevel is what I was looking for. It has the added advantage of not showing the company configured notice when running scripts! (I am running now w/ loglevel ERROR) – Anshu Prateek Aug 04 '15 at 03:46
  • In what file do I add this ? – Wim Deblauwe May 18 '17 at 12:06
  • 1
    This is your SSH configuration file. In Linux or macOS the file would generally be in a directory called .ssh within your home directory and named config -- ~/.ssh/config – cclark May 18 '17 at 12:09
31

For a single ssh session, use this

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host
Quanlong
  • 1,250
  • 11
  • 14
12

I feel like adding the host key to your known_hosts (the folks running these services are, in my experience, at least smart enough to keep their host keys consistent between machines serving the same hostname) and then turning on StrictHostKeyChecking, turning off CheckHostIP, and logging with LogLevel ERROR will give you the best experience without sacrificing security. (Ok, without CheckHostIP you do need to trust DNS, which is a huge gaping hole without widespread DNSSEC or something similar; but we'll just sweep that under the rug for the moment.)

I use a read-only known_hosts file, so I have to do something or I get endless warnings about not being able to add entries to known_hosts.

What I use:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

I would like these services to publish their SSH host keys on their websites via HTTPS, so I can copy them explicitly without having to connect first and potentially expose myself to a MITM attack.

Kyle Rose
  • 121
  • 1
  • 4
  • No need to publish keys on a website. DNS SSHFP records have been around since 2006. It is not widely supported, at least not on public DNS. – Scott Prive Nov 02 '21 at 13:36
  • If anyone actually used DNSSEC, this might be a viable option for trust establishment. Since end-to-end DNSSEC is virtually non-existent, however, trusting a key served over DNS is probably worse in most cases than TOFU. – Kyle Rose Nov 03 '21 at 14:59
  • Fair, the adoption rate is poor. – Scott Prive Nov 04 '21 at 17:05
8

I suggest

LogLevel ERROR

over

LogLevel QUIET

so you still get "Could not resolve hostname" and other such errors

kiloforce
  • 89
  • 1
  • 1
  • you should be able to trust your SSH connections, imho. Not just make it silent about your risks. – sylvainulg Jan 23 '15 at 09:16
  • 4
    Depends really. We have development environments that get torn down each week and rebuilt, their A records stay the same but their host key is generated each time it's built. We can't persist the host keys because the A record is just defined in a database based off an environment name, and environment names can be scrapped or new ones created at any time, so the above workaround is genuinely useful. – Alex Berry Jun 27 '17 at 08:59
1

Have you tried disabling StrictHostKeyChecking? You can do it with the -o option or in the configuration file ~/.ssh/config.

jneves
  • 307
  • 1
  • 4
  • I'm already using that. But it has a different effect: It loweres the strictness for the host key checking. I.e. when the host is unknown, it still connects when you disable that option. Thus, it still saves the host. But I think I have found the right solution (see my answer). – Albert May 15 '10 at 00:29
0

I found the following .ssh/config entries useful (LAN with DHCP and DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

Result is local machine names "zora" or "goron" will not check against dynamically assigned IP addresses, but www.mycompany.com or node42.planetlab.com will still have their static IPs confirmed.

sylvainulg
  • 583
  • 4
  • 10