With the release of OpenSSH 8.2 last week, the project announced that they would disable ssh-rsa signatures in a future version. I thought it would be paramount to update our API users on what this means in practice and how it will impact your implementations.
Why are SSH-RSA signatures being disabled?
OpenSSH has decided to disable ssh-rsa “in a near-future release.”; The release notes of OpenSSH 8.2 state:
It is now possible to perform chosen-prefix attacks against the SHA-1 hash algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm that depends on SHA-1 by default in a near-future release.
This decision follows from work performed by Gaëtan Leurent and Thomas Peyrin, published online and is particularly momentous as ssh-rsa is the last surviving public key specification from the original SSH2 specification. This change will significantly impact compatibility with many clients and servers.
How does it affect API users?
Once implemented by OpenSSH, the 1.4.x versions of our API will not be able to connect to OpenSSH servers’ and OpenSSH clients will not be able to communicate with 1.4.x servers.
With our 1.6.x versions, OpenSSH clients will not be able to use your RSA host keys; however, it should still be communicable if your server has ECDSA host keys present. OpenSSH clients will not be able to use RSA keys for user authentication. Similarly, Maverick Legacy clients using 1.6.x cannot use RSA keys to authenticate to OpenSSH servers.
For our current 1.7.x versions, versions before 1.7.27 will support RSA with stronger signature algorithms but require code changes. Versions 1.7.27 or above will be fully functional and not present any compatibility problems.
What can I do?
Recent SSH specifications added support for SHA2 signatures with RSA keys and allowed for using old ssh-rsa formatted keys but with different signature algorithms. We introduced these algorithms, rsa-sha2-256, and rsa-sha2-512, in our 1.7.18 update.
In 1.7.27, we implemented automatic support for these algorithms; as long as the remote side supports the new algorithms, they will be used in preference to the older SHA-1 signature type.
Therefore, all users should upgrade to 1.7.27 or above of our client and server APIs. With the latest API version, users can still use their existing ssh-rsa keys for authentication. Similarly, servers can continue to load their ssh-rsa keys as these are updated internally to rsa-sha2-256 and rsa-sha2-512 keys.
1.7.x also supports other public-key implementations, including ECDSA, OpenSSH certificates, and ed25519, ensuring the most extensive compatibility possible with modern OpenSSH versions.
Will we remove ssh-rsa support from our APIs?
We do not plan to remove the ssh-rsa SHA1 signature algorithm from the 1.7.x versions of the Maverick Legacy APIs. Our last version of the API included support for algorithm classification, and as such, ssh-rsa has moved to WEAK-level security. It will be up to you to choose if you wish to include this by setting the minimum security level as outlined in our Journal article https://www.jadaptive.com/managed-security-in-our-java-ssh-apis/
For our next-generation API, Maverick Synergy, ssh-rsa will still be present in the WEAK algorithms list but will not be used because we have set the default minimum security level to STRONG.
How long do I have?
The change may not have an immediate impact as the new version will take time to filter through to the most popular OS distributions; however, taking action now will ensure you minimize the support tickets that will undoubtedly flow from this change.
Please consider planning the API upgrade in your next build cycle, and feel free to contact us if you have any concerns or further questions about these changes.