Hello,
Rocky Linux 9.5 upgraded openssl libs to 3.2.2
For us who cannot run dnf update for various reasons, this causes a lot of issues if only openssl is updated. It seems that Opnessl promises ABI compatability as long as .so version is the same, but some packages explicitly check openssl version and refuse to run, for example, updating only opnessl on 9.4 or earlier causes such issues:
openssh does not accept new connections, it fails with the error:
OpenSSL version mismatch. Built against 30000070, you have 30200020
radiusd (at least compiled from source) fails with a similar error:
libssl version mismatch. built: 30000070 linked: 30200020
Updating sshd and recompiling radiusd solves the issue.
So the main question is, how dangerous is it to run a system with updated ssl without running a full dnf/yum update. As far as I can see only a few packages (openssh, radiusd) explicitly check openssl versions, and others trust that updated openssl ABI will work.
Briefly, its dangerous. Its important to see the technical system as a conceptual system where every component brings their part in to make the technical system secure. This is also what was validated. Everything else is not verified.
It is dangerous to run your system(s) like that. Cherry picking updates or rebuilding only against a subset of updated packages is unsupported and will likely lead to system instability.
You are highly recommended to update your system to full.
This upgrade is quite catastrophic. On the server, when installing the git software on Rocky, it forcibly upgrades openssl and openssl-libs, causing ssh to fail. The only solution is to reinstall the system. It’s simply a disaster.
Unfortunately this is because you are cherry picking updates or not updating your system at all, and choosing to install packages that update others (as required). There should be no expectation that an update to a core package like openssl would not cause issues for packages dependent on it, such as openssh.
Reinstalling a system should not be an option. Fully updating your system is the better choice here. My recommendation is to fully update your system to what is supported by the project, which as of this writing, is 9.5.
Under normal circumstances, if user password authentication is enabled, it is possible to proceed with the dnf upgrade. However, on Oracle Cloud servers, password authentication is disabled by default, and only SSH key authentication is supported. This can result in being unable to access the system. Ultimately, reinstalling the system becomes the only solution. To prevent this issue, the first thing I do after reinstalling the system is to configure a remote user with password authentication, and then proceed with the dnf update.
Here is how I did it:
1. Do not exit or close the terminal during the operation.
2. Start the cockpit.socket service in Rocky Linux and open port 9090. The port needs to be opened on both the server and Oracle.
3. Set a password for the Oracle login user: passwd <username>.
4. Ensure that http://<ip>:9090 can be accessed and logged into using the credentials set earlier.
5. It is now safe to execute dnf update, as alternative login methods are available even if there are issues with OpenSSL.
I don’t mean to hijack this post, but I just created my forum account so I can’t make my own posts yet.
I’ve been experiencing a somewhat similar issue (OpenSSL version mismatch. Built against 30000070, you have 30200020). I typically use an Azure template to deploy my Rocky servers, but something’s changed; I’m no longer able to SSH to the boxes once they’re deployed. My workaround has been to connect via console and dnf install openssh-server.
My issue is that if I manually create the server using the Azure wizard with the ‘official’ Rocky 9 image, I don’t have this problem, and I’m able to SSH immediately upon deployment. My template has the following properties specified: publisher resf | offer rockylinux-x86_64 | sku 9-base | version latest. Does anyone have any info on how I can fix my template?