Securing SSH connections

[David Graham_9]

All - we just had a security audit performed and we told that our SSH Algorithms and ciphers are weak. We were told to disable MD5 algorithms and CBC ciphers. Is this possible to do on the SSH connections? I see how to do it on the SSL connections and have done that, but cannot find the way to do this for SSH. Unless disabling it for SSL disabled it for SSH.

These switches are A5800AF-48G running Comware Version 5.20.

Thanks for any answers!

Cheers

Dave

[Apachez- · Accepted solution]

Unfortunately there doesnt seem to exist a way to alter which ciphers will be allowed for ssh.

What did the HP support tell you when you filed this as a bug?

I tried looking in latest firmware for 5820 without finding anything useful on this topic, also tried looking in _hidecmd without any luck.

One possible workaround could be if you enable FIPS-mode on the device, but that usually have other drawbacks instead.

Another workaround would be to properly protect the SSH interface and use a sane SSH configuration like so (unfortunately you cannot lock the ssh to listen on a particular vlan either):

#
acl number 2002 name v4-MGMT-SSH
 hardware-count enable
 rule 0 deny fragment
 rule 5 permit source <REMOVED> 0
 rule 10 deny
#
acl ipv6 number 2002 name v6-MGMT-SSH
 hardware-count enable
 rule 0 deny fragment
 rule 5 deny routing
 rule 10 deny
#
 ssh server enable
 ssh server rekey-interval 1
 undo ssh server compatible-ssh1x
 undo sftp server enable
 ssh client source interface LoopBack0
 ssh server acl 2002
 ssh server ipv6 acl ipv6 2002
#
user-interface vty 0 15
 acl 2002 inbound
 acl ipv6 2002 inbound
 authentication-mode scheme
 user privilege level 1
 set authentication password cipher <REMOVED>
 protocol inbound ssh
 terminal type vt100
#

The  "ssh server acl 2002" and "ssh server ipv6 acl ipv6 2002" are from a recent firmware (R1808P25 or so).

[David Graham_9]

Thanks much for all of the above. I have not opened a bug with HP yet as I figured I was a dufus and just was not finding the documentation correctly. Using the ACL is a neat trick.

I will open a case with HP now to get this looked into.

Thanks again

Dave

[MDella]

Ok, fast forward to November 4th or so...

The MSR20-20 and MSR30-20 both came out with new revisions of their OS that now deals with CVE-2008-5161 however after the update, I cannot get back into the router (I just updated to A_MSR20-CMW520-R2513L20-SI-RU.BIN to test this).

When SSHing into the router, I get the following error:

[mdella@catalyst (LHR) ~]$ ssh lhr-front-rtr1
no matching cipher found: client aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se server des-cbc
[mdella@catalyst (LHR) ~]$

Unfortunately I'm using the stock Centos 6.6 openssh to get to the machine.  I say unfortunate because now without doing something *additional*, you cannot get into a stock (current firmware) MSR device.

Looking at debug I'm getting the comware side to report:

...

debug1: Remote protocol version 1.99, remote software version Comware-5.20.106
debug1: no match: Comware-5.20.106
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
no matching cipher found: client aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se server des-cbc

...

So... anyone have a clue?  I read the release notes to know that the old support was { des | 3des | aes-cbc } which has now been reduced to { des }.  Unfortunately I thought that was SSH1, not SSH2.  Now even I'm confused as to what really happened.  Anyway, been experimenting with all the "supported" ciphers that I have and nothing is working yet.

Marcos

[Apachez-]

You are using the RU-firmware which I guess stands for RUssian edition, meaning its crippled cipherwise (exportrestrictions or whatever).

Reading the release notes it clearly states:

"

Modified feature: SSH only supports the DES algorithm for encryption

"

and then lists how both ssh2 and sftp command (among others) are affected by the removal of 3des and aes from the cipher suite.

I think the proper fix in your case is to contact HP so you can access the password protected downloads (non-RU editions) which I assume are full featured.

As a workaround get a ssh client which will allow you to use single-DES as cipher. I think putty supports this if you first go to Connection -> SSH and move up DES above "-- warn below here --". Preferly you do this only for the specific session for the ip of your routers (so the default is still to disallow DES).