Wireless Access

Is there a way to change which SSH ciphers and/or Algorithms are enabled in AOS? A recent vulnerability scan shows CBC mode ciphers and insecure HMAC algorithms are enabled.

 

We are using AOS 6.3.0.1-FIPS

Is there a way to "disable" the cipher/algo without turning SSH?

I have the same issue.  I can no longer use cbc flavored ciphers, which is apparently all that the Aruba 650 will support.  I just updated to the 6.4.3.3 build, and it still throws an error.

 

I am trying to scp a file from my server to the Aruba. 

 

The error reads:

no matching cipher found: client aes128-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

 

What this implies to me, is that teh client (Aruba, in this case) has the ciphers: aes128-cbc and aes256-cbc -- My server is presenting the remainder of the error list.

 

So far I have had no luck fixing this, but tech support said they should support ctr flavored ciphers.  The error, from what I am reading, implies that the controller does not support these ciphers.  Any help would be much appreciated.

I'm afraid SSH ciphers are not configurable - they are hardcoded at build time.

 

Because the US Government (and other national governments) is typically our strictest customer from a security standpoint, we've chosen to make our SSH ciphersuites comply with their requirements.  We comply with the Network Device Protection Profile (https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0) which states:

 

FCS_SSHC_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and rejects all other encryption algorithms: aes128-cbc, aes256-cbc, [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other algorithms].

As you can see, there's no flexibility here to support CBC and ALSO support CTR - we're limited to only this list.  In the future, we are likely to add support for the GCM-based ciphers here, but we would then still be required to leave CBC enabled.

Frankly, the risk of exposure from https://www.kb.cert.org/vuls/id/958563 is so exceedingly small that I don't think anyone should be worrying about it.

Discovering this problem (yet again).

 

Todays issue is that openssh 7 doesn't include these ciphers, so its impossible to use any system that has an up to date openssh package installed.

 

Any news on the way forwards?

It's working OK for me - any details on who built that version of OpenSSH?  This is from Ubuntu 16.04:

 

OpenSSH_7.2p2 Ubuntu-4, OpenSSL 1.0.2g-fips 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to arubaos.atl.arubanetworks.com [63.80.98.178] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jon/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to arubaos.atl.arubanetworks.com:22 as 'bugz'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: ssh-rsa SHA256:Zdl4mNSwfLXzcYJQCxAt859gmtLVPr5+chiYX9NBCXA
debug1: Host 'arubaos.atl.arubanetworks.com' is known and matches the RSA host key.
debug1: Found key in /home/jon/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: password,keyboard-interactive

 

 

 

That's interesting... .I tried Fedora 24 which has:

 

# rpm -qa | grep openssh
openssh-server-7.2p2-6.fc24.x86_64
openssh-clients-7.2p2-6.fc24.x86_64
openssh-7.2p2-6.fc24.x86_64

 

I'll try it against some RedHat systems later on - but they should work out of the box because they still have openssh 6.x. I wonder what specifics ubuntu use to build openssh - as most were dropped upstream by openssh.

This issue with administrators not being able to login to AOS is comming back:

1. CBC ciphers have been deprecated in upstream openssh since version 7.3p1.

2. Ubuntu 18.04 uses openssh 7.6p1 and any attempt to log into an Aruba controller running AOS 6.5.3.5 or even 8.2.1 results in

Unable to negotiate with x.x.x.x port 22: no matching cipher found. Their offer: aes128-cbc,aes256-cbc

The ciphers are still compiled in the code and you can force ssh to use them, but they might be left out alltogether in the future. Perhaps it's time AOS supported other ciphers as well?

 

ssh -v output:

OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /home/x/.ssh/config
debug1: /home/x/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to x.x.x.x port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH
debug1: match: OpenSSH pat OpenSSH* compat 0x04000000
debug1: Authenticating to x.x.x.x:22 as 'admin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ssh-rsa
Unable to negotiate with x.x.x.x port 22: no matching cipher found. Their offer: aes128-cbc,aes256-cbc

John does this still apply.  I know this is an old post but we are running 6.5.1.9 AOS and 8.2.4 Airwave. We recent had Nessus scan done and both the controller and Airwave findings are "

SSH Weak MAC Algorithms Enabled and SSH Server CBC Mode Ciphers Enabled "the receomedned solutions are "

Contact the vendor or consult product documentation to disable MD5 and 96-bit MAC algorithms

Contact the vendor or consult product documentation to disable CBC mode cipher encryption, and enable CTR or GCM cipher mode encryption.

 

I know thess are low risk but we are in the process of getting an ATO and we have to provide POAM for these.

Thanks

Thomas

 

My opinion of Nessus being 100% wrong about this has not changed.  However, arguing this point has worn us down.  In an upcoming ArubaOS release, we're going to provide a knob to shut off AES-CBC and HMAC-SHA1-96.  I've been told AOS 6.5.3.4 and 6.5.4.4, coming in December.  The feature will not be backported to 6.5.1.x.

 

You mentioned ATO, so I'll assume you are doing a DoD deployment.  Until recently, AES-CTR was not approved by NIAP, so deploying it would have put you out of compliance with CNSS policy 11.  That changed a few months ago when NIAP adopted NDcPP 2.0, so this is the first time we're able to offer it and still maintain compliance with DoD policy.

Thanks John , this is a DOJ deployment.


Thomas

IMPORTANT NOTICE: This message may contain privileged and confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.