From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] openssh: Update to 8.4p1 Date: Fri, 02 Oct 2020 11:15:37 +0100 Message-ID: <9A55F246-A02A-4B88-B102-919474F2FED4@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8419084114043153352==" List-Id: --===============8419084114043153352== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Great! Thank you for clarifying this. I will try to summarise this for the ch= ange log. -Michael > On 1 Oct 2020, at 13:17, Adolf Belka wrote: >=20 > Hallo everyone, >=20 > Just to be certain on this important topic, I did a trawl through the opens= sh email archive on the deprecation and found quite a bit of communication wh= ich has been able to clarify and confirm things. >=20 > - The deprecation notice is related to the key signature algorithm, not the= key type. >=20 > - The string ssh-rsa is used as both a key type name in authorized_keys and= as a key signature algorithm name. This is what has caused some confusion, t= he use of the same string for two very different items. >=20 > - The RSA key with the string identifier ssh-rsa is not changing. So no con= cerns about losing RSA. >=20 >=20 > Neither of the following apply to the IPFire ssh server so there is no prob= lem for the deprecated signature algorithm for IPFire. >=20 > - Openssh servers that are older than 7.4 would need to upgrade to be a= ble to use the sha2 signature algorithms rsa-sha2-256 & rsa-sha2-512. >=20 > - Openssh servers where ssh-rsa has been explicitly specified in sshd_c= onfig would need to add rsa-sha2-256 and/or rsa-sha2-512 to their list. >=20 >=20 > Users of up-to-date default configured ssh clients will have no problems co= nnecting to the IPFire ssh server and will not need to generate new keys, cha= nge their configuration or migrate to different key types. >=20 > - Users with older openssh clients than 7.4 would need to upgrade to be= able to use the sha2 signature algorithms rsa-sha2-256 & rsa-sha2-512. >=20 > - Users that have explicitly specified ssh-rsa in their ssh_config woul= d need to add rsa-sha2-256 and/or rsa-sha2-512 to their list. >=20 >=20 > The majority of people using IPFire will not have any problems. Any that do= will likely have an issue in their ssh_config files that can be easily fixed. >=20 > Regards, >=20 > Adolf. >=20 >=20 > On 30/09/2020 15:27, Michael Tremer wrote: >> Hey Adolf, >>=20 >>> On 29 Sep 2020, at 14:45, Adolf Belka wrote: >>>=20 >>> Hi Michael, >>>=20 >>> I don't believe it will be a problem from what I have read up about on th= is topic. >> Very good to hear. >>=20 >>> The move to disabling the ssh-rsa signature by default is still for a fut= ure (undefined) release. >> I do not think that we can generally disable RSA for SSH. There are simply= too many tools out there that do not support elliptic curve cryptography at = all. >>=20 >>> When it happens this will not change the rsa key itself. That stays the s= ame. It is the hash used for the signature format that's used during each aut= hentication handshake that will have to be different. There are three signatu= re hashes used for rsa keys, ssh-rsa which is SHA1 based and rsa-sha2-256 and= rsa-sha2-512 which are both SHA2 based. >>>=20 >>> Since openssh-7.2 the sha2 signatures have been available and in default = setups the options are tried in descending order in the key exchange communic= ation, so rsa-sha2-512 first then rsa-sha2-256 and then ssh-rsa. The first on= e available in both server and client will be used. Apparently some people mu= st be explicitly defining only ssh-rsa in their ssh_config file with HostKeyA= lgorithms. >>>=20 >>> If the HostKeyAlgorithms is not specified in ssh_config then the default = includes the sha2 options. >> We do not explicitly change this anywhere on IPFire. >>=20 >>> The only problem I can see when this default is implemented in the future= is for people who have ssh clients where ssh-rsa has been explicitly specifi= ed without the sha2 variants in ssh_config. Then the negotiation between thei= r client and the ipfire ssh server would fail. Updating their HostKeyAlgorith= ms line to include rsa-sha2-512 and rsa-sha2-256 would fix the problem and ma= ke their signature format much more secure. >> People who have that deliberately disabled probably have other issues. I a= m more worries about people who run clients that don=E2=80=99t support the ne= wer ones. We will see. We cannot stop progress for a couple of people who do = not update their systems for forever. >>=20 >>> Having said all the above, I think it would be good for someone else to a= lso check this out to make sure that my interpretation and understanding is c= orrect. >> I double checked. This looks very good. Thank you for looking into this at= this depth. Good job! >>=20 >> -Michael >>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>=20 >>> On 29/09/2020 10:29, Michael Tremer wrote: >>>> Good morning Adolf, >>>>=20 >>>> Thank you for working on this. >>>>=20 >>>> Did you have a look at the changes regarding retiring support for RSA-SH= A1? Does that affect us in any way? >>>>=20 >>>> Best, >>>> -Michael >>>>=20 >>>>> On 29 Sep 2020, at 08:21, Adolf Belka wrote: >>>>>=20 >>>>> - Update openssh from version 8.3p1 to 8.4p1 >>>>> See https://www.openssh.com/releasenotes.html >>>>> See https://www.openssh.com/portable.html#http for mirrors for source = file >>>>> - No change to rootfiles >>>>> - Installed on virtual ipfire testbed and ssh connection successfully o= perated >>>>> Signed-off-by: Adolf Belka >>>>> --- >>>>> lfs/openssh | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>=20 >>>>> diff --git a/lfs/openssh b/lfs/openssh >>>>> index 75210060e..5143f4154 100644 >>>>> --- a/lfs/openssh >>>>> +++ b/lfs/openssh >>>>> @@ -24,7 +24,7 @@ >>>>>=20 >>>>> include Config >>>>>=20 >>>>> -VER =3D 8.3p1 >>>>> +VER =3D 8.4p1 >>>>>=20 >>>>> THISAPP =3D openssh-$(VER) >>>>> DL_FILE =3D $(THISAPP).tar.gz >>>>> @@ -40,7 +40,7 @@ objects =3D $(DL_FILE) >>>>>=20 >>>>> $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE) >>>>>=20 >>>>> -$(DL_FILE)_MD5 =3D 68d7527bf2672153ca47402f6489a1af >>>>> +$(DL_FILE)_MD5 =3D 8f897870404c088e4aa7d1c1c58b526b >>>>>=20 >>>>> install : $(TARGET) >>>>>=20 >>>>> --=20 >>>>> 2.28.0 >>>>>=20 --===============8419084114043153352==--