Configuring IOS XE for Strong Security SSH Sessions (2025)

Summary
Requirements
Configuration Steps
Create RSA Key Pair
Force SSH version 2
Server Authentication
Server Algorithm Key Exchange (KEX)
Server Algorithm Host Key
Server Algorithm Encryption
Server Algorithm Message Authenticator Code (MAC)
Server Algorithm Public Key
Conclusion
Reverting Back
Verification
Troubleshooting \ Debug
Packet Captures
Overview
Frame 1
Frame 2
Frame 3
Frame 6
Frame 7
Frame 10
References
SSH RFCs

Secure Shell (SSH) is a secure management protocol that Cisco engineers use to connect to and administer IOS XE. SSH is what encrypts what you see at the command line interface(CLI). Under the covers, SSH uses Cipher Suites, Hostkeys, Key Exchange Protocols, Message Authentication Codes (MAC).

SSH like most security protocols can use different encryption methods, cipher suites, and key generation mechanisms. In the default configuration more of these are enabled than we would desire for a strong secure session; this provides compatibility at the expense of security. In this document, we shift the balance and provide security at the expense of compatibility. I will account for four (4) client programs Secure CRT, putty, the built-in OpenSSH client in Mac OSX 12, and the built-in SSH client in IOS XE.

It is desirable that the security strength of the key exchange be chosen to be comparable with the security strength of the other elements of the SSH handshake as attackers can target the weakest element of the SSH handshake.

This document will show you how to configure IOS XE to assure the cryptographic primers in use provide the highest level of security. We will do our best to match the strength of the public key exchange algorithm with the security strength of the symmetric cipher.

Cat9K IOS XE 17.2(1) and later - Fully Supported

This configuration will not fully work on C3750X and \ or C3850. I have tested both C3750 and C3850 with the most current IOS XE and have had varying levels of support. IOS XE prior to 17.2 on other platforms will have varying levels of support as well.

I will describe each step in detail.

Create RSA Key Pair

We will create a specific RSA key pair that is only used for SSH. In order to use SSH version 2, we need to create a key pair with at least 2048 bit key length. Modern (newer than 2016) IOS XE devices have more than enough CPU for a key length of 4096 and in order to maintain a similar level of security strength, we will need a key this long.

!
configure terminal
 crypto key generate rsa modulus 4096 label my-4096rsa-ssh-key
 ip ssh rsa keypair-name my-4096rsa-ssh-key
end
!

Force SSH version 2

We need to force SSH version 2. A common misconception is that version 1.99 is right and correct, however, SSH 1.99 is not SSH version 2. SSH 1.99 is the default and is ‘compatibility mode’, that is version 1 and version 2 are supported. We do NOT want to see SSH 1.99.

https://datatracker.ietf.org/doc/html/rfc4253#section-5.1

!
configure terminal
 ip ssh version 2
end
!

Server Authentication

We will be using keyboard authentication. This allows for many different types of authentication including:

Password, SecureID and hardware tokens, Pluggable Authentication Module (PAM) and S/KEY (and other One-Time-Pad)OTP.

!
configure terminal
 ip ssh server algorithm authentication keyboard
end
!

Server Algorithm Key Exchange (KEX)

The KEX algorithms are used to protect the key exchange process. In this step, we are modifying the KEX algorithm order and disabling both DH Group 14 and the SHA2 NIST 256 method.

The NSA states that we should not use ECDSA with NIST P-256 so we will not.

RFC 9142 states 'It is advisable to match the Elliptic Curve Digital Signature (ECDSA) and ECDH algorithm to use the same curve for both to maintain the same security strength in the connection.' We will follow this recommendation when we configure the Server Algorithm Public Key later on.

Modern SSH clients support the NIST Prime curves so we will only enable them and we will enable the stronger algorithms.

Server Algorithm Host Key

The host key specifies the public key algorithms that are used by SSH. We will only enable algorithms that SHA-2 and we will order them with the higher bit length first.

!
configure terminal
 ip ssh server algorithm hostkey rsa-sha2-512 rsa-sha2-256
end
!

Server Algorithm Encryption

This configures the symmetric cipher that will be used for bulk data encryption. This algorithm is what encrypts the content that network administrators see at the CLI.

According to this document, CBC mode is discouraged so we will not enable it. Additionally, SecureCRT does not offer AES-CBC as an option.

!
configure terminal
 ip ssh server algorithm encryption aes256-gcm aes256-ctr
end
!

Server Algorithm Message Authenticator Code (MAC)

The Message Authenticator Code verifies that the message received is the same as the message that was sent.

RFC 6668 introduced two new data integrity algorithms and we will configure IOS XE to use them here.

!
configure terminal
 ip ssh server algorithm mac hmac-sha2-512 hmac-sha2-256
end 
!

Server Algorithm Public Key

In the Server Algorithm KEX section of this document, we discussed using the NIST P-385 and NIST P-521 algorithms.

!
configure terminal
 ip ssh server algorithm publickey ecdsa-sha2-nistp521 ecdsa-sha2-nistp384
end
!

At this point, we have configured the IOS XE device to assure the cryptographic primers in use provide the highest level of security that is possible. Modern versions of the SSH clients SecureCRT, putty, OpenSSH should all successfully connect with this configuration.

I've performed a significant amount of testing on various IOS XE versions, and varying clients and I believe the above configuration will work in the majority of situations. However, if it does not and you need to revert back, you can use the script below.

!
configure terminal
 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
end
!

Here we verify that the settings reflect the configuration we configured.

debug ip ssh client

debug ip ssh detail

debug ip ssh packet

Note: The SSH Handshake illustrated here is after the above configuration.

Overview

Client IP: 192.168.10.153

Server IP: 10.65.0.10

The SSH Handshake contains 8 frames so it is fairly light. In short:

Frames 1 & 2 are the SSH Version Exchange.

Frames 3 & 6 are the KEX Initialization where all the cryptographic primers are negotiated.

Frame 1

This is showing the client announcing SSH version 2 to the server.

Frame 2

This is showing the server announcing SSH version 2 to the client.

Frame 3

This is the Server to Client Key Exchange (KEX). During the KEX we see the server informing the client of the cryptographic primitives that it supports.

Frame 6

NOTE: We are skipping to frame 6 because there are some TCP packets in the stream that are not relevant to the SSH handshake (ACKs and such) that we won't focus on.

This is the Client to Server Key Exchange (KEX). Notice that the Client is announcing it supports LOTS of cryptographic primitives. Since we want to avoid 90% of these we configured the server to only support the strongest.

Frame 7

This is the Client to Server Public Key Initialization. The keys in frames 7 & 10 are only used once and then they are trashed.

Frame 10

This is the Server to Client Public Key Reply.

Frame 11 & 12

This information exchanged in these last two frames helps each side generate the symmetric keys used for bulk encryption, the initialization vectors and the integrity keys.