Configuring SSH on a Cisco Device

SSH (Secure Shell) is a command-line interactive interface, similar to Telnet, but encrypted. All data sent in both directions during interactive sessions are encrypted, as well as all session setup information. It uses a public key / private key mechanism to manage security. So how do you go about configuring SSH?

Both the terminal and the network device have their own private keys and each has the public key of the other. The public key encrypts and the private key decrypts. In order to initiate an SSH exchange, both devices must send their public keys. If you have previously logged into the device, this step can be skipped.

A few versions of SSH have emerged over the years. Due to some critical security flaws with SSH-1, it’s important to use version 2. Cisco recommends using version 2 unless you have software that doesn’t support it. I’d go even further and recommend you simply not use version 1 for any reason.

You’ll need a terminal emulator that supports SSH-2. There are some perfectly good free ones available, such as PuTTY, as well as several excellent commercial solutions.

SSH uses TCP port 22. The protocol also supports encrypted file transfers.

Configuring SSH on a router or switch includes many of the same steps as configuring Telnet. You first set up the VTY (virtual terminal) and an enable password, and then define a method of user authentication. The main difference with SSH is generating cryptographic keys, which are tied to the hostname of the device. You must make sure that a hostname is configured.

1. Configure SSH-2

First, force the router to use SSH-2:

ip ssh version 2

If this command gives an error message, your device is probably running an older version of the software that doesn’t support SSH-2. In this case, I strongly recommend not exposing it to SSH sessions sourced from the public internet.

2. Configure a hostname

You can’t define the cryptographic key unless the device has a fully qualified domain name. This means it needs both a hostname and a default domain.

hostname MyCiscoDevice
ip domain MyNetwork.net

It doesn’t matter if the hostname and domain aren’t the same as what you might find in DNS for this device. In fact, you can connect to the device using the IP address, so you can configure a completely bogus domain name if you’d like.

3. Set up authentication

SSH requires a user ID and password. You either need to create local user accounts or use a central authentication server like TACACS or RADIUS. I prefer to have a central authentication server, but because many smaller organizations don’t have one, the following configuration includes a local user ID.

aaa new-model
aaa authentication login LOCAL local
username MyUserID secret MyCleverPassword
enable secret MyEnablePassword

This code fragment also defines an enable password, which is necessary before the router will let you log in.

4. Configure VTY

The VTY configuration for SSH is almost identical to Telnet. The following example assumes that only SSH will be used to access this device. To also allow Telnet to access the device, add it to the “transport input” command.

!
access-list 80 permit host 192.168.19.25 log
!
line vty 0 4
 transport input telnet
 login authentication LOCAL
 exec-timeout 5 0
 access-class 80 in
!

In this example, I’ve also included an “access-class” command that restricts where I can access this device from.

5. Create the keys

SSH won’t work until you create the public and private keys.

crypto key generate rsa

This command takes a while to run as the device generates a new set of public and private keys for SSH to use.

If there are already keys and you want to wipe them out and start over, use this command:

crypto key zeroize rsa

Then you’ll need to use the “generate” command again. If there’s no key, SSH won’t accept connections.

6. Validate

There are a few useful “show” commands for checking your configuration.

show ssh

The switch or router will likely respond to this command with something like this:

  SSH Enabled - version 2.0
  Authentication timeout: 120 secs; Authentication retries: 3

Here the device is configured properly. If it says “no SSHv2 server connections running,” something is wrong with the configuration and the SSH server isn’t accepting connections.

If the device reports that the version is either 1.5 or 1.99, this isn’t good. Version 1.5 means the device will only accept SSH-1 connections, while 1.99 means it will accept version 1 or 2. You don’t want to accept version 1 connections over the public internet, although it would be secure over a private network.