Openssh 7.2p2 compatability with RHEL 6.8

Latest response

Due to various CVEs causing security scans to flag openssh, can I upgrade from current 5.3p1 to 7.2p2 without causing openssh to experience issues or to stop working altogether?

Responses

That's a huge deflection...... There would be a lot of changes made to the 7.2p2 version of the openssh package when compared with 5.3p1. Also, the latest package that is available as per Red Hat is "openssh-7.4p1-5.el7.x86_64.rpm" which is built for RHEL7.x, so the latest openssh package to which you are planning to upgrade would not be suitable for your build (RHEL6.x). Beware, there is a dependency that creep in which I could see that it needs "glibc" of higher version and other packages which again a big mess that is not easy to fix. I just tried the "7.4p1" to check on my vm running RHEL 6.8 and this is what i see:

[root@ansible-host tmp]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.8 (Santiago)
[root@ansible-host tmp]# 
[root@ansible-host tmp]# rpm -q openssh
openssh-5.3p1-117.el6.x86_64
[root@ansible-host tmp]# 
[root@ansible-host tmp]# rpm -qpR openssh-7.4p1-5.el7.x86_64.rpm 
/bin/sh  
/sbin/nologin  
audit-libs >= 1.0.8
config(openssh) = 7.4p1-5.el7
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.14)(64bit)  
libc.so.6(GLIBC_2.17)(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libc.so.6(GLIBC_2.8)(64bit)  
libcrypt.so.1()(64bit)  
libcrypto.so.10()(64bit)  
libcrypto.so.10(OPENSSL_1.0.1)(64bit)  
libcrypto.so.10(OPENSSL_1.0.1_EC)(64bit)  
libcrypto.so.10(libcrypto.so.10)(64bit)  
libdl.so.2()(64bit)  
libdl.so.2(GLIBC_2.2.5)(64bit)  
libfipscheck.so.1()(64bit)  
liblber-2.4.so.2()(64bit)  
libldap-2.4.so.2()(64bit)  
libresolv.so.2()(64bit)  
libresolv.so.2(GLIBC_2.2.5)(64bit)  
libselinux >= 1.27.7
libutil.so.1()(64bit)  
libz.so.1()(64bit)  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)  
rpmlib(PayloadIsXz) <= 5.2-1

[root@ansible-host tmp]# rpm -Uvh openssh-7.4p1-5.el7.x86_64.rpm 
error: Failed dependencies:
    libc.so.6(GLIBC_2.14)(64bit) is needed by openssh-7.4p1-5.el7.x86_64
    libc.so.6(GLIBC_2.17)(64bit) is needed by openssh-7.4p1-5.el7.x86_64
    selinux-policy < 3.13.1-92 conflicts with openssh-7.4p1-5.el7.x86_64
    openssh = 5.3p1-117.el6 is needed by (installed) openssh-clients-5.3p1-117.el6.x86_64
    openssh = 5.3p1-117.el6 is needed by (installed) openssh-server-5.3p1-117.el6.x86_64
    openssh = 5.3p1-117.el6 is needed by (installed) openssh-askpass-5.3p1-117.el6.x86_64

Rather, you may prefer to check out those CVEs in detail and see the reason why openssh is being flagged. All the best!!!

The point of a CVE isn't a blanket "you need to upgrade to opensource version X.Y.Z", it's to inform you what vendor version you need to run if you're running a particular vendor's release-stream.

In general, if you're using a properly configured scanner, it will include in its flagged issues, link-outs to appropriate package versions. That is, if your scanner is properly calibrated to scan a Red Hat 6.x system, it will provide guidance on what minimum EL6 openssh RPM you need to install.

While you can download, compile and install your own software to replace vendor-furnished content, it's typically not advised to do so. Your knock-on effects from following that path can increase your overall administrative overhead for a given system or set of systems' lifecycle. In fact, since following such a path means that you can't just do a yum update and ensure all your software is brought up to latest-and-greatest, you likely reduce the security of your system(s) over their lifetime by switching to "roll your own".

In general, what you want to limit your "roll your own" stuff to is content for which there is no vendor-furnished packagings.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.