Upgrade openssh-serer version 7.9p1 in rhel 7.4

Latest response


We have request from security team that openssh-server that is included in our RHEL 7.4 (openssh-server7.4) is vulnerable and need to be upgraded to latest version (openssh-server_7.9p1).

I checked repositories and found that latest available version is only 7.4 and no update info for this specific case.

Can you advice what to do in this case.
Is there some version of RPM available on RHEL source repositories ?

Best Regards
Kenan R.


Hi Kenan,

The latest stable version of openssh-server available from the Red Hat repositories for RHEL 7 is 7.4p1 and, the latest beta version available from the Red Hat repositories for RHEL 8 is 7.8p1 ... so if you want to install openssh-server 7.9p1 : there is currently one option I'd suggest ... you can download the latest stable version 7.9p1 of openssh from the fedora project and install it manually. :)


I recommend against installing Fedora packages on a RHEL system. It's not a sustainable upgrade path. Eventually Fedora upgrades its glibc while RHEL doesn't, so you cannot install Fedora packages on that RHEL version anymore. Then you're left with very old Fedora packages and no further upgrade path. Stick to the RHEL distro packages.

Hi Jamie,

I agree - yes, it is better to stick with Red Hat packages, fedora packages of course would have to be updated manually. glibc from another distro is an example where I also would recommend against installing on RHEL. But in many other cases fedora packages work perfectly fine (as a workaround), the only downside is that this is not supported by Red Hat, as I told Kenan yesterday (see below). :)


Ah, I have not explained clearly.

I'm not talking about updating the glibc package, I'm talking about Fedora updating its glibc, which is a dependency of other packages. Eventually you won't be able to install Fedora packages on RHEL anymore because of this.

Here's an example. Go install a RHEL 6.0 system. That openssh package is probably vulnerable to a few things. So install the openssh package from Fedora 12. Now install the openssh package from Fedora 13. Now install the openssh package from Fedora 14. So far you are updating your OpenSSH version successfully.

Now try to install the openssh package from Fedora 15. That Fedora release updated the glibc to something which is not compatible with RHEL6, so now you won't be able to install Fedora packages anymore. The F15-onwards packages need a glibc later than what RHEL6 can provide.

You're left with a RHEL6 system with Fedora 14 OpenSSH, and no upgrade path.

Meanwhile, the RHEL6 OpenSSH package continues to receive security updates well beyond the lifespan of Fedora 14.

Such a system would have been better sticking with the RHEL package.

So you can see, installing Fedora packages on RHEL to receive security updates eventually becomes a dead end. Don't do it.

Thank you for your excellent explanation, Jamie ! :) Not to be misunderstood - I definitely do NOT
recommend to install external packages on RHEL, the opposite is true : I generally recommend to
stick with packages from the Red Hat repositories ... as you can see in many other posts from me.
What I wanted to say is that sometimes there are situations where you need to find a workaround.

Example from my own set up : I am using dirdiff since many years and appreciate the convenience
of this "tiny" backup tool. As it is not available from Red Hat or EPEL, I have installed the package from openSUSE. Of course, one has to know what he's doing and if it is safe, without breaking the RHEL operating system. Thanks again for clarifying what you meant and for the good explanation.


Oh Kenan, what I forgot to mention ... this workaround is not supported by Red Hat of course, you are doing it on your own risk. :)


Thanks a lot Christian.

You're welcome, Kenan ! :)

Hi Kenan,

If the vulnerabilities that your security team reports are critical, maybe you should report them to Red Hat.

Once can check which bugs were resolved in the current RPM by Red Hat:

# rpm -q --changelog openssh-server 

You can also verify the current CVE status for openssh at Red Hat:



Dusan Baljevic (amateur radio VK2COT)

This is the correct answer.

We don't often upgrade package versions in RHEL, but we do important backport security fixes from later versions to the RHEL version. This is discussed further at:

So forget the fact that "version number X is vulnerable" and instead focus on the actual vulnerability and its fix. Usually a vulnerability is assigned a CVE so you can look up each one and see in which RHEL package version it's fixed, or at least some mitigation steps, or if the RHEL package is even vulnerable to that error in the first place.


What you think about compiling openssh from source code ? Is there some source RPMs for version openssh-server_7.9p1 that can be used ?

Best Regards Kenan R.

Hi Kenan,

Why would you want to do this ? It makes no difference regarding the consequences which Jamie pointed out. :)


So when they fix it in RHEL 8 it will be backported to earlier versions?


I checked the changelog for openssh and the last change was made was over a year ago:

"017-11-24 Jakub Jelen jjelen@redhat.com - 7.4p1-16 + 0.10.3-2 - Fix for CVE-2017-15906 (#1517226)"

If you check the RH link below they say: "Red Hat Product Security has rated this issue as having Low severity. An attacker could use this flaw to determine whether given usernames exist or not on the server, but no further information is disclosed and there is no availability or integrity impact. A future update may address this issue." Further down it states "Will not fix".


The NVD however rates it Medium severity. https://nvd.nist.gov/vuln/detail/CVE-2018-15473

In the meantime the company I work for runs vulnerability scans which are flagging our RHEL systems for this vulnerability as a "Medium severity" and advising to upgrade of OpenSSH 7.8 or later.

Thanks, Mark

So when they fix it in RHEL 8 it will be backported to earlier versions?

There is no guarantee that fixes will be backported. If a fix is important to you, Open a support case.