openssh: Update to 8.4p1

  - 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@gmail.com>
---
 lfs/openssh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

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@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@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
>
  

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@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@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
>>
  

Hey Adolf,

> On 29 Sep 2020, at 14:45, Adolf Belka <ahb.ipfire@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@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@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
>>>
  

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@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@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@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
>>>>
  

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@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@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@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@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
>>>>>