Date: Sun, 12 Sep 2021 16:02:42 +0200 From: Markus Falb <markus.falb@fasel.at> To: freebsd-security@freebsd.org Subject: Re: Important note for future FreeBSD base system OpenSSH update Message-ID: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> In-Reply-To: <CAPyFy2Aw8Z3ngiM8YHApjjPRLZVC5MCN8TRQkh6pj2fSeM1zqw@mail.gmail.com> References: <CAPyFy2A390kS_C3g=Y9QhQcJ06z_FKUxXsNvi9g2CdWF24pukg@mail.gmail.com> <CAPyFy2B04b0GtWoHFQwxht5vK4_cnApPXpDLXU%2BRvcR=2L9YxA@mail.gmail.com> <CAPyFy2Aw8Z3ngiM8YHApjjPRLZVC5MCN8TRQkh6pj2fSeM1zqw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 09.09.2021, at 20:01, Ed Maste <emaste@freebsd.org> wrote: > > OpenSSH will disable the ssh-rsa signature scheme by default in the > next release. > > ... > > To check whether a server is using the weak ssh-rsa public key > algorithm, for host authentication, try to connect to it after > removing the ssh-rsa algorithm from ssh(1)'s allowed list: > > ssh -oHostKeyAlgorithms=-ssh-rsa user@host FWIW, some of us may already have dealt with that. FIPS enabled RedHat Enterprise Linux (and probably other FIPS enabled systems) means effectively no ssh-rsa signature available in the sshd. I had that situation at the beginning of the year. As mentioned, ssh-rsa signature algorithm will stop working, but that does not automatically imply that every RSA key must be changed to something other. The signature algorithm is not a property that is inherent to the key. That said, existing RSA keys were working fine for me (my openssh client was rsa-sha2-256 and rsa-sha2-512 capable) but when I tested with some popular windows clients (filezilla, putty) it failed (apparently no rsa-sha2 algorithms available). I found it interesting that mentioned clients were ecdsa capable but did not support sha2 signatures with RSA keys. Maybe the situation changed in the meantime to the better. There are 3 scenarios: 1. both sides support rsa-sha2 signatures -> RSA keys still working 2. one side does not support sha2 signatures but does support other key types -> you can change key type 3. one side does not support sha2 and no other key type -> you loose A prominent candidate for 3. would be Cisco IOS Best Regards, Markus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8169A4A8-B8D1-4265-87C8-74ED4D34FBC8>