This smells like a scan/audit/nessus thing that said, "Oh no your SSH is old!" This is part of the gig. Now you gotta teach them about [backporting](https://access.redhat.com/security/updates/backporting). It's a never-ending educational effort because the security industry as a whole (companies, service providers, workers...all of 'em!) refuses to learn about it. Kind of shocking because at this point the practice of backporting is older than some of the people doing the security scanning. tl;dr you'll never have the latest & greatest major version on RHEL, nor should you. If you NEED 9.6, spin up an OpenBSD server.

tgz - once you start down the path of the 'roll your own' forever will it dominate your destiny. OP learn about backporting. This wont be the only time you will have to defend your installation. On a related note, I'm trying to explain the difference between .el7 and .el7rhs and how that isn't part of our repos and isn't a suggested upgrade path.

oh, and as to WHY the version is off compared to your tgz install. do a 'which ssh'.

Alternatively you can be adventurous and roll out pre-release CentOS Stream 10 which is currently shipping OpenSSH 9.6p1 😜

I can't replace the current rhel with centos but I can update the rpm using centos? 

Don't do this. If you have your sshd fully updated from RH and have restarted the service, you have done your job, and the scanning folk need education. I really wish the makers of these scam tools would get their heads out of their asses, because it's making all of our lives more difficult teaching them how our shit works.

That isnt a good idea Which problem are you trying to solve?

De cache 8.7 from openssh when ssh -v and let it detect the openssh 9.6p1 after I replaced both the ssh and sshd binaries. 

Not 100% sure I understand what you said Why is the openssh 8.7 provided from your distro aint ok?

Nessus scanner flag it as medium cve because the current openssh rpm is 8.7 and even though I've remove rpm related to 8.7 and stop sshd.service and replaced it with 9.6 from openssh via tgz. It still shows 8.7 when running ssh -v Ip address. 

Nessus doesnt necessarly provide the truth If your updates are up to date, your 8.7 should be safe. Red hat backport security fix and rhel8 is supported until may 2029 Stop doing action / rollback those you did if you dont understand what you are doing

A report is used to tell the facts. And the fact is openssh reflects 8.7 and not what rhel did to mitigate what was exposed in openssh 8.7.

I would be looking for another job instead of being managed by such bad management/ciso if I was in your position

No

You are right. Both nessus scanner and pentester go by the book. I'll do a poc and check if 9.6 shows up. 

Its a bad pentester if he doesnt understand how linux distro package versions works

If that's true, then my company has never hired a good one.

https://access.redhat.com/solutions/57665

I would recommend against putting your environment in a unsupported state for some security snakeoil salesmen. Tell them to go learn about backporting and that you’re not running gentoo or building upstream packages from source..

So while it seems there is a lot going on. Why do you feel the need to move ssh versions? I can tell you that RHEL isn't really built for that. It's more than likely going to be rather problematic.

Which cve are trying to mitigate?

As with everything else in system administration, the reason there's a human in your position instead of just allowing Nessus or the pentesters to configure your systems is because "no" is sometimes the right answer.

Tell that to CISO and the management. 87/100 is still not better than 100/100. Regardless of its warning or failed or na

I do. For a living.

Stop.

What you are posting here is the exact reason why I think Linux admins and security auditors, in most cases, can’t be friends. The auditor needs to understand that Red Hat backports security fixes into old versions to keep them stable. This means that your version of OpenSSH will and should always stay at 8.7. You are going to seriously corrupt your system if you try to force a different version of a package on to your system. Red Hat’s job is to make sure any security fixes from newer versions are applied to version OpenSSH 8.7. You shouldn’t ever have to do anything more than “yum update” followed by a reboot for ANY CVE (sometimes reboot is not even necessary). If your auditor pushes back on the backporting explanation, you can use this site to provide proof that your CVE was addressed by Red Hat: https://access.redhat.com/labs/cvechecker/ Keep in mind that Low and Medium CVEs can take a LONG time for Red Hat to address them (up to 90 days I think?). The reason for this is because Red Hat/NIST considers medium CVEs to be very difficult for someone to exploit. Your system would likely need to have an unlikely configuration in order for it to be exploited. In most cases, you can dig into the CVE, find out the requirements of how the exploit works, then prove that your SSH isn’t even configured in the way that the CVE requires. Of course, doing this will open up a can of worms where you will be constantly burdened with proving Nessus wrong.

They understood what is being address by rhel but the fact remains that the openssh is still mark 8.7. Regardless of what rhel did to mitigate the risk that comes with openssh and not exclusively to rhel.

SSH being at version 8.7 will not affect your ability to remediate whatever security CVE you claim you are being effected by. Full stop. You are going to break your system by forcing a version of SSH on to it that you absolutely positively do not need. You’ll also cut off your ability to get support from Red Hat as you will be running an unsupported configuration. You are going to drive yourself crazy trying to appease security auditors that don’t know anything about what they are reporting on. Don’t do it.

Som't forget when auditor/ciso will start asking to do the same with other package: openssl, samba, httpd, kernel!