Securing Cisco IOS SSH server

Back in 2011, I wrote a post on how to enable SSH on Cisco routers and switches. Unfortunately, it didn’t contain any of the advanced configurations that will harden Cisco IOS SSH server. To be fair, there were older IOS software versions that didn’t include advanced SSH commands that I will cover here. With this post, I’d like to share at least the minimum advanced SSH configuration that network engineers should consider adding to their template.

SSH Encryption Algorithms

If you’re a macOS 10.13.2 user and you use it to connect to Cisco routers and switches, you may have seen this error message already.

The issue here is that OpenSSH has deprecated the weaker ciphers in the default SSH configuration of the newest version of macOS. Unfortunately, older Cisco IOS software uses AES 3DES-CBC for the SSH server, by default. Below is an example of a Cisco router running an older version of IOS which uses default SSH configuration.

There are two options to get rid of the error message. One of the options is by configuring the client side to accept the legacy ciphers. The right course of action, in my opinion, is to change SSH server configurations. However, we still need to be able to connect to our Cisco IOS devices to correct the issue.

SSH client option

A quick fix here is to keep using compatible ciphers that the client would accept. There are three options that one could use for this workaround. Technically, they are all doing the same thing but just different approach.

Option #1

With this option, the user just needs to specify the cipher and KEX algorithms in the SSH command when connecting to an SSH server. One could create an alias to include all the necessary command flags for shorter keystrokes.

Option #2

With this option, the user does not need to create an alias or type the whole command shown above. The .ssh/config file is a user-specific configuration file. OpenSSH receives its configuration from this file when the command issued doesn’t include command flags.

Option #3

With this option, all users are affected by this configuration file. However, the command issued and user-specific configuration file take precedence over the global configuration file.

SSH server option

As mentioned earlier, the server side option is the correct course of action. However, one still needs to connect the Cisco IOS devices to fix the issue. That said, the SSH client workaround still plays an important role.

SSH encryption algorithm

The command shown below is used to change SSH encryption key algorithm used on a Cisco IOS device. If one gets an error message, then the command is not available in that IOS version.

In this particular IOS version, the SSH server supports the encryption algorithms: AES-CTR, AES-CBC, and 3DES. According to this thread, use EAX or GCM, if available. If not, the author said to use CTR over CBC mode. By specifying the encryption algorithm, we’re telling Cisco IOS to only offer the AES-256-CTR mode to any clients that try to connect to it.

Below shows the verbose output of a Cisco IOS device using default SSH configuration.

Below shows the verbose output of a Cisco IOS device using the SSH configuration mentioned above.

SSH MAC algorithm

To change the default SSH MAC algorithm used on a Cisco IOS device, use the command below.

In this particular IOS version, the SSH server supports two Message Authentication Code (MAC) algorithms: HMAC-SHA1 and HMAC-SHA1-96. The difference between the two algorithms is the digest length. The HMAC-SHA1-96 is a truncated message digest. From my limited understanding, the HMAC-SHA1-96 is the weakened version of HMAC-SHA1 due to the shortened message digest.

Below shows the verbose output of a Cisco IOS device using default SSH configuration.

Below shows the verbose output of a Cisco IOS device using the SSH configuration mentioned above.

Key Exchange Algorithm

If my memory serves me right, even before macOS High Sierra, OpenSSH also deprecated the use of Diffie-Hellman key exchange with SHA-1. That said, users that tried to connect to Cisco IOS devices with default SSH configurations were greeted by an error message, like the one below.

The real issue is that most of the Cisco IOS versions use 1024-bit key size for Diffie-Hellman used for key exchange, by default. Though, there are old Cisco IOS versions that use 768-bit DH key size, by default. Prior the year of 2016, 1024-bit key size is adequate. However, NIST’s recommendation is to use 2048-bit key size or higher. Furthermore, the authors of the LogJam paper believes that it may be possible for a nation-state to break 1024-bit groups. Therefore, the authors recommend disabling DH Group 1.

Below shows the verbose output of a Cisco IOS device using the SSH configuration mentioned above.

Note: Changing the DH key size to 4096 value may break some applications that connect to Cisco IOS devices. For example, HPE Opsware Network Automation (now Micro Focus) uses a Java-based SSH client that is incompatible with SSH servers that use higher than 2048-bit DH key.

Additional SSH configuration

The commands covered here deserves consideration since they increase the level of protection to Cisco IOS SSH server.

RSA keys

As covered in this post, I used 4096-bit modulus in the second example. Cisco IOS users should consider generating higher than NIST’s recommendation of the 2048-bit modulus. Generating higher than the recommended value may take a minute or two (depending on the platform). Additionally, it may take few seconds to get the prompt when connecting to a Cisco IOS device. That said, make sure to take the two facts into consideration before using higher than the recommended value. In theory, newer Cisco platforms could handle the higher values without a significant impact on performance.

If you’re confused about the difference between RSA and DH mentioned here, then I recommend you to read this article. The article did a great job explaining the SSH connection process. If you just want to know the difference between the RSA and DH, then skip to the┬áNegotiating Encryption for the Session section.

SSH authentication timeout

There is no reason to have a high authentication timeout, so it is recommended to lower the value to 60 seconds or less. This particular router has the SSH authentication timeout set to 120 seconds. We’ll change it to 30 seconds.

Line VTY

There four Cisco IOS features under VTY configuration that deserves consideration because they provide an increased level of protection to networking devices.

SSH transport protocols

As mentioned in this post, by default, Cisco IOS still allows telnet connection when the user doesn’t disable it. To disable, please issue the command below. If you only need 5 vty lines, I suggest disabling the remaining vty lines.


Creating and applying ACL to SSH is best practice, so I decided to cover it here, even though this is considered very basic security.

Session timeout

I think this is one of the controversial settings that require some discussions with the networking team. The STIG recommends to set it to 10 minutes or less. By default, Cisco IOS uses 10 minutes for this setting. Please feel free to change it to something else that follows your security policy or suggested setting by the networking team.

Final Words

All of the configurations covered here are what I’d say minimum security standard for all Cisco IOS devices. My advice for my fellow network engineers looking to secure network devices against management plane attacks must consider including this in their configuration template. Though, this blog post is just a small part of protecting the management plane. That said, I urge my fellow network engineers to research more about other settings that protect the management plane.

Want to learn more about securing Cisco IOS?

CCNP Security Secure 642-637 Official Cert Guide

Disclosure is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to

About Andrew Roderos

As an IT professional, I have a strong passion for technology and a desire to learn more about it. Technologies that I am mostly interested in are computer networking, network security, virtualization, and programming. Outside of the information technology world, I enjoy traveling, reading science fiction books and manga, watching movies, and photography.