Disable the use of ssh-rsa with SHA-1

[vxgmichel]

Main information

Work Item Reference

XCPNG-3089

Context & Motivation

Disable the use of ssh-rsa with SHA-1 that was temporarily enabled in 9.8p1-1.2.2 (see #11 )

Release Target

• We already defined a release target with the release team.
• I haven't talked with the release team, but I have a proposed target.

Around the end of May to give users some time to see the warning coming with the previous update.

---

Release Notes and Documentation

Explain the change to users

Disable the use of ssh-rsa with SHA-1 that was temporarily enabled in 9.8p1-1.2.2

Attention points

N/A

Documentation update needed

• Yes
• No

---

Testing and regression avoidance

What tests have you performed?

Tested with @LucienLassalle :

• ssh-rsa (sha-1) with openssh6 client: permission denied as expected
• ssh-rsa with modern client: public key authentication successful
• ssh-ed25519 with modern client: public key authentication successful

What manual tests should be performed after the build, and by whom?

A good test would be to make sure that ssh clients ranging from version 7.2 to the latest version can connect to an xcp-ng server using public key authentication. Those tests can be run automatically using this script.

Note that manual tests had already been performed before the patch allowing sha-1 temporarily was added.

What's covered by the xcp-ng-tests test suite?

ssh-rsa with SHA-1 is not covered by xcp-ng-tests

What tests have been or will be added to CI for this change? If none, explain why.

None. We're only reverting to the original openssh code, which is tested by their test suite.

---

Xen Orchestra Impact

Does this affect existing features in Xen Orchestra, or add new features that could be useful?

• Yes
• No

[gduperrey]

Have you done a "scratch" build with Koji?

If not, you should do so (see the "XCP Handling hotfixes" procedure), and add the information as a comment on the PR.

[vxgmichel]

@gduperrey

Have you done a "scratch" build with Koji?

Done:

• Koji build Scratch (v8.3-incoming): https://koji.xcp-ng.org/taskinfo?taskID=104491

[gduperrey]

The PR template is full of "I'm not sure, help me". @LucienLassalle, could you go with Vincent to help him find the information he needs?

[stormi]

What's covered by the xcp-ng-tests test suite?

ssh-rsa with SHA-1 is not covered by xcp-ng-tests

There's a very important nuance here, that shouldn't escape reviewers' attention. The question is not just about testing the scope of the change that you have in mind, it's also about ensuring the we're not breaking any feature relying on this package. Imagine if for some reason we haven't foreseen, 10% of all customers, or more, can't connect to their hosts after the update because we unwillingly broken something unrelated to ssh-rsa. This would be catastrophic.

So the testing part must not be treated lightly.

Here, a first part of the response is that xcp-ng-tests relies on SSH, so we can at least say that SSH is not completely broken. It's up to you and the platform team to determine if more tests are required.

What manual tests should be performed after the build, and by whom?

None. Manual tests had already been performed when before the patch allowing sha-1 temporarily was added.

Tests before the build are good and necessary. Nothing guarantees 100% that the installed package after the build behaves exactly like what you have tested before the build. Maybe you've tested manually, but the patch doesn't apply exactly like you thought it would. Maybe there's a subtlety at RPM upgrade time. Maybe you haven't tested the right package, this kind of thing happens. We cannot assume that tests made before the build are a sufficient safety net.

[stormi]

Release Target

We already defined a release target with the release team.

What's the release target, then? It must be specified and verified by @xcp-ng-rpms/os-platform-release. That's in the template.

[LucienLassalle]

Release Target

We already defined a release target with the release team.

What's the release target, then? It must be specified and verified by @xcp-ng-rpms/os-platform-release. That's in the template.

It's my fault; I'm the one who told him it was fine.

It was agreed that users would have at least one month to change their SSH key/update their OpenSSH client.

The blog post is from the end of March, the package was released at the end of April, so ideally it should have been around the end of May.

[rzr]

What's covered by the xcp-ng-tests test suite?

ssh-rsa with SHA-1 is not covered by xcp-ng-tests

Here, a first part of the response is that xcp-ng-tests relies on SSH, so we can at least say that SSH is not completely broken. It's up to you and the platform team to determine if more tests are required.

We know from the forum that the package (before the warning), is working for openssh-7.2+ clients

Older clients are out of scope now, BTW I also note that a convenient legacy project is using 7.5:

https://github.com/christian-becker/ssh-legacy

We could do negative testing (using openssh-6?) but it would add complexity (dependency on a container runtime), which will not bring much value for the feature.

What manual tests should be performed after the build, and by whom?

I believe the mentioned developer tests could be done again once package land in incoming repo ?

Using openssh-7.2 (which is the minimal version supporting ssh-rsa using hash function).

The open question who will be the tester ? ideally someone different than the developer, I guess the bug tracker can be used for that.

[vxgmichel]

@stormi

So the testing part must not be treated lightly.

Following @rzr suggestion, I wrote a small bash script that automates the testing of public key authentication against several versions of the openssh client using those docker images:

± ./test-ssh-public-key-auth.sh 1.2.3.4
Enter root@1.2.3.4 password: 
[host:1.2.3.4 | ver:7.2_p2-r5  | key:rsa    ] PASS ✅
[host:1.2.3.4 | ver:7.2_p2-r5  | key:ed25519] PASS ✅
[host:1.2.3.4 | ver:7.9_p1-r6  | key:rsa    ] PASS ✅
[host:1.2.3.4 | ver:7.9_p1-r6  | key:ed25519] PASS ✅
[host:1.2.3.4 | ver:8.8_p1-r1  | key:rsa    ] PASS ✅
[host:1.2.3.4 | ver:8.8_p1-r1  | key:ed25519] PASS ✅
[host:1.2.3.4 | ver:9.9_p2-r0  | key:rsa    ] PASS ✅
[host:1.2.3.4 | ver:9.9_p2-r0  | key:ed25519] PASS ✅
[host:1.2.3.4 | ver:10.2_p1-r0 | key:rsa    ] PASS ✅
[host:1.2.3.4 | ver:10.2_p1-r0 | key:ed25519] PASS ✅
Matrix run complete  total: 10  passed: 10  failed: 0

We could use it for manual testing during the "after the build" testing phase.