NetworkJutsu

Network Security Consulting | San Francisco Bay Area

SSH

Securing Cisco IOS SSH server

By Leave a Comment

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.

Mac mini:~ networkjutsu$ ssh router01
Unable to negotiate with 192.168.100.200 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

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.

router01>sh ssh
Connection Version Mode Encryption  Hmac	     State	               Username
0          2.0     IN   3des-cbc    hmac-sha1    Session started       networkjutsu
0          2.0     OUT  3des-cbc    hmac-sha1    Session started       networkjutsu
%No SSHv1 server connections running.

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 options

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.

Mac mini:~ networkjutsu$ ssh -oKexAlgorithms=diffie-hellman-group1-sha1 -c 3des-cbc router01
Password:
router01>

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.

Mac mini:~ networkjutsu$ cat .ssh/config
# ***
# *** General settings (these apply to all connections)
# ***
HostkeyAlgorithms +ssh-dss
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +3des-cbc

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.

Mac mini:~ networkjutsu$ cat /etc/ssh/ssh_config
HostkeyAlgorithms +ssh-dss
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +3des-cbc

SSH server options

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.

router01(config)#ip ssh server algorithm encryption ?
  3des-cbc    Three-key 3DES in CBC mode
  aes128-cbc  AES with 128-bit key in CBC mode
  aes128-ctr  AES with 128-bit key in CTR mode
  aes192-cbc  AES with 192-bit key in CBC mode
  aes192-ctr  AES with 192-bit key in CTR mode
  aes256-cbc  AES with 256-bit key in CBC mode
  aes256-ctr  AES with 256-bit key in CTR mode
router01(config)#ip ssh server algorithm encryption aes256-ctr

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.

Mac mini:~ networkjutsu$ ssh -vvv router01
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted for brevity -->
debug2: peer server KEXINIT proposal
debug2: ciphers ctos: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

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

Mac-mini:~ networkjutsu$ ss -vvv router01
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted for brevity -->
debug2: peer server KEXINIT proposal
debug2: ciphers ctos: aes256-ctr
debug2: ciphers stoc: aes256-ctr

SSH MAC algorithm

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

router01(config)#ip ssh server algorithm mac ?
  hmac-sha1     HMAC-SHA1 (digest length = key length = 160 bits)
  hmac-sha1-96  HMAC-SHA1-96 (digest length = 96 bits, key length = 160 bits)
router01(config)#ip ssh server algorithm mac hmac-sha1

UPDATE: Newer IOS supports higher than SHA1.

router01(config)#ip ssh server algorithm mac ?
  hmac-sha1      HMAC-SHA1 (digest length = key length = 160 bits)
  hmac-sha1-96   HMAC-SHA1-96 (digest length = 96 bits, key length = 160 bits)
  hmac-sha2-256  HMAC-SHA2-256 (digest length = 256 bits, key length = 256 bits)
  hmac-sha2-512  HMAC-SHA2-512 (digest length = 512 bits, key length = 512 bits)
router01(config)#ip ssh server algorithm mac hmac-sha2-512

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.

Mac-mini:~ networkjutsu$ ss -vvv router01
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted for brevity -->
debug2: MACs ctos: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: MACs stoc: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96

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

Mac-mini:~ networkjutsu$ ss -vvv router01
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted for brevity -->
debug2: peer server KEXINIT proposal
debug2: MACs ctos: hmac-sha1
debug2: MACs stoc: hmac-sha1

UPDATE: Configured with SHA2

Mac-mini:~ networkjutsu$ ss -vvv router01
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted for brevity -->
debug2: MACs ctos: hmac-sha2-512
debug2: MACs stoc: hmac-sha2-512

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.

Mac mini:~ networkjutsu$ ssh router01
Unable to negotiate with 192.168.100.200 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

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.

router01(config)#sh ip ssh
<-- Output omitted for brevity -->
Minimum expected Diffie Hellman key size : 1024 bits
router01(config)#ip ssh dh min size ?
  1024  Diffie Group 1 1024-bit key
  2048  Diffie Group 14 2048-bit key
  4096  Diffie Group 16 4096-bit key
router01(config)#ip ssh dh min size 4096

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

Mac-mini:~ networkjutsu$ ss -vvv router01
OpenSSH_7.6p1, LibreSSL 2.6.2
<-- Output omitted for brevity -->
debug1: kex: algorithm: diffie-hellman-group-exchange-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none

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.

router01(config)#crypto key gen rsa mod ?
  <360-4096>  size of the key modulus [360-4096]
router01(config)#crypto key gen rsa modulus 4096 label SSH_KEY
The name for the keys will be: SSH_KEY
% The key modulus size is 4096 bits
% Generating 4096 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 103 seconds)

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.

router01#sh ip ssh
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication timeout: 120 secs; Authentication retries: 3
<-- Output omitted for brevity -->
router01#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
router01(config)#ip ssh time-out 30
router01(config)#do sh ip ssh
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication timeout: 30 secs; Authentication retries: 3
<-- Output omitted for brevity -->

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.

router01(config)#line vty 0 4
router01(config-line)#transport input ssh
router01(config)#line vty ?
  <0-98>  First Line number
router01(config)#line vty 5 98
router01(config-line)#transport input none

SSH ACL

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

router01(config)#access-list 1 permit 172.16.0.0 0.0.0.63
router01(config)#access-list 1 permit 192.168.100.0 0.0.0.255
router01(config)#line vty 0 4
router01(config-line)#access-class 1 in

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.

router01#sh run all | sec line vty
line vty 0 4
 motd-banner
 exec-banner
 exec-timeout 10 0
<-- Output omitted for brevity -->
router01(config)#line vty 0 4
router01(config-line)#exec-timeout ?
  <0-35791>  Timeout in minutes
router01(config-line)#exec-timeout 5 ?
  <0-2147483>  Timeout in seconds
router01(config-line)#exec-timeout 5 0

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.

NetworkJutsu provides networking and network security consulting services for startups, a more established small and medium-sized business (SMB), or large business throughout the San Francisco Bay Area.

Want to learn more about securing Cisco IOS?

CCNP Security Secure 642-637 Official Cert Guide

Disclosure

NetworkJutsu.com 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 Amazon.com.

Securing SSH with Google Authenticator

By 2 Comments

In my old blog post, I talked about how to mitigate from persistent SSH brute force attack. While there are several options in mitigating SSH brute force attack, I opted to use the Fail2Ban option at the time. Today, I’ve decided to add another security layer to the host since this is a public facing server. This addition of security layer is based on defense in depth, which is an information assurance concept. As the title says, I will be using Google Authenticator to generate a time-based one-time password (TOTP) for two-step verification.

Related: What is multi-factor authentication?

It seems like two-factor authentication (2FA) is becoming a norm these days. More and more security professionals are pushing organizations to use 2FA for every sensitive systems and application. Understandably so, because the consensus is that password is no longer enough to protect accounts in this day and age. As a result, I’ve also decided to start implementing 2FA in my home devices.

Installing Google Authenticator PAM

Ubuntu has been my distro of choice for several years now, so all of my Linux-related tutorials have been on that. I will keep that going, mostly because I do not have time to learn another distro, like CentOS.

Installing Google Authenticator on Ubuntu 16.04 is a piece of cake. All you need is one command.

$ sudo apt-get install libpam-google-authenticator -y

Configuring SSH PAM

The Google Authenticator 2FA is accomplished by integrating into Linux’s Pluggable Authentication Modules (PAM) library. PAM is a way for programs to use an underlying authentication mechanism. With that said, we’ll need to configure PAM configuration to pass it to Google Authenticator. To do this, we need to edit the PAM configuration file for SSH.

$ sudo vi /etc/pam.d/sshd

At the bottom of the file, I added the following lines below. The first line is optional, but it’s always best to add comment lines in my opinion.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

If you want to understand the syntax, please check this site. Though, the article did not include what nullok argument means. The argument simply means that if a user hasn’t created secret key yet, then they’re still allowed to log in. My recommendation is to enable 2FA for all users so make sure to have all the users generate the secret key. Once all secret keys are generated, take out the nullok argument.

Configuring OpenSSH Daemon

The next step is to actually configure SSH to check for backend system (e.g. PAM) to use the challenge-response authentication method. To do this, we need to edit the OpenSSH configuration file.

$ sudo vi /etc/ssh/sshd_config

Once the file is open, look for the line with ChallengeResponseAuthentication no and change it to yes. Save the file and exit.

ChallengeResponseAuthentication yes

In Linux, changes to Linux configuration files require a service restart to take effect, for the most part. With that said, we need to restart SSH daemon (sshd). To restart SSH service, issue sudo service ssh restart command. Once sshd is back up, test to make sure that user can still log in without two-step verification.

Generating Google Authenticator Secret Key

The last step to make SSH 2FA work is to generate a secret key for the two-step verification. In this example, I created a test user account for demo purposes.

generating-secret-key

Use the Google Authenticator app on your mobile device and add the QR code.

Account with Google Authenticator secret key

In this example, SSH daemon is asking the user to enter Google Authenticator OTP.

$ ssh test@radius
Password: testing1234
Verification code: 664449
<-- Output omitted for brevity -->
test@radius:~$
google authenticator token

Account with no Google Authenticator secret key

Here the admin account does not have the Google Authenticator secret key yet. If one forgets to add the nullok argument, then the system will not allow user accounts without the secret key.

$ ssh admin@radius
Password:
<-- Output omitted for brevity -->
admin@radius:~$

Optional Configuration

It is probably a good idea to enable 2FA to the local login (console) too. So this way, anyone who has access to the physical machine will be subjected to two-step verification. To do this, we need to edit the login configuration file.

$ sudo vi /etc/pam.d/login

Once the file is open, add the lines below at the end of the file. Save the file and exit out.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

From now on, all user accounts with Google Authenticator secret key will need to enter a verification code.

Thoughts

Balancing security and convenience is one of the biggest dilemmas that information security professionals face. In a nutshell, making it convenient for users to access their account means it is less secure. In a perfect world (no bad guys) people would probably pick one password across all of their accounts. Since we’re not living in a perfect world, this leaves the accounts to be very insecure. If one account is compromised, then all of the other accounts could potentially be accessed by the bad guys.

The use of complex passwords and password managers are good first steps toward securing accounts. However, in today’s world, some of the information security professionals view password alone as an antiquated technique in securing accounts. As a result, a lot of online services have had multi-factor authentication feature. However, companies that provide these online services do not force accounts to use it. As a result, accounts are still at risk by relying on passwords alone.

You might also like to read

Adding Two-Factor Authentication to FreeRADIUS

Reference

How to Secure SSH with Google Authenticator’s Two-Factor Authentication

Disclosure

NetworkJutsu.com 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 Amazon.com.