Quite often, you have to test connectivity or connect to a multitude of devices from your router or switch. Unless you have all their IP addresses memorized or you have a trusty topology map with you wherever you go, you might find it difficult to accurately recall their IP address information.

To assist you when such challenges arise, the Cisco IOS can statically or dynamically support domain name resolution on the Cisco device. This way, you can refer to the devices by a recognizable hostname versus an IP address.

The command to create a static entry in the IOS configuration file is ip host. For example, given the following command:

CCNA2811(config)#ip host corer outer 172.16.1.1

The IOS automatically forms a name-to-IP association in a host table so that every time you refer to corer outer, it translates that hostname to the IP of 172.16.1.1.

In instances where there are far too many devices to create individual static host entries, you might be better suited to have a DNS server keep the hostname-to-IP records. With that infrastructure in place, you can have your Cisco device use these servers for the name translation. The command to specify the DNS server(s)(up to 6) is the ip name-server command as shown here:

CCNA2811(config)#ip name-server 172.16.1.254 172.16.1.100 172.16.1.2

Given the previous ip name-server command, when referencing a device by its hostname, the router will query the DNS server with the IP addresses of 172.16.1.254, 172.16.1.100, and 172.16.1.2 to resolve the hostname to an IP address.

Domain resolution is automatically enabled on your Cisco device. If you have not configured a DNS server, it tries to resolve hostnames by sending a broadcast out all its active interfaces.

This can be irksome when you accidentally type a command in User or Privileged EXEC and the IOS attempts to resolve the command thinking that it is a hostname. To disable this feature, use the following command:

CCNA2811(config)#no ip domain lookup

One final domain specific command is to assign your Cisco device to an IP domain. This command has several purpose in a Cisco networking environment; however, for our purpose, it will be crucial in enabling SSH connectivity to our Cisco device as discussed in the next section. The command to assign a default domain name to a Cisco device is ip domain-name as demonstrated here:

CCNA(config)#ip domain-name examprep.com

Enabling SSH

SSH is a secure (and Cisco preferred) method of remote access to Cisco devices because of the terminal connection which uses RSA public key cryptography for authentication and encryption of the data sent over the terminal connection.

Because this terminal connection utilizes encryption, two prerequisites for configuring SSH are to have IP sec (DES or 3DES) IOS feature-set on the Cisco device and have an SSH supported terminal client such as Putty and Secure CRT.

Assuming your Cisco device meets the prerequisites for SSH, the first step in enabling SSH connectivity to the Cisco IOS is to configure a hostname(other than its default) and assign the device to a domain as previously discussed. The only remaining step in the SSH process is to generate an RSA key for the encryption. The default key length is 512 bits, however, it is recommended to have a key of at least 1024 bits in length for additional security strength. The command to generate this key is crypto key generate rsa as demonstrate here:

CCNA2811(config)#crypto key generate rsa
the name for the keys will be: CCNA2811.examprep.com
choose the size of the key modulus in the range of 360 to 2048 for your General purpose keys.
choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]:1024
Generating RSA keys...
[OK]
7w1d: %SSH-5-ENABLED: SSH 1.5 has been enabled

Notice how the key generating process uses the hostname and domain name of the device when generating the key; therefore, those configuration steps must be performed first. Also notice that at the completion of the key generation, SSH is automatically enabled.

One final element to the SSH configuration is to define a username and password for authentication. this username/password pair will be used when you configure your SSH client to connect to the IOS.

The command to define this username and password pair is username username password password in Global Configuration. For instance, if you want to use SSH username as your username and SSH password as our password, the configuration would look like the following:

CCNA2811(config)#username SSH username password SSH password

Line Configuration

We already have an article of how to secure access to Privileged EXEC by using the enable password or enable secret command. However, this assumes that any administrators can still gain User EXEC to the Cisco device. The problem with this configuration is that you can send excessive pings or Telnet to another device from your router or switch in User EXEC.

Because the ping and Telnet traffic are coming from your private router or switch, they might not be blocked by a security device such as a firewall. This section looks into how to secure access to the User EXEC by assigning a password on the EXEC lines into the Cisco device.

Know what is Firewall for a Network to enhance the security level for the network.

Securing console access to User EXEC

Console access necessitates that an admin have physical access to the device itself. If your Cisco router or switch is physically accessible to non-authorized personnel (not highly recommended), you should take preventive measures to add another level of security by having the devices prompt anybody trying to get to User EXEC via the console port for a password. the following three commands ultimately achieve that goal:

CCNA2811(config)#line.console 0
CCNA2811(config-line)#login
CCNA2811(config-line)#password my console password

The first command navigates the IOS to sub-configuration mode for the console port. The second command instructs the IOS to prompt anybody connecting to this EXEC line for a login, using the password chosen in the third command.

To add yet another additional level of security comfort, it is also advisable to have the IOS close the console session after so much time of inactivity (no typing) in the session. After the EXEC session is closed, the admin has to enter the console password (assuming the above console configuration was in place) to get into user EXEC again. This is generally useful for those emergency bathroom breaks that arise after a couple cups of coffee or those unscheduled fire drills.

By default, the console session closes after 10 minutes of inactivity which, unfortunately, is plenty of time for someone to jump on to your terminal and change passwords and lock you out if you are not present. To change that setting, use the exec-timeout command followed by the number of minutes and seconds the IOS should wait to time out. for example, if you want the console to close after 1 minute and 30 seconds of inactivity, the command should reflect the following:

CCNA2811(config-line)#exec-timeout 1 30

Securing Auxiliary Access to User EXEC

If your organization has decided to allow remote terminal access to your Cisco device through an external modem or terminal server connected to the auxiliary port, you have added another means of getting to User EXEC that you must secure.

The auxiliary port is slightly easier to connect than the console port because physical access is no longer a mandate. As long as you know the phone number to dial into the modem, you can gain access to a User EXEC session. This ease of access should be counterbalanced with security measures to ensure authorized users are connecting to this EXEC line.

Conveniently, the commands are practically identical to those used to secure a console connection. The only major difference is the navigation to the auxiliary port as opposed to the console:

CCNA2811(config)#line auxiliary 0
CCNA2811(config-line)#login
CCNA2811(config-line)#password my aux password
CCNA2811(config-line)#exec-timeout 1 30

Securing Telnet and SSH Access to User EXEC

Telnet and SSH are by far the most insecure methods of establishing an EXEC session because any user with IP connectivity to the device can initiate a Telnet or SSH session to it. For this reason, the default state of these lines is to require that a vty password be set for anyone to achieve access to User EXEC. Otherwise, you will receive an error similar to the following:

Password required, but none set. In addition, if you do not have an enable password set on the device, you are not able to enter Privileged EXEC mode. The error you receive in this situation is the following:

% No password set

Once again, the configuration is similar to those of the console and the auxiliary port, however, the navigation of the Telnet lines is slightly different than what you find with the rest. To assign a login password to all the vty lines into the device, you must specify the range of those vty lines in your navigation.

For instance, most routers allow five Telnet or SSH sessions into them. To encompass all the vty lines, you have to identify them starting with the first line (remembering that numbering beings with 0), followed by the last (0-4 is a total of 5 lines), as shown here:

CCNA2811(config)#line vty 0 4
CCNA2811(config-line)#login
CCNA2811(config-line)#password my telnet password
CCNA2811(config-line)#exec-timeout 1 30

The question usually begs, “what would happen if you configured only line vty 0 or you put a different password on each vty line?” to answer the first part of the question, if you configure only line vty 0, the router prompts the first user for a password. If another user tries to connect with that first Telnet session still running, he cannot log in to the router (remembering that the default state is that a password must be set.).

On the other hand, if you assign different passwords to each of the vty lines, you can connect on all the lines; however, you have no means of choosing or knowing to which vty line you are connected. you would have to guess the password within three tries (IOS only allows three attempts).

Your configuration should look like the following (with possible variation on the abbreviation of the commands):

! step 1
Router>enable
Router#configure terminal Enter configuration commands, one per line. end with CNTL/Z

! step 2
Router(config)#line console 0
Router(config-line)#login
Router(config-line)#password captstubing

! step 3
Router(config-line)#exec-timeout 2 10
Router(config-line)#exit

! step 4
Router(config)#line aux 0
Router(config-line)#login
Router(config-line)#password bartenderisaac

! step 5
Router(config-line)#exec-timeout 3 0
Router(config-line)#exit

! step 6
Router(config)#line vty 0 4
Router(config-line)#login
Router(config-line)#password yeoman gopher
Router(config-line)#exit

! step 7
Router(config)#hostname The love Router

! step 8
The love Router(config)#ip domain-name comeaboard.com

! step 9
The love Router(config)#crypto key generate rsa
The name for the keys will be: TheLoveRouter.comeaboard.com
Choose the size of the key modulus in the range of 360 to 2048 for your General purpose keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]:1024
Generating RSA keys...
[OK]
7w1d: %SSH-5-ENABLED: SSH 1.5 has been enabled

! step 10
The Love Router(config)#username jmcoy password cruise director 

! step 11
The Love Router(config)#enable password the love boat

! step 12
The Love Router(config)#enable secret something4every1

! step 13
The Love Router(config)#service password-encryption

In this configuration, anyone connecting to the console port needs to enter the password captns tubing before gaining an EXEC session via the console port. After 2 minutes and 10 seconds of inactivity, the session close and users have to enter in the password again to return to User EXEC.

Likewise, anyone accessing the router from the auxiliary port needs to enter the password bartenderisaac at the login prompt and has to re-enter that password after 3 minutes of inactivity. Up to five administrators can Telnet or SSH into this router, at which point they all have to enter the password yeoman gopher at the login prompt. RSA was enabled by using the crypto key generate rsa command and specifying the key length as 1024. the key generated used our configured IP domain, comeaboard.com, and the default hostname of Router (since that was unchanged).

Because the enable password command and the enable secret command are used in this configuration, the password something4every1 inevitably will be used to enter Privileged EXEC because the enable, secret command overrides the enable password.

The final command, service password-encryption, encrypts the enable, vty, aux, and console passwords so they are not visible to anyone who can see the configuration.