Wireless Access

last person joined: 11 hours ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

SSH Ciphers

  • 1.  SSH Ciphers

    Posted Aug 13, 2013 02:13 PM

    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



  • 2.  RE: SSH Ciphers

    Posted Apr 23, 2015 04:53 AM

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



  • 3.  RE: SSH Ciphers

    Posted Sep 01, 2015 03:29 PM

    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.



  • 4.  RE: SSH Ciphers

    Posted Sep 01, 2015 05:47 PM

    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.



  • 5.  RE: SSH Ciphers

    Posted May 01, 2016 11:00 PM

    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?



  • 6.  RE: SSH Ciphers

    Posted May 02, 2016 08:14 AM

    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

     

     

     



  • 7.  RE: SSH Ciphers

    Posted May 02, 2016 11:57 PM

    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.



  • 8.  RE: SSH Ciphers

    Posted May 28, 2018 05:31 AM

    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


  • 9.  RE: SSH Ciphers

    Posted Nov 29, 2017 12:14 PM

    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

     



  • 10.  RE: SSH Ciphers

    Posted Nov 29, 2017 12:27 PM

    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.



  • 11.  RE: SSH Ciphers

    Posted Nov 29, 2017 12:50 PM
    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.