I know that cPanel and plain redhat do not use proprietary ssh version and this will work fine for those servers. Enism DOES use special rpms (atlteast last time I used it long ago somebody correct me if I am wrong) and I am unsure about plesk. Please only do the following with cPanel or no control panel! For now I have placed this guide in the cPanel forum to avoid confusion and problems with people doing this on a server that will not accept the install. As always I take no responsibility if this guide screws up your server, it worked fine for me!

This guide is also posted on my website http://eth0.us/?q=node/5

Updated 12/2 to include open ssl upgrade

First step we will enable telnet so if something screws up you can still access the server:
#pico -w /etc/xinetd.d/telnet
change disable = yes to no
Save and then exit
#/etc/init.d/xinetd restart






First we will upgrade open ssl:
#cd /usr/local/src
#wget http://www.openssl.org/source/openssl-0.9.7e.tar.gz
#tar -zxf openssl-0.9.7e.tar.gz
#cd openssl-0.9.7e
#./Configure --prefix=/usr linux-pentium
#make
#make test
#make install





Now get the latest source from an official mirror:
#cd /usr/local/src
#wget http://ftp.belnet.be/packages/openbsd/Open...sh-3.9p1.tar.gz
#tar -xzf openssh-3.9p1.tar.gz
#cd openssh-3.9p1
#./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/src/openssl-0.9.7e --with-pam
#make
#make install
#/sbin/service sshd restart

If you get a user error you need to add a sshd user. Do that by running this command:
#adduser sshd -s /sbin/nologin
If you don't get any error about a user you do not have to worry about adding the user.

Open another ssh window and make sure ssh works ok, if running the following command returns something with “OpenSSH_3.9p1” you did it correctly.
#sshd –V

Now go back and turn telnet on:
#pico -w /etc/xinetd.d/telnet
change disable = no to yes
Save and then exit
#/etc/init.d/xinetd restart

That’s it!

Hi eth00

I do your instruction but at the end of make install : show me this error:

Privilege separation user sshd does not exist
make: [check-config] Error 255 (ignored)


and when I restart sshd , It stop but , donot start agian !

our server is linux rehat 7.3 (cpanel/whm).

How should i do now ?

Regard

I changed the guide to reflect your problem maidenonline, go ahead and type:
#adduser sshd -s /sbin/nologin

The run make; make install again and you should be fixed.

Hi

I cannot loggin to SSH and when I logon to Telnet and type

adduser sshd -s /sbin/nologin

it show me :


bash: adduser: command not found

now how can i do to fix this problem ??

Regard

try "su -" then adduser or useradd

Very Very Very Thanks

It's a very good instruction , and you are a very very clever linuxmaster.

Best Thanks and Regard

Would like to UpgradeSSH but been having problems with it

configure: error: Your OpenSSL headers do not match your library.
Check config.log for details.
Also see contrib/findssl.sh for help identifying header/library mismatches.


0x0090705FL /root/openssl-0.9.7e/crypto/opensslv.h
0x0090705FL /root/openssl-0.9.7e/include/openssl/opensslv.h
0x0090705FL /usr/include/openssl/opensslv.h
0x0090705FL /usr/include/opensslv.h

Searching for OpenSSL shared library files.
0x0090701fL /usr/lib/libcrypto.so.0
0x0090701fL /usr/lib/libcrypto.so.4
0x0090701fL /usr/lib/libcrypto.so
0x0090602fL /lib/libcrypto.so.0
0x0090701fL /lib/libcrypto.so.0.9.7a
0x0090701fL /lib/libcrypto.so.4
0x0090602fL /lib/libcrypto.so.0.9.6b
0x0090602fL /lib/libcrypto.so.2

Searching for OpenSSL static library files.
0x0090705fL /root/openssl-0.9.7e/libcrypto.a
0x0090705fL /usr/lib/libcrypto.a


I even tried this guide here
http://entropy.brneurosci.org/linuxsetup54.html

But no luck thats the only thing stopping me... theres something im overlooking im sure. Would appreciate any input

DigitalCrime: did you make install your openssl?

eth00: yes, this should work on ensim too, it's very similar to other how-to previously posted here, I've performed it before and it works, as of previous ssh and sshd on the box, they replaced and don't generate Ensim upgrade problems

I'm talking about any Ensim 3.x or 4.x version

however people with the Ensim 4.x shouldn't have problems up2dating their box and having openssh along with openssl upgraded from there, for the paranoid who can't wait up2date releases it's alright, it doesn't break anything

regards

Yep..... almost sure I did

cept
openssl
openssl: error while loading shared libraries: libssl.so.0.9.7: cannot open shared object file: No such file or directory

Missing something now, WHM shows it being installed though

I think I ran into a similar problem once

I'd move /lib/libcrypto.so.0.9.6b somewhere else (don't remove it, you need it just in case you break something and if it doesn't work)

and then move / rename

/lib/libcrypto.so.0
/lib/libcrypto.so.4
/lib/libcrypto.so.2

and replace them with simlynks to their newer counterparts at /usr/lib/

careful when you do this, and keep some extra ssh active sessions in case you get disconnected accidentally

try


to check linking on you current ssh binary

regards

Good instructions, but I'd like to keep as much as possible under up2date. Are there concise newbie instructions anywhere for updating openssl/openssh to bring RHEL/cpanel up to date and make the vulnerability scanner happy?

Thanks,
Scot

There are none. RH has the bad habit of patching things but NOT changing version numbers. So even though it should be patched with up2date -u the version numbers are still going to state the old version. I guess if you found where the version numbers are stored could change that but it is too much work, I just upgrade ssh by the above method.

Thanks eth00. So if RH has patched without changing the version #, does that imply that the OpenSSH/OpenSSL as shipped with RHEL3 are not in fact vulnerable to the weakness that Vulnerabilty Scanner flags? If not, I don't suppose there's any reason to actually upgrade...

By the way, many thanks for all of your security tutorials -- many of the procedures have become a part of my standard server setup routine.

They should be fine though I have never tried to actually test against the exploit.