Remote access to network devices using Telnet and Secure Shell (SSH)
Typically, when you’re preparing a router to go “into production” (meaning it will be used in a live network), you first need to configure it. A common way to do this is to connect a rollover cable from your computer to the router’s console port and then enter the appropriate IOS commands.
When you configure a router this way, it’s called configuring locally, because the computer you’re using is directly connected to the router’s console port.
Once a router is in production, you may need to log into it when you’re not physically at the same site. You could be miles away and still need to access it, and it may not be practical (or fast enough) to travel to the router’s location. For situations like this, remote access protocols such as Telnet were developed.
Telnet
Telnet is a TCP application that uses port 23. It lets you log into a router remotely using an IP address that is reachable on the network.
A Telnet session works much like a console session:
- You see the router’s CLI output on your screen.
- Your keystrokes are sent across the network to the router.
- The router sends back the updated screen output so you can see what’s happening.
This exchange happens quickly enough that it feels real time.
Image 273
Image Title - Telnet session between PC A and R2
To connect using Telnet, open your terminal emulator (for example, PuTTY). Instead of selecting a serial COM port, you enter the router’s IP address.
As long as:
- you can ping the router, and
- no ACLs are blocking Telnet traffic (TCP port 23),
you should be able to log in.
Telnet’s major drawback is security: it is unsecure. Commands and output are sent unencrypted (in clear text). If someone captures packets on the network, they can read:
- every command you type, and
- everything the router sends back to your screen.
Because of this, Telnet is not recommended for modern networks. The preferred protocol for remote router access is Secure Shell (SSH).
Secure Shell (SSH)
SSH is a TCP application that uses port 22. Like Telnet, it allows remote CLI access to a router. The key difference is that SSH encrypts the traffic between your computer and the router, so the packets aren’t readable by anyone else.
Image 274
Image Title - Encrypted SSH session between PC A and R2
Before you can access a router remotely, a few prerequisite configurations must be in place. Here, the focus is on the configurations required for SSH.
Configuring SSH
First, you need a username and password configured on the router. When you connect remotely, the router prompts you for a username and then the password associated with that account.
User accounts have what we call “privilege levels” associated with them. Privilege levels determine the rights or command access that a user has on a router. They dictate which commands you can enter while in “Privilege EXEC” mode - for example, whether you’re allowed to enter the “configure terminal” command to go into Global Configuration Terminal mode. If your privilege level doesn’t allow access to Global Configuration Terminal mode, you can’t configure the router.
Privilege levels range from 1-15 where, Level 1 (which is essentially like User mode) allows you to run basic commands like “ping” and simple show commands like “show ip interface brief”. However, you will not be able to view anything from the running-configuration on the router. This is typically used for Network Operators in a Network Operating Center (NOC) who just need to view the current state of the router’s interfaces, or OSPF adjacencies, and maybe run some ping tests.
These types of users typically do not configure anything on the router. That role is typically reserved for the Network Engineers who hold a CCNA certification and above.
Level 15 gives you full access to all commands on the router, with the highest administrative privileges. Typically, when you are beginning to configure a router, you will use an administrative account with Privilege level 15 in order to add the necessary configurations on the router.
Levels 2-14 allow you to create custom, user defined privileges, where you can define which commands a user with those privilege levels can enter on the router. This is outside of the scope of the CCNA 200-301 v1.1 exam.
:::
Let’s say you want to configure an admin user account that can enter all commands on a router. You can also configure the account so that as soon as the user logs in, they will automatically be placed in Privileged EXEC mode with Level 15 privileges.
In Global Configuration Terminal mode, configure the username admin and set the password to cisco.
When you’re configuring a router for the first time, there is no existing user account, so you already have Privilege level 15 access the moment you type in “enable” to get into Privileged mode. This allows you to enter Global Configuration Terminal mode and create the user account.
configure terminal
username admin privilege 15 password cisco
This configures the username “admin” so it automatically gains access to Privileged EXEC mode when the user logs in, and it sets the password for this user account to “cisco”.
Next, configure a domain name on the router. The router uses this value when generating the encryption key for SSH.
Typically a domain name is the name of your organization followed by either “.com”, “.gov” or “.edu” or whatever is relevant to your organization.
For this example, use the domain name: example[.]com
The domain name should be entered without the square brackets [] of course. The square brackets are only used in the following examples in order to prevent them from becoming a click-able hyperlink on this webpage. But if you enter a domain name on a real router, do not include the square brackets.
ip domain-name example[.]com
On some newer versions of Cisco IOS, the command might be:
ip domain name
Without the hyphen (-).
:::
Next, generate the RSA keys. SSH uses these keys to encrypt the session.
RSA keys can be generated with different encryption strengths. The strength is based on the “modulus”, measured in bits. Typically, 1024 bits is good enough encryption, but as of this writing, a recommended modulus for the RSA keys is 2048 bits. This also depends on what the router can handle.
The details of RSA keys, how they are generated and how they encrypt the data are outside of the scope of the CCNA v1.1 exam
Here, generate RSA keys using a 1024-bit modulus. In Global Configuration Terminal mode, enter:
crypto key generate rsa modulus 1024
Below is a screenshot of what takes place once you enter this command:
Image 275
Image Title - Generating RSA keys with a modulus of 1024 on R1
If you are entering this command in the Cisco Packet Tracer simulation software, you may have to enter the “crypto key generate rsa” command in one line, then hit enter and it will ask you what modulus you would like to use to generate the keys. From there you can enter the modulus in the next line and it will generate the keys. This is just a slight difference from configuring the keys on real Cisco IOS software.
Below is what you might encounter in the Cisco Packet Tracer simulator:
Image 276
Image Title - Generating RSA keys with a modulus of 1024 on R1 in Cisco Packet Tracer
The final steps are to:
- allow SSH connections into the router (SSH is not enabled by default), and
- tell the router to use the local username and password stored in the local user database you configured earlier.
The following configurations are entered within the VTY Line sub-configuration mode. VTY lines are used whenever you access a router remotely via Telnet or SSH. This is in contrast to the Console Line, which is used when you access the router via its console port. Most Cisco routers allow up to 16 VTY lines, which means up to 16 simultaneous remote connections can be made to the router. The VTY lines are numbered from 0 - 15 (which are 16 lines in total, including the 0).
Each VTY line can have its own custom configurations. However, it’s common to configure a range of VTY lines at once. In this example, configure lines 0-15.
To enter VTY line configuration sub-mode from Global Configuration Terminal mode, use:
line vty 0 15
This brings you into VTY line configuration sub-mode, where you’ll see a prompt like:
R1(config-line)#
While in this mode, allow SSH connections by entering:
transport input ssh
Finally, still in VTY line configuration sub-mode, tell the router to authenticate using the local user database:
login local
Now the SSH configuration is complete. Here are all of the commands together:
configure terminal
username admin privilege level 15 password cisco
ip domain-name example[.]com
crypto key generate rsa 1024
line vty 0 15
transport input ssh
login local
end
Image 277
Image Title - Configuring SSH on R1
If everything is configured properly, you can test SSH by selecting “SSH” in PuTTY and using the router’s IP address to connect.
Image 278
Image Title - Testing SSH using PuTTY
If the connection is successful, PuTTY will display a login prompt. Enter the username, press Enter, then enter the password (it won’t be displayed on the screen) and press Enter again. You should be placed directly into Privileged EXEC mode.
Image 279
Image Title - Successfully logging into R1 using SSH