OpenSSH 8 Breaking Changes

If you’re using an SSH server, security best practices indicate that you should always use public key authentication (and never password-based authentication). For many of us, this meant generating an RSA key pair, then adding the public key to the ~/.ssh/authorized_keys file, and everything just worked.

With the introduction of OpenSSH 8, the OpenSSH team has deprecated RSA signatures with weak SHA1 hashes¹.

This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K ²
OpenSSH Release Notes

Most RSA keys generated with ssh-keygen -t rsa will be using SHA256 hashes and won’t be affected. OpenSSH clients can adequately negotiate with these keys. Older client implementations do not seem to be able to negotiate a connection, leading to some difficult-to-debug issues. Primarily, connections to servers that once worked will begin to return No supported authentication methods available (server sent: publickey) even though you’re using a public key. The debug logs for the server won’t be of much help either; they’ll contain something like this:

Failed publickey for <user> from <ip_address> port <some_port> ssh2: RSA-CERT SHA256:<redacted> ID <user> (serial <redacted>) CA RSA SHA256:<redacted>

error: Received disconnect from <ip_address> port <some_port>: No supported authentication methods available [preauth]

In my case, I was seeing this with the otherwise-stellar MobaXterm program (v22.1 build 4888), but I wasn’t seeing this when using OpenSSH³ from my terminal using the same public key! It’s worth noting that my key is using SHA256, so it’s unclear what part of the SSH handshake is causing the hiccup.

The Fix

One option to fix this issue is to generate a key pair using a more robust and modern cipher. The current recommendation is Edwards-curve Digital Signature Algorithm, specifically Ed25519.

To do this, we can simply generate a new key:

$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:FNsGzwO5keen60lsU0MiYuyk7IxGjbrpauUcR1YE5Iw user@host
The key's randomart image is:
+--[ED25519 256]--+
|    .oo.+o       |
|    +. .+O.      |
|   E o* +=B .    |
|   + B o.o.+.    |
|  o * . S  oo    |
| o * .   ... .   |
|. * =     =.     |
| = o     o.o     |
|B.       .o      |
+----[SHA256]-----+

Because this file is saved as id_ed25519 (by default), it shouldn’t interfere with any existing id_rsa files.

In the case of MobaXterm, you can simply set the public key to the new key, and you should be all set!

Alternatively, updating your SSH client so that it can properly negotiate a connection with RSA keys using SHA256+ hashes may be a more appropriate approach if you have the ability to do so. Unfortunately, I don’t know if it’s possible to update the SSH engine in MobaXterm – maybe a later release will fix this issue.