XCP-ng 8.3 updates announcements and testing

acebmxer

Built new Ubuntu 24.04 vm either fresh install from ISO or from cloudint i seem to be having issues. Existing vms seem to be fine. First thought was becuase vm was multiple nics add it might have caused networking issues. Powered off that vm and build new (first as fresh from iso. Second from cloudint) with 1 nic. Same issues...

Update - issues were with script that i updated prior to updating hosts. Fixed script all is working again. Didnt test script on new vm prior to updating host.

olivierlambert

I'm not sure it's the right topic for that, probably worth creating a new one

acebmxer

@olivierlambert Created new topic.

gduperrey

New update candidate for you to test!

A new update for the Xen packages is ready, which brings a significant improvement in live migration performance on AMD systems under heavy load, that we add to the previous batch of updates for a common publication.

Maintenance updates

xen: Improve migration performance on AMD systems under heavy load.

Test on XCP-ng 8.3

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

Versions:

xen: 4.17.6-4.1.xcpng8.3

What to test

Normal use and anything else you want to test. If you have a pool with AMD processors, we're interested in your feedback regarding live migration under heavy load.

Test window before official release of the updates

~4/5 days

Andrew

@gduperrey The new OpenSSL/SSH blocks existing/working RSA keys from older SSH clients. While you can still use a password for SSH, it will block old keys from working which will break things (not good for existing LTS installs). To maintain compatibility add PubkeyAcceptedAlgorithms +ssh-rsa to /etc/ssh/sshd_config

flakpyro

@gduperrey Tested this on the same hosts i already have running the testing updates from earlier. No issues. Mixture of AMD and Intel.

gduperrey

@Andrew I just pinged Philippe (rzr) internally to ask him to look into this

rzr

@Andrew said:

@gduperrey The new OpenSSL/SSH blocks existing/working RSA keys from older SSH clients. While you can still use a password for SSH, it will block old keys from working which will break things (not good for existing LTS installs). To maintain compatibility add PubkeyAcceptedAlgorithms +ssh-rsa to /etc/ssh/sshd_config

Hi @andrew, thank you for your feedback, the fallback option you're suggesting will work but it will downgrade the security of your system, we suggested to update clients:

"Note that older ssh-clients (with weak ciphers) will need to update, if connection is rejected."

Let me make it more explicit that older keys should be also refreshed:

  ssh-keygen # To generate new $identity_file 
  ssh-copy-id \
        -i $identity_file \
        -o HostKeyAlgorithms=+ssh-rsa \
        -o PubkeyAcceptedAlgorithms=+ssh-rsa \
        $user@$host
  ssh $user@$host

Ideally this can be done before the update, but let's us think if we have a better strategy to provide a smoother experience, meanwhile if anyone is curious please check:

https://www.openssh.org/releasenotes.html

https://www.openssh.org/txt/release-8.8

"We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519)."

https://datatracker.ietf.org/doc/html/rfc8332

As I understand, RSA is safe unless it was coupled with SHA1 hash function which was then decoupled in later versions (and then obsoleted in V_8_7_P1-4-g234475025 with https://github.com/openssh/openssh-portable/commit/2344750250247111a6c3c6a4fe84ed583a61cc11 "The use of RSA/SHA1 can be re-enabled by adding "ssh-rsa" to the
PubkeyAcceptedAlgorithms directives on the client and server.") .

Regen keys will be needed, better sooner than later, meanwhile we could support weak ~~keys~~ clients during a short (TBD) deprecation period.

PS: this post may be updated

0

djmdjm committed to openssh/openssh-portable

upstream: After years of forewarning, disable the RSA/SHA-1

signature algorithm by default. It is feasible to create colliding SHA1
hashes, so we need to deprecate its use.

RSA/SHA-256/512 remains available and will be transparently selected
instead of RSA/SHA1 for most SSH servers released in the last five+
years. There is no need to regenerate RSA keys.

The use of RSA/SHA1 can be re-enabled by adding "ssh-rsa" to the
PubkeyAcceptedAlgorithms directives on the client and server.

ok dtucker deraadt

OpenBSD-Commit-ID: 189bcc4789c7254e09e23734bdd5def8354ff1d5

stormi

Although disabling ssh-rsa is the right thing to do from a security perspective, we'll see what we can do to smoothen the transition.

psafont

@rzr said:

Hi @andrew, thank you for your feedback, the fallback option you're suggesting will work but it will downgrade the security of your system, we suggested to update clients:

If users need to take action, I would rather recommend users to do something that raises the security floor, like generating new keys with newer, future-looking ciphers, like ed25519:

ssh-keygen -t ed25519 -C "<email>"
for server in $servers do ; ssh-copy-id $server; done