Hi, On Thu, Sep 30 2021 at 14:27:24 UTC, Heiko Tietze wrote: > That's caused by OpenSSH update to 8.8 where RSA-SSH encryption was > disabled This is misleading: RSA (and other key types) is only used for authentication, not for key exchange let alone data encryption. Also as of OpenSSH 8.8, RSA keys are in *no way* deprecated or disabled; what *is* now disabled by default — and which has been deprecated for a while — are RSA signatures based on the SHA-1 digest algorithm. When both client and server advertise support for SHA-2 (for instance if both are OpenSSH ≥7.2, released Feb 2016) then the handshake will use that for RSA user resp. host signatures. OpenSSH 8.8 did not deprecate RSA keys. The reason they don't work anymore with gerrit (and Jenkins) is due to a bug in gerrit's builtin SSHd: https://issues.apache.org/jira/browse/SSHD-1141 . mina SSHd appears to only advertise support for one digest algorithm per key type, and for RSA it's unfortunately SHA-1. Although it actually does support rsa-sha2-*, these are not advertised to the client which therefore fallbacks to SHA-1 when RSA keys are used for authentication. That bug is fixed upstream and a future gerrit release will come with the new mina SSHd, thereby restoring compatibility with OpenSSH ≥8.8 and RSA user keys. > The second method works until Debian stops supporting RSA. That is incorrect. An OpenSSH ≥8.8 client with stock configuration can authenticate to an OpenSSH ≥7.2 server and vice versa. But the OpenSSH let alone Debian version used on the server is irrelevant here: what listens at gerrit.libreoffice.org:29418 is not OpenSSH but gerrit's builtin SSHd (mina SSHd). cheers -- Guilhem.
Attachment:
signature.asc
Description: PGP signature
