search

dev-sec / ssh-baseline

DevSec SSH Baseline - InSpec Profile
https://dev-sec.io/baselines/ssh/
Apache License 2.0
283 stars 78 forks source link

Added OpenSSH 8.5/8.5p1 KexAlgorithms Support #192

Closed lonkey closed 3 years ago

lonkey commented 3 years ago

OpenSSH 8.5 was released on 2021-03-03 and was officially made available for Arch Linux on 2021-03-04 17:09 UTC. The previous key exchange method sntrup4591761x25519-sha512@tinyssh.org is replaced with sntrup761x25519-sha512@openssh.com in this release. Consequently, the ssh_crypto.rb library has to be updated.

micheelengronne commented 3 years ago

Ok, but what is the state of usage on that ? I mean, if the majority of Arch users still use a version previous to this one (and according to the date I think so), we should ensure compatibility with them for a certain amount of time.

lonkey commented 3 years ago

Can you add a release check to ensure compatibility with previous Arch versions ?

As proposed, compatibility with older OpenSSH versions on Arch Linux is now ensured.

Ok, but what is the state of usage on that ? I mean, if the majority of Arch users still use a version previous to this one (and according to the date I think so), we should ensure compatibility with them for a certain amount of time.

Since Arch Linux is not the only supported rolling release system, compatibility should also be ensured on the other platforms as a precautionary measure, shouldn't it? So far, openSUSE Tumbleweed and Alpine have not released an update to OpenSSH 8.5, but this is probably only a matter of a few weeks/days. Should I include an OpenSSH version match for these platforms as well?

micheelengronne commented 3 years ago

Ok, but what is the state of usage on that ? I mean, if the majority of Arch users still use a version previous to this one (and according to the date I think so), we should ensure compatibility with them for a certain amount of time.

Since Arch Linux is not the only supported rolling release system, compatibility should also be ensured on the other platforms as a precautionary measure, shouldn't it? So far, openSUSE Tumbleweed and Alpine have not released an update to OpenSSH 8.5, but this is probably only a matter of a few weeks/days. Should I include an OpenSSH version match for these platforms as well?

Indeed, it would be very great ! Thank you.

lonkey commented 3 years ago
Done TBD
Arch Alpine
Fedora openSUSE

For most platforms (including Alpine and openSUSE), the operating system version is used to derive the OpenSSH version. Why is the OpenSSH version itself not primarily used for this?

https://github.com/dev-sec/ssh-baseline/blob/d2346c96d7c69b1de42e6f4894fae3d600c70781/libraries/ssh_crypto.rb#L110

I'm asking because the current master already uses a subversion to determine the correct key exchange algorithms for Alpine and openSUSE. I want to avoid making the change unnecessarily complicated, confusing or not being in line with best practice.

schurzi commented 3 years ago

Why is the OpenSSH version itself not primarily used for this?

That may be because of RedHat, they like to backport stuff without changing the version number of packages.

see https://github.com/dev-sec/ssh-baseline/blob/d2346c96d7c69b1de42e6f4894fae3d600c70781/libraries/ssh_crypto.rb#L157-L161 and https://www.redhat.com/en/blog/what-backporting-and-how-does-it-apply-rhel-and-other-red-hat-products

lonkey commented 3 years ago

That may be because of RedHat, they like to backport stuff without changing the version number of packages.

I have now grouped the validation of the key exchange algorithms for Alpine, Arch, Fedora and openSUSE, as no difference seems to exist there due to the lack of backports. Finally, I tested my changes using Vagrant for all 4 operating systems on different versions and could not find any error. So everything should be fine now.

However, all CI/CD verifications fail. According to the details, this does not seem to be due to my code changes.

schurzi commented 3 years ago

However, all CI/CD verifications fail. According to the details, this does not seem to be due to my code changes.

No, the failures are not because of you. I'm trying to find out, why tihs happens. It started a few days ago and I cannot pinpoint any change or problem with our repo or workflow. My guess would be something with the Gem source (packagecloud.io). I will need to do some further investigation.

schurzi commented 3 years ago

I found a fix for the Ci issue. #194

If you do a merge or rebase things will be working.

lonkey commented 3 years ago

If you do a merge or rebase things will be working.

Done.

micheelengronne commented 3 years ago

Let's go !!