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.
signature.asc
Description: PGP signature
