Bugzilla – Bug 1222831
openssh 9.6 now uses the system crypto-policies
Last modified: 2024-05-15 11:21:37 UTC
The openssh package was updated in SLE15-SP6 to 9.6p1 which includes some changes to follow the system crypto policies as defined by the crypto-policies package. This means some cryptographic algorithms which are considered insecure will not be used by openssh. Among those, the most important change is probably that RSA keys with less than 2048 bits are not allowed anymore. For some users this might be a problem when connecting to existing servers if they only know the server from an old RSA host key that uses less than 2048 bits. This can be checked by doing: grep ssh-rsa ~/.ssh/known_hosts | ssh-keygen -lf - The first number for each line is the number of bits the key is using and the 3rd column is the hostname/ip used to connect, so after upgrading to SP6 (openssh 9.6p1) users won't be able to connect to hosts having a 1024 bit key if no other valid key is known for them. In order to fix this situation there are several solutions that can be applied. Before upgrading to SP6: 1) A patch will be submitted to openssh 8.4p1 in SLE-15-SP3 that changes the default value of UpdateHostkeys to be enabled (unless VerifyHostKeyDNS is enabled too, but that's disabled by default). This makes ssh update the known_hosts stored keys with all host keys published by the server (after it's authenticated with an existing key), which will allow to identify the server with a valid key after the insecure key stops working. Note that for this to solve the situation the user needs to update the system to this intermediate version, then ssh to the host having a 1024 rsa key and only then upgrade to SP6. 2) Manually adding the host keys to the known_host file with: ssh-keyscan hostname >> ~/.ssh/known_hosts Note however that this adds all host keys published by the ssh server unconditionally, without any verification so this should only be done if there's some other manual host verification. After upgrading to SP6: 1) The system crypto policy can be changed to allow to continue using now considered insecure algorithms. This can be done with: sudo update-crypto-policies --set LEGACY Note however that using insecure cryptographic algorithms is not safe, so the recommendation is to change the crypto policy to LEGACY just temporarily in order to allow the user to connect to the problematic hosts. Once the user connects once, ssh should update the known_host file with all keys published by the server so the crypto policy can be reverted back to the default secure policy with: sudo update-crypto-policies --set DEFAULT 2) Remove the invalid host key from the known_hosts file and connect to the server as if it was the first time, manually verifying the new host key.
Hi Antonio, I have taken the liberty to use and paraphrase from your text and added that to the release notes in https://gitlab.suse.de/documentation/release-notes-sles/-/commit/5155ef2d9161b1b87b665f857365edfe7083f98a Thanks!
SUSE-RU-2024:1366-1: An update that has four fixes can now be installed. Category: recommended (moderate) Bug References: 1216474, 1218871, 1221123, 1222831 Maintenance Incident: [SUSE:Maintenance:33331](https://smelt.suse.de/incident/33331/) Sources used: openSUSE Leap 15.3 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 openSUSE Leap Micro 5.3 (src): openssh-8.4p1-150300.3.37.1 openSUSE Leap Micro 5.4 (src): openssh-8.4p1-150300.3.37.1 openSUSE Leap 15.5 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro for Rancher 5.3 (src): openssh-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro 5.3 (src): openssh-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro for Rancher 5.4 (src): openssh-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro 5.4 (src): openssh-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro 5.5 (src): openssh-8.4p1-150300.3.37.1 Basesystem Module 15-SP5 (src): openssh-8.4p1-150300.3.37.1 Desktop Applications Module 15-SP5 (src): openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Manager Proxy 4.3 (src): openssh-8.4p1-150300.3.37.1 SUSE Manager Retail Branch Server 4.3 (src): openssh-8.4p1-150300.3.37.1 SUSE Manager Server 4.3 (src): openssh-8.4p1-150300.3.37.1 SUSE Enterprise Storage 7.1 (src): openssh-8.4p1-150300.3.37.1, openssh-askpass-gnome-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro 5.1 (src): openssh-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro 5.2 (src): openssh-8.4p1-150300.3.37.1 SUSE Linux Enterprise Micro for Rancher 5.2 (src): openssh-8.4p1-150300.3.37.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
It does not seem to work, I do not get keys updated when connecting using the old key.
It works only when both the host and the IP have the old key, when new key is available for the IP address the host key is not updated.