Openssh 4.4p1

[Qcheck]

I did download the openssh-4.4p1 from openssh website, to fix the vulnerability, as solution says to update to 4.4 version. I thought 4.4 will fix the issue by updating the system with the latest version. Since it is not a rpm package, I did configure and install on my system which already has the rpm packages for the following:
[root@server dev]# rpm -qa| grep openssh
openssh-askpass-4.3p2-41.el5
openssh-clients-4.3p2-41.el5
openssh-server-4.3p2-41.el5
openssh-4.3p2-41.el5

So when I run # ssh -V
OpenSSH_4.4p1, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008.

Restarted the ssh service. Ran the scan and still shows the vulnerability fix.
So I thought may be the scan software still found the 4.3p2 version, it must have flagged. So I removed those packages. Now I can't restart the sshd. However "ssh -V" shows the 4.4p1 version. So how can I refresh the server to take the new version which shows in the "ssh -V" command. Please assist.

[Steven E. Protter]

Shalom,

uname -a
# please post.

To assist we'd need to know the Linux distribution in use. If this is rhel, you have not updated correctly.

SEP

[Qcheck]

Sorry forgot the version to mention.

[root@Server ~]# uname -a
Linux cognos 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[root@Server ~]#

[Matti_Kurkela · Accepted solution]

You say your "openssh-4.4p1" is not a RPM package? Did you compile it from the source code?

If you compiled and installed it with no compile-time configuration options (i.e. "configure; make; make install" or equivalent commands), then the client installed to /usr/local/bin and the server to /usr/local/sbin by default. Source installations usually don't automatically install start-up scripts, because it's traditionally the sysadmin's job to tailor the scripts to the local system environment. When using RPMs, this task is automated.

The script you used to restart the ssh service is most likely still using the RPM-installed version of sshd in /usr/sbin.

I guess you're seeing the newer ssh client because /usr/local/bin is before /usr/bin in your PATH environment variable.

If you want to use your compiled version, you should modify either the ssh service startup script (/etc/init.d/sshd) or the /etc/sysconfig/sshd file which supplies some parameters to the service startup script.

But you should be aware that RedHat usually back-ports security fixes to the original application version selected to the particular RHEL release, instead of upgrading the application version.

The -41 part in the package name "openssh-4.3p2-41.el5" indicates the package has 41 versions of fixes added to the "stock" openssh-4.3p2 code. Most likely some of these versions have never been allowed outside RedHat labs, but it's also very likely your vulnerability has already been fixed in RedHat RPM updates. If you need proof, you should read the RedHat errata notices for updated packages at http://rhn.redhat.com.

MK

[Qcheck]

Thank you so much for the detail explanation MK. Thank you for ur time and it sounds right.

So what should I do in order to work the ssh in /usr/local/bin?

Since I already installed 4.4p1, what can I do to remove the 4.4p1? Once I remove this 4.4p1 then I will put the redhat's fix which is in 4.3p2.....

Thank you so much for your time and awaiting the response.

[Matti_Kurkela]

The sshd startup script /etc/init.d/sshd has a variable that identifies the location of the sshd daemon. By default, the value is set to:

SSHD=/usr/sbin/sshd

If you change this value to:

SSHD=/usr/local/sbin/sshd

then it will start your self-compiled sshd daemon instead.
Stop your existing sshd service before the change; otherwise the script may fail to stop the old sshd daemon.

But reusing the RPM-installed script like this is not recommended: if you remove or update the openssh-server-4.3p2 RPM, the script may be updated and your changes may be lost. You should make your own startup script if you want to use your self-compiled openssh-4.4p1.

I still don't know exactly which compile-time options you used in compiling your openssh-4.4p1. But if you did not specify any options, your compiled version will look for configuration files in /usr/local/etc instead of /etc.

This is half good, half bad: the good thing is that the presence of openssh-4.4p1 does not in any way stop you from updating the RedHat openssh RPMs. The bad thing is, having two versions of the same software in different directories can be very confusing.

If you installed openssh-4.4p1 with a simple "make install" (i.e. without using the .spec file or any RPM tools), removal can be tricky. Fortunately, the OpenSSH source code package supports the "make uninstall" command: go to the source code directory if you still have it, and run "make uninstall". It will remove all the files installed by the original "make install".

If you've already removed the source code directory, you may have to use commands like "find" to look for all the files in /usr/local whose timestamp matches the time you installed openssh-4.4p1, and delete them manually. If you have to do this, think of it as a learning experience :)

----

For future reference: if a source code package contains a .spec file for your Linux distribution (openssh-4.4p1.tar.gz contains openssh-4.4p1/contrib/redhat/openssh.spec), you can use the "rpmbuild" tool to automatically build a RPM-packaged version of the software for you:

rpmbuild -tb openssh-4.4p1.tar.gz

If you don't use the "--buildroot" option with rpmbuild to define a custom build directory, the rpmbuild tool will use the directories in /usr/src/redhat as a work area.

When the tool completes, there should be a set of RPMs in the /usr/src/redhat/RPMS directory. These RPMs will be configured to install in the standard location for your distribution, e.g. installing the locally-built openssh-server-4.4p1.rpm will completely and cleanly replace the RedHat standard openssh-server-4.3p2- RPM and will use the standard SSH configuration file location /etc/ssh.

If you do this, the RPM update tools like yum and pirut will see that you have a newer version than is available on RedHat Network, and will never offer to update it. You will then have to keep building new versions yourself each time a new security vulnerability is found.

MK

[Qcheck]

MK, Thank you so much for all your help. It was detail and I really appreciate for all your time.

I could able to uninstall on the dev servers. So I need to schedule to remove the same thing from the production servers and then I will update with the rpm of 4.3p2-41.el5.

Thanks again so much.....

In future, I will only go with the rpm rather than using the source code. I did use the source code thinking I was going with the latest version and the all should be fixed. But this didn't work.

[Steven E. Protter]

Shalom,

I actually now that you have identified your Linux distro recommend taking out the package you have added in.

You can use yum update to get any fully integrated package that Red Hat offers when it comes down stream.

yum -y update

This will keep all your packages, in sync and secure.

SEP