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 hashes1SHA1 is vulnerable to collision attacks.
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 2“SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust” Leurent, G and Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdfOpenSSH 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 OpenSSH3OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 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.
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
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.