TOFU with Visual Host Key

TOFU with Visual Host Key

Say we have set up a new computing device and we try to clone a Git repository from a remote Git server via SSH. There is a good chance that our experience may look something like this:

$ git clone [email protected]:susam/devil.git
Cloning into 'dotfiles'...
The authenticity of host 'github.com (140.82.121.3)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

What should we do here? Is it safe to accept this host key and proceed? A similar conundrum arises when we try to log into a remote server via SSH for the first time from this new device.

$ ssh tty.sdf.org
The authenticity of host 'tty.sdf.org (205.166.94.4)' can't be established.
ED25519 key fingerprint is SHA256:ZjwbO7AU8rHJExYrmZS2LqGZ7WfdoELfMrF54W92PYA.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Again, what should we do here? In both examples above, our SSH client on the new system has not seen the public key of the remote server before. Therefore it does not know whether to trust it or not. The security of any subsequent encrypted communication with the remote server critically depends on the authenticity of this public key. If the SSH client connects to a legitimate remote server and receives its legitimate public key and we decide to trust this key and proceed with the connection, then we will enjoy the safety of an encrypted connection with the legitimate server.

However, if a rogue server has managed to masqeurade as the server we want to connect to and our client has received a public key of this rogue server and we decide to trust it, then we will end up connecting to this rogue server. Obviously, we don't want to do that.

The question we have here is whether to trust the server's public key when we connect to it for the first time. All we have been presented with by the SSH client is a fingerprint of the public key it has received from the remote server. Should we trust on first use (TOFU)?

A prudent thing we can do here is to find the host key fingerprint of the server from a reliable source over a secure connection. For the specific examples presented above, we are in luck. Both github.com and sdf.org publish their SSH host keys on web pages served via HTTPS. Therefore we can compare the fingerprints published there with the ones presented by the SSH client and if they match, we can ask the client to go ahead with the connections. The client would then trust that host key and add it to ~/.ssh/known_hosts file in order to remember it, so that it does not have to ask us about the authenticity of the host key the next time we connect to the same server. This completes TOFU. In case, the SSH client finds that the host key of the server has changed the next time we connect to it, it would present a big warning in uppercase letters about it urging us to investigate if we are being attacked with a rogue server or if the host key has indeed changed in a legitimate manner.

While public facing services like GitHub and SDF do publish their host keys via HTTPS, so that we can read them with a web browser and compare them with the host key fingerprints the SSH client is present us, we do not always have the luxury of these fingerprints being readily available in a secure location. This is especially true in many private networks where servers may be provisioned and reprovisioned frequently with little care about maintaining a secure inventory of the host keys we can rely on.

Home Blog Feed Subscribe About GitHub Mastodon

© 2001–2023 Susam Pal