If you manage 9800 WLCs or any Cisco IOS-XE devices, chances are you rely on SSH to access their command interfaces. But here’s something you might have missed: the default SSH configuration could unintentionally permit various cipher suites, potentially putting your system at risk.

When setting up SSH, it’s crucial to be vigilant. Cisco recognizes the importance of robust security practices and offers a recommended configuration that we’ll explore in this post. To implement these improvements, your devices should be operating on IOS-XE 17.2.x or later versions. By doing so, you’re not only following Cisco’s best practices, but you’re also ensuring the safety of your network with firmware that’s more advanced than ever.

Let’s take a look at a practical example involving my 9800-CL device, where SSH has been set up. In the configuration, you’ll notice that various forms of authentication (key exchange algorithms), encryption ciphers, and integrity checks (MAC algorithms) have been activated. However, it’s important to highlight that some of these methods are no longer considered secure, and it’s advisable to avoid enabling them due to potential vulnerabilities

C9800-2#sh ip ssh
SSH Enabled - version 1.99
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,x509v3-ecdsa-sha2-nistp256,x509v3-ecdsa-sha2-nistp384,x509v3-ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512
Hostkey Algorithms:x509v3-ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-rsa
Encryption Algorithms:chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-gcm,aes256-gcm,aes128-ctr,aes192-ctr,aes256-ctr
MAC Algorithms:hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
KEX Algorithms:curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 2048 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): TP-self-signed-3476138042
Modulus Size : 2048 bits

Now, let’s explore how you can set up SSH on your IOS-XE device to align with those top-notch security practices. The initial step involves creating an RSA Key, which should be at least 4096 bits in length. This key will be instrumental in ensuring a secure SSH connection. Make sure you enforce SSH v2.0 and use keyboard authentication as well.

C9800-2(config)#crypto key generate rsa modulus 4096 label RSA4096_SSH_KEY
The name for the keys will be: RSA4096_SSH_KEY

% The key modulus size is 4096 bits
% Generating 4096 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 3 seconds)
!
ip ssh rsa keypair-name RSA4096_SSH_KEY
ip ssh version 2
ip ssh server algorithm authentication keyboard

In today’s digital landscape, prioritize AES encryption with a 256-bit key length for top-tier security. When it comes to efficiency, GCMP outshines CCMP. And within CCMP, it’s better to go with CTR mode over CBC for added security.

ip ssh server algorithm encryption aes256-gcm aes256-ctr

When it comes to Message Integrity, you should always use SHA2 (over SHA1 or MD5 which is deprecated in current standards).

ip ssh server algorithm mac hmac-sha2-512 hmac-sha2-256

Speaking of key exchange algorithms, Elliptic Curve Diffie-Hellman takes the lead. For optimal security, go with NIST P-521 and NIST P-384, which are endorsed by the NSA.

ip ssh server algorithm kex ecdh-sha2-nistp521 ecdh-sha2-nistp384

public key to match same NIST P-curves

ip ssh server algorithm publickey ecdsa-sha2-nistp521 ecdsa-sha2-nistp384

Server algorithm hostkeys

ip ssh server algorithm hostkey rsa-sha2-512 rsa-sha2-256

In summary here are all the CLI to match that cisco best practices

crypto key generate rsa modulus 4096 label RSA4096_SSH_KEY
ip ssh rsa keypair-name RSA4096_SSH_KEY
ip ssh version 2
ip ssh server algorithm authentication keyboard
ip ssh server algorithm mac hmac-sha2-512 hmac-sha2-256
ip ssh server algorithm encryption aes256-gcm aes256-ctr
ip ssh server algorithm kex ecdh-sha2-nistp521 ecdh-sha2-nistp384
ip ssh server algorithm hostkey rsa-sha2-512 rsa-sha2-256
ip ssh server algorithm publickey ecdsa-sha2-nistp521 ecdsa-sha2-nistp384

Once you configured above, you should be good with SSH secuirty best practices. As long as you use modern SSH client to connect to your IOS-XE devices, there should not be any incompatiblities.

C9800-2#sh ip ssh
SSH Enabled - version 2.0
Authentication methods:keyboard-interactive
Authentication Publickey Algorithms:ecdsa-sha2-nistp521,ecdsa-sha2-nistp384
Hostkey Algorithms:rsa-sha2-512,rsa-sha2-256
Encryption Algorithms:aes256-gcm,aes256-ctr
MAC Algorithms:hmac-sha2-512,hmac-sha2-256
KEX Algorithms:ecdh-sha2-nistp521,ecdh-sha2-nistp384
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 2048 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): RSA4096_SSH_KEY
Modulus Size : 4096 bits

In case you want to roll-back your changes, here are the CLI commands to put default settings.

  default ip ssh server algorithm encryption
  default ip ssh server algorithm hostkey
  default ip ssh server algorithm kex
  default ip ssh server algorithm mac
  default ip ssh server algorithm authentication
  default ip ssh server algorithm publickey

Sometime your SSH client device you may have to delete known_hosts file “rm .ssh/known_hosts” or alter it using “ssh-keygen -R <ip_addr or name>“.

To see new SSH security in action, I did a test with my client (Macbook Pro) using the verbose (-v) option to get detailed debug information. This can be really helpful for troubleshooting and understanding the SSH flow. Refer RFC 4253-SSH Trasport Layer Protocol for more details about each message.

mrncciew@Rasikas-MacBook-Pro ~ % ssh -v 192.168.100.30 -l rasika
OpenSSH_9.0p1, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.100.30 [192.168.100.30] port 22.
debug1: Connection established.
.
.
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version Cisco-1.25
debug1: compat_banner: match: Cisco-1.25 pat Cisco-1.* compat 0x60000000
debug1: Authenticating to 192.168.100.30:22 as 'rasika'
.
.
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp384
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:oLQpJ1nqEsbSFM/BISqXHr1NOEjEEUGP+7IKvpY68/s
.
.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.100.30' (RSA) to the list of known hosts.
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
.
.
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ecdsa-sha2-nistp521,ecdsa-sha2-nistp384>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
(rasika@192.168.100.30) Password: 
Authenticated to 192.168.100.30 ([192.168.100.30]:22) using "keyboard-interactive".
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_AU.UTF-8"
C9800-3#

You can also simply take a packet capture on your 9800 (Troubleshooting -> Packet Captures)to confirm the SSH packet flow. This time I used SecureCRT from my MBP while accessing 9800 GUI using a different PC to set the below capture. Note that the “Monitor Control Plane” checkbox is unticked as it is only required when you want to monitor 9800 control plane traffic (like AP registration,etc)

I have set an ACL to filter only traffic coming from my SSH client (Mackbook Pro IP)

ip access-list extended MBP_ACL
 10 permit ip host 192.168.129.154 any
 20 permit ip any host 192.168.129.154

Here is the complete PCAP with SSH packets highlighted. You’ll notice that SSH protocol traffic perfectly matches the SSH debug messages seen earlier.

When the SSH connection is established, both the client and server (9800 WLC in this case) must send their identity string typically including the protocol version & software version in that string. The client says it’s SecureCRT v9.3.2, and the server (WLC) says it’s Cisco v1.25.

Next, Key Exchange (KEX) begins with each side sending lists of suppported algorithms. In the server key exchange message (SSH_MSG_KEXINIT) you will see it is limited to SSH security algorithms that we configured on 9800.

Even though the Client listed all those different types of cipher suites it supports, 9800 will only choose what is configured to use. When listing multiple algorithms it must be listed in order of preference, from most to least.

Then Diffie-Helmn (ECDH in our case) Key exchange takes place to derive the symmetric encryption key. First Client sends (SSH_MSG_KEXDH_INIT) frame #10 with its public key where the server responds with (SSH_MSG_KEXDH_REPLY) frame #14 with its public key.

Hope you enjoy the read.

If you are keen on IOS (not IOS-XE), please find the best practices document written by one of my good friends Karsten Iwen