Enabling SSH on Cisco Catalyst Switches

There are several ways to configure or monitoring a Cisco Device: console line (which requires a local cable, hence physical address), vty lines (via telnet or ssh), SNMP, and http/https access.

Since traffic through Telnet protocol travels in clear (non-encrypted) text, it’s best to configure remote access through a secure (encrypted) channel.

Before you proceed, verify your Cisco Device supports encryption. To check whether your device allows encryption issue the following command:

Look for the line System image file and verify whether your IOS version have a “k9” substring in the file name. This indicates the version supports encryption.

Configuration Steps

• Set a hostname and a domain name
• Enable password encryption and create required usernames and passwords
• Generate an encryption key
• Restrict vty lines to use ssh
• Restrict vty lines to allow incoming ssh traffic only from certain IP addresses (optional)
• Block IP addresses after a certain number of failed attempts (optional)

Set a hostname and a domain name

A hostname is already set but you should change it to something more descriptive for your environment. A domain is not set by default and you must set this value to match your business infrastructure.

Change to enable mode, if you’re not already on it.

Set your hostname and domain-name according to your own network.

Enable password encryption and create usernames and passwords

The service password-encryption allows for ahem.. the encryption of every password (enable, username passwords) on the device. Issue it if you haven’t before (you probably have, though). Also create the users who can access your device and with which privileges. In this example the user database is local.

where
name: the user name
privilege#: 15 for enable permissions; 1 for normal user permissions
passwordtype#:

• 0 if you’re going to type an unencrypted password;
• 5 if you’re going to type an already encrypted password.

password: the actual password

The following example creates the user khaxan with enable permissions

Generating a crypto key

The Cisco device must create an encryption key before ssh could be enabled.

You can choose a modulus size up to 2048. The longer the better so:

Wait a bit while the system creates the key.

Restricting vty lines to use only ssh (don’t allow telnet)

In configuration mode allow only incoming ssh connections with the command transport input ssh (by default lines don’t allow any connections), and indicate the authentication is taking place against the local database (the users you created before).

Restricting vty lines to only allow ssh from certain subnets (Optional)

If you want to add a bit of extra security, you can create a list of IP addresses which are allowed to connect via ssh to the Cisco device.

The following example creates the standard access list 1 to permit traffic from the subnet 10.10.10.0 with logging enabled.  A deny statement is implicit in the ACL so technically the second access-list line is not needed unless you want to log unauthorized connection attempts (Always check who’s trying to connect to your server!).

Apply that ACL to the vty lines accepting SSH.

Block IP addresses after a certain number of failed attempts (optional)

Also, if you want to prevent the casual attacker you can block their IP addresses for a period of time use the command login block-for; this will prevent brute force attacks to the device.

The example below blocks for 1 hour (3600 seconds) an IP address with 5 failed login attempts within 50 seconds.  Important: Choose carefully the proper times for your environment. If you select a very low fail-attempt-threshold like 2 failed login attempts within 60 seconds then you might be blocking yourself if you accidentally type a wrong password 2 times in 1 minute.

That’s it. You should be able to connect to your device via your favorite SSH client.