From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: [PATCH] openssh: Update to 8.4p1 Date: Thu, 01 Oct 2020 14:17:32 +0200 Message-ID: In-Reply-To: <90A5E269-F041-435D-83F8-23AB30B841A4@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4615400394674648765==" List-Id: --===============4615400394674648765== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hallo everyone, Just to be certain on this important topic, I did a trawl through the openssh= email archive on the deprecation and found quite a bit of communication whic= h has been able to clarify and confirm things. - The deprecation notice is related to the key signature algorithm, not the k= ey type. - The string ssh-rsa is used as both a key type name in authorized_keys and a= s a key signature algorithm name. This is what has caused some confusion, the= use of the same string for two very different items. - The RSA key with the string identifier ssh-rsa is not changing. So no conce= rns about losing RSA. Neither of the following apply to the IPFire ssh server so there is no proble= m for the deprecated signature algorithm for IPFire. =C2=A0=C2=A0=C2=A0 - Openssh servers that are older than 7.4 would need to u= pgrade to be able to use the sha2 signature algorithms rsa-sha2-256 & rsa-sha= 2-512. =C2=A0=C2=A0=C2=A0 - Openssh servers where ssh-rsa has been explicitly speci= fied in sshd_config would need to add rsa-sha2-256 and/or rsa-sha2-512 to the= ir list. Users of up-to-date default configured ssh clients will have no problems conn= ecting to the IPFire ssh server and will not need to generate new keys, chang= e their configuration or migrate to different key types. =C2=A0=C2=A0=C2=A0 - 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-s= ha2-512. =C2=A0=C2=A0=C2=A0 - Users that have explicitly specified ssh-rsa in their s= sh_config would need to add rsa-sha2-256 and/or rsa-sha2-512 to their list. The majority of people using IPFire will not have any problems. Any that do w= ill likely have an issue in their ssh_config files that can be easily fixed. Regards, Adolf. On 30/09/2020 15:27, Michael Tremer wrote: > Hey Adolf, > >> On 29 Sep 2020, at 14:45, Adolf Belka wrote: >> >> Hi Michael, >> >> I don't believe it will be a problem from what I have read up about on thi= s topic. > Very good to hear. > >> The move to disabling the ssh-rsa signature by default is still for a futu= re (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 a= ll. > >> When it happens this will not change the rsa key itself. That stays the sa= me. It is the hash used for the signature format that's used during each auth= entication handshake that will have to be different. There are three signatur= e hashes used for rsa keys, ssh-rsa which is SHA1 based and rsa-sha2-256 and = rsa-sha2-512 which are both SHA2 based. >> >> Since openssh-7.2 the sha2 signatures have been available and in default s= etups the options are tried in descending order in the key exchange communica= tion, so rsa-sha2-512 first then rsa-sha2-256 and then ssh-rsa. The first one= available in both server and client will be used. Apparently some people mus= t be explicitly defining only ssh-rsa in their ssh_config file with HostKeyAl= gorithms. >> >> If the HostKeyAlgorithms is not specified in ssh_config then the default i= ncludes the sha2 options. > We do not explicitly change this anywhere on IPFire. > >> 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 specifie= d without the sha2 variants in ssh_config. Then the negotiation between their= client and the ipfire ssh server would fail. Updating their HostKeyAlgorithm= s line to include rsa-sha2-512 and rsa-sha2-256 would fix the problem and mak= e their signature format much more secure. > People who have that deliberately disabled probably have other issues. I am= more worries about people who run clients that don=E2=80=99t support the new= er ones. We will see. We cannot stop progress for a couple of people who do n= ot update their systems for forever. > >> Having said all the above, I think it would be good for someone else to al= so check this out to make sure that my interpretation and understanding is co= rrect. > I double checked. This looks very good. Thank you for looking into this at = this depth. Good job! > > -Michael > >> Regards, >> >> Adolf. >> >> >> On 29/09/2020 10:29, Michael Tremer wrote: >>> Good morning Adolf, >>> >>> Thank you for working on this. >>> >>> Did you have a look at the changes regarding retiring support for RSA-SHA= 1? Does that affect us in any way? >>> >>> Best, >>> -Michael >>> >>>> On 29 Sep 2020, at 08:21, Adolf Belka wrote: >>>> >>>> - 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 f= ile >>>> - No change to rootfiles >>>> - Installed on virtual ipfire testbed and ssh connection successfully op= erated >>>> Signed-off-by: Adolf Belka >>>> --- >>>> lfs/openssh | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/lfs/openssh b/lfs/openssh >>>> index 75210060e..5143f4154 100644 >>>> --- a/lfs/openssh >>>> +++ b/lfs/openssh >>>> @@ -24,7 +24,7 @@ >>>> >>>> include Config >>>> >>>> -VER =3D 8.3p1 >>>> +VER =3D 8.4p1 >>>> >>>> THISAPP =3D openssh-$(VER) >>>> DL_FILE =3D $(THISAPP).tar.gz >>>> @@ -40,7 +40,7 @@ objects =3D $(DL_FILE) >>>> >>>> $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE) >>>> >>>> -$(DL_FILE)_MD5 =3D 68d7527bf2672153ca47402f6489a1af >>>> +$(DL_FILE)_MD5 =3D 8f897870404c088e4aa7d1c1c58b526b >>>> >>>> install : $(TARGET) >>>> >>>> --=20 >>>> 2.28.0 >>>> --===============4615400394674648765==--