How do i upgrade OPENSSH in esxi 7.0.3p from 8.8 tp 9.7 ????

[rr rra]

How do i upgrade OPENSSH in esxi 7.0.3p from 8.8 tp 9.7 ????

[loungehostmaste]

you don't - what makes you think you have any business to update specific software on a ESXi host?

[roadgeek]

I see this in my company all of the time. Compliance team, who just knows how to run scans, sends a Nessus scan report saying OpenSSH is out of date and needs to be updated. Management team, who just knows how to read scary words, pushes it to a poor worker to "fix". Worker, just trying to do their job, is following the letter of the Nessus report and trying to upgrade OpenSSH.

[loungehostmaste]

either fire the compliance team, educate them or just quit instead working in a setup full of morons

[JDMils_Interact]

If the request has passed thru this many levels and not one person has said "No, ESXi components can only be upgraded by the supplier's patches" then you have a problem in your company not with your vulnerabilities!

[Jim Dean]

Assuming OP is attempting to patch to mitigate below CVE:

https://nvd.nist.gov/vuln/detail/CVE-2024-39894

Not sure why you all had to be rude with your answers instead of simply stating, "You cannot update individual components of ESXi. You must wait for the next official release." I am in the same boat as OP and this is the top post on Google about resolving this CVE (which still isn't patched in 7.0.3q)

[loungehostmaste]

because it's common sense?

[Jim Dean]

To who, people with VCPs? Nearly any flavor of Linux, including Photon, you can manually update packages without using a vendor release. 

[loungehostmaste]

you don't update packages on a appliance - period

[Jim Dean]

You do what you have to do when the alternative is having your program shut down ¯\_(ツ)_/¯ 

[JadedEngineer]

Me: "You want me to what now?"
Sec: "You need to shut down those vulnerable systems..."
Me: "Uhhhh, no. Begins explaining the birds and the bees to Sec about what impact that command will have, before being rudely interrup-"
Sec: "MOOOOM HE WON'T DO WHAT WE TELL HIM TO!"
C-level: "It sure would be a shame to have to replace you if you don't get rid of those vulns..."
Me: "Ok. Done. Vulns remediated."
Sec/C-level: Shocked Pikachu - "Y EVRTING BORKE?"

Malicious compliance is a thing, as long as full CYA has been performed and you've made an honest effort to communicate clearly. At some point, your company is going to have to trust you to know what you're doing, they did hire you after all. And if they don't, I'd consider locating a new technology stack in another company to play with.

[Daniel Scasso]

Thanks for being the only one who actually understood the quest and explained properly the issue.

I'm on the same boat running 8U3 with the CVEs patched from last week and I still get this on my Nessus Scan.

Will have to wait for Broadcom to patch this for the CVE

[JDMils_Interact]

Firstly, why do you want to upgrade OPENSSH? Is there a vulnerability you wish to mitigate?

Secondly, ESXi should only be updated via official patches from Broadcom so if there IS a reason which Broadcom says it should be updated, it will come in a new patch release.

[Daniel Scasso]

My friend, best i could find so far is:

tdnf check-update - WIll check package updates

tdnf repolist - Will list available repos

tdnf makecache - Refreshes metadata cache

tdnf update - Apply available updates

I will run a Nessus Scan now and see if this fixed the issue

[Daniel Scasso]

tdnf install libssl-dev gcc g++ gdb cpp make cmake libtool libc6 autoconf automake pkg-config build-essential gettext

tdnf install libzstd1 zlib1g libssh-4 libssh-dev libssl3 libc6-dev libc6 libcrypt-dev

tdnf install netcat lsof wget diffutils

tdnf install zlib-devel

tdnf install openssl-devel

wget LINK_TO_TAR.gz

tar xvzf xxx.tar.gz

cd folder_from_tar.gz

./configure

make

make install

vi /etc/systemd/system/sshd.service

ADD:

[Unit]

Description=OpenSSH server daemon

After=network.target

[Service]

ExecStart=/usr/local/sbin/sshd -D

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

Restart=on-failure

[Install]

WantedBy=multi-user.target

sudo vi /etc/ssh/sshd_config

Change Port to 2222

sudo systemctl daemon-reload

sudo systemctl stop ssh.socket

sudo systemctl disable ssh.socket

sudo systemctl stop ssh

sudo systemctl disable ssh

sudo systemctl start sshd

sudo systemctl enable sshd

This worked for me, only issue is that OpenSSH 9.9p2 reports itself as 9.9 so Nessus will still complain on the Scan until they make 10.x versions or fix the issue of SSH not reporting the p2 part of the version.

[roadgeek]

This is such an incredibly bad idea, but I applaud your persistence in accomplishing it!

[Daniel Scasso]

I totally understand that, but if the "Main Quest" is to patch the OpenSSH (SSHD) service, then this is the only way. We know VMware will take ages to patch this package.

If security is the priority, then my solution/test is the way to go.

I took a full file backup and a Snapshot of the vCenter before I made any changes.

I took notes of all the steps, which gives me the opportunity to rollback OpenSSH if needed. The old version wasn't removed; it's just that the SSHd service now points to 9.9p2. If, by any chance, the old SSHd goes up, it will use port 2222 and avoid any conflict down the road.

So far no issues at all as I just replaced old sshd.service 9.x to sshd.service 9.9p2

I don't see any harmful impact on my home lab so far.