* Re: [PATCH] openssh: Update to 8.4p1 [not found] <90A5E269-F041-435D-83F8-23AB30B841A4@ipfire.org> @ 2020-10-01 12:17 ` Adolf Belka 2020-10-02 10:15 ` Michael Tremer 0 siblings, 1 reply; 5+ messages in thread From: Adolf Belka @ 2020-10-01 12:17 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 5628 bytes --] 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 which has been able to clarify and confirm things. - The deprecation notice is related to the key signature algorithm, not the key type. - 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, 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 concerns about losing RSA. Neither of the following apply to the IPFire ssh server so there is no problem for the deprecated signature algorithm for IPFire. - Openssh servers that are older than 7.4 would need to upgrade to be able to use the sha2 signature algorithms rsa-sha2-256 & rsa-sha2-512. - Openssh servers where ssh-rsa has been explicitly specified in sshd_config would need to add rsa-sha2-256 and/or rsa-sha2-512 to their list. Users of up-to-date default configured ssh clients will have no problems connecting to the IPFire ssh server and will not need to generate new keys, change their configuration or migrate to different key types. - 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. - Users that have explicitly specified ssh-rsa in their ssh_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 will 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 <ahb.ipfire(a)gmail.com> wrote: >> >> Hi Michael, >> >> I don't believe it will be a problem from what I have read up about on this topic. > Very good to hear. > >> The move to disabling the ssh-rsa signature by default is still for a future (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. > >> When it happens this will not change the rsa key itself. That stays the same. It is the hash used for the signature format that's used during each authentication handshake that will have to be different. There are three signature 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 setups the options are tried in descending order in the key exchange communication, 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 must be explicitly defining only ssh-rsa in their ssh_config file with HostKeyAlgorithms. >> >> 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. > >> 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 specified without the sha2 variants in ssh_config. Then the negotiation between their client and the ipfire ssh server would fail. Updating their HostKeyAlgorithms line to include rsa-sha2-512 and rsa-sha2-256 would fix the problem and make 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’t support the newer ones. We will see. We cannot stop progress for a couple of people who do not update their systems for forever. > >> Having said all the above, I think it would be good for someone else to also check this out to make sure that my interpretation and understanding is correct. > 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-SHA1? Does that affect us in any way? >>> >>> Best, >>> -Michael >>> >>>> On 29 Sep 2020, at 08:21, Adolf Belka <ahb.ipfire(a)gmail.com> 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 file >>>> - No change to rootfiles >>>> - Installed on virtual ipfire testbed and ssh connection successfully operated >>>> Signed-off-by: Adolf Belka <ahb.ipfire(a)gmail.com> >>>> --- >>>> 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 = 8.3p1 >>>> +VER = 8.4p1 >>>> >>>> THISAPP = openssh-$(VER) >>>> DL_FILE = $(THISAPP).tar.gz >>>> @@ -40,7 +40,7 @@ objects = $(DL_FILE) >>>> >>>> $(DL_FILE) = $(DL_FROM)/$(DL_FILE) >>>> >>>> -$(DL_FILE)_MD5 = 68d7527bf2672153ca47402f6489a1af >>>> +$(DL_FILE)_MD5 = 8f897870404c088e4aa7d1c1c58b526b >>>> >>>> install : $(TARGET) >>>> >>>> -- >>>> 2.28.0 >>>> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] openssh: Update to 8.4p1 2020-10-01 12:17 ` [PATCH] openssh: Update to 8.4p1 Adolf Belka @ 2020-10-02 10:15 ` Michael Tremer 0 siblings, 0 replies; 5+ messages in thread From: Michael Tremer @ 2020-10-02 10:15 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 5965 bytes --] Great! Thank you for clarifying this. I will try to summarise this for the change log. -Michael > On 1 Oct 2020, at 13:17, Adolf Belka <ahb.ipfire(a)gmail.com> wrote: > > 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 which has been able to clarify and confirm things. > > - The deprecation notice is related to the key signature algorithm, not the key type. > > - 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, 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 concerns about losing RSA. > > > Neither of the following apply to the IPFire ssh server so there is no problem for the deprecated signature algorithm for IPFire. > > - Openssh servers that are older than 7.4 would need to upgrade to be able to use the sha2 signature algorithms rsa-sha2-256 & rsa-sha2-512. > > - Openssh servers where ssh-rsa has been explicitly specified in sshd_config would need to add rsa-sha2-256 and/or rsa-sha2-512 to their list. > > > Users of up-to-date default configured ssh clients will have no problems connecting to the IPFire ssh server and will not need to generate new keys, change their configuration or migrate to different key types. > > - 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. > > - Users that have explicitly specified ssh-rsa in their ssh_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 will 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 <ahb.ipfire(a)gmail.com> wrote: >>> >>> Hi Michael, >>> >>> I don't believe it will be a problem from what I have read up about on this topic. >> Very good to hear. >> >>> The move to disabling the ssh-rsa signature by default is still for a future (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. >> >>> When it happens this will not change the rsa key itself. That stays the same. It is the hash used for the signature format that's used during each authentication handshake that will have to be different. There are three signature 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 setups the options are tried in descending order in the key exchange communication, 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 must be explicitly defining only ssh-rsa in their ssh_config file with HostKeyAlgorithms. >>> >>> 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. >> >>> 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 specified without the sha2 variants in ssh_config. Then the negotiation between their client and the ipfire ssh server would fail. Updating their HostKeyAlgorithms line to include rsa-sha2-512 and rsa-sha2-256 would fix the problem and make 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’t support the newer ones. We will see. We cannot stop progress for a couple of people who do not update their systems for forever. >> >>> Having said all the above, I think it would be good for someone else to also check this out to make sure that my interpretation and understanding is correct. >> 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-SHA1? Does that affect us in any way? >>>> >>>> Best, >>>> -Michael >>>> >>>>> On 29 Sep 2020, at 08:21, Adolf Belka <ahb.ipfire(a)gmail.com> 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 file >>>>> - No change to rootfiles >>>>> - Installed on virtual ipfire testbed and ssh connection successfully operated >>>>> Signed-off-by: Adolf Belka <ahb.ipfire(a)gmail.com> >>>>> --- >>>>> 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 = 8.3p1 >>>>> +VER = 8.4p1 >>>>> >>>>> THISAPP = openssh-$(VER) >>>>> DL_FILE = $(THISAPP).tar.gz >>>>> @@ -40,7 +40,7 @@ objects = $(DL_FILE) >>>>> >>>>> $(DL_FILE) = $(DL_FROM)/$(DL_FILE) >>>>> >>>>> -$(DL_FILE)_MD5 = 68d7527bf2672153ca47402f6489a1af >>>>> +$(DL_FILE)_MD5 = 8f897870404c088e4aa7d1c1c58b526b >>>>> >>>>> install : $(TARGET) >>>>> >>>>> -- >>>>> 2.28.0 >>>>> ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] openssh: Update to 8.4p1 @ 2020-09-29 7:21 Adolf Belka 2020-09-29 8:29 ` Michael Tremer 0 siblings, 1 reply; 5+ messages in thread From: Adolf Belka @ 2020-09-29 7:21 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 868 bytes --] - 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 operated Signed-off-by: Adolf Belka <ahb.ipfire(a)gmail.com> --- 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 = 8.3p1 +VER = 8.4p1 THISAPP = openssh-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = 68d7527bf2672153ca47402f6489a1af +$(DL_FILE)_MD5 = 8f897870404c088e4aa7d1c1c58b526b install : $(TARGET) -- 2.28.0 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] openssh: Update to 8.4p1 2020-09-29 7:21 Adolf Belka @ 2020-09-29 8:29 ` Michael Tremer 2020-09-29 13:45 ` Adolf Belka 0 siblings, 1 reply; 5+ messages in thread From: Michael Tremer @ 2020-09-29 8:29 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 1225 bytes --] Good morning Adolf, Thank you for working on this. Did you have a look at the changes regarding retiring support for RSA-SHA1? Does that affect us in any way? Best, -Michael > On 29 Sep 2020, at 08:21, Adolf Belka <ahb.ipfire(a)gmail.com> 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 file > - No change to rootfiles > - Installed on virtual ipfire testbed and ssh connection successfully operated > Signed-off-by: Adolf Belka <ahb.ipfire(a)gmail.com> > --- > 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 = 8.3p1 > +VER = 8.4p1 > > THISAPP = openssh-$(VER) > DL_FILE = $(THISAPP).tar.gz > @@ -40,7 +40,7 @@ objects = $(DL_FILE) > > $(DL_FILE) = $(DL_FROM)/$(DL_FILE) > > -$(DL_FILE)_MD5 = 68d7527bf2672153ca47402f6489a1af > +$(DL_FILE)_MD5 = 8f897870404c088e4aa7d1c1c58b526b > > install : $(TARGET) > > -- > 2.28.0 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] openssh: Update to 8.4p1 2020-09-29 8:29 ` Michael Tremer @ 2020-09-29 13:45 ` Adolf Belka 0 siblings, 0 replies; 5+ messages in thread From: Adolf Belka @ 2020-09-29 13:45 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 2971 bytes --] Hi Michael, I don't believe it will be a problem from what I have read up about on this topic. The move to disabling the ssh-rsa signature by default is still for a future (undefined) release. When it happens this will not change the rsa key itself. That stays the same. It is the hash used for the signature format that's used during each authentication handshake that will have to be different. There are three signature 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 setups the options are tried in descending order in the key exchange communication, 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 must be explicitly defining only ssh-rsa in their ssh_config file with HostKeyAlgorithms. If the HostKeyAlgorithms is not specified in ssh_config then the default includes the sha2 options. 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 specified without the sha2 variants in ssh_config. Then the negotiation between their client and the ipfire ssh server would fail. Updating their HostKeyAlgorithms line to include rsa-sha2-512 and rsa-sha2-256 would fix the problem and make their signature format much more secure. Having said all the above, I think it would be good for someone else to also check this out to make sure that my interpretation and understanding is correct. 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-SHA1? Does that affect us in any way? > > Best, > -Michael > >> On 29 Sep 2020, at 08:21, Adolf Belka <ahb.ipfire(a)gmail.com> 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 file >> - No change to rootfiles >> - Installed on virtual ipfire testbed and ssh connection successfully operated >> Signed-off-by: Adolf Belka <ahb.ipfire(a)gmail.com> >> --- >> 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 = 8.3p1 >> +VER = 8.4p1 >> >> THISAPP = openssh-$(VER) >> DL_FILE = $(THISAPP).tar.gz >> @@ -40,7 +40,7 @@ objects = $(DL_FILE) >> >> $(DL_FILE) = $(DL_FROM)/$(DL_FILE) >> >> -$(DL_FILE)_MD5 = 68d7527bf2672153ca47402f6489a1af >> +$(DL_FILE)_MD5 = 8f897870404c088e4aa7d1c1c58b526b >> >> install : $(TARGET) >> >> -- >> 2.28.0 >> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-10-02 10:15 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <90A5E269-F041-435D-83F8-23AB30B841A4@ipfire.org>
2020-10-01 12:17 ` [PATCH] openssh: Update to 8.4p1 Adolf Belka
2020-10-02 10:15 ` Michael Tremer
2020-09-29 7:21 Adolf Belka
2020-09-29 8:29 ` Michael Tremer
2020-09-29 13:45 ` Adolf Belka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox