In this modern era of cloud computing, servers are provisioned as needed and destroyed when their work is done. Most of these servers are short lived and have relatively low security requirements. This leads to some annoyances when using SSH. Specifically, the known_hosts file is constantly growing, most of the host records belong to hosts that don’t exist anymore, or the host keys for a particular system change frequently. Luckily, there’s an easy work around.

There are two SSH options that can help: StrictHostKeyChecking and UserKnownHostsFile (see the ssh-config man page for full details). Setting StrictHostKeyChecking to “no” tells SSH to automatically add hosts to the known_hosts file. UserKnownHostsFile can be used to define a different file to track host keys. In the bluntest scenario, /dev/null can be used as a known_hosts file. From the command line, the options are used as follows:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@example.com

In this scenario, SSH will attempt to connect to example.com as user, look for an existing host key record in /dev/null (which obviously doesn’t exist), automatically adds the host key to /dev/null (without prompting, but it may output a warning), and finally opens the connection.

This trick can also be applied to a SSH config file to simplify usage. For example, if connections are frequently made to a cloud environment, a host pattern could be used to automatically apply the above options.

Host *.cloud.example.com
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Then, connections would be as simple as:

ssh instance.cloud.example.com

The internet is filled with variations on this, and other, tips.