web analytics

Accessing the CLI with Telnet and SSH

For many years, terminal emulator applications have supported far more than the ability to
communicate over a serial port to a local device (like a switch’s console). Terminal emulators
support a variety of TCP/IP applications as well, including Telnet and SSH. Telnet and SSH
both allow the user to connect to another device’s CLI, but instead of connecting through
a console cable to the console port, the traffic flows over the same IP network that the networking
devices are helping to create.

Telnet uses the concept of a Telnet client (the terminal application) and a Telnet server
(the switch in this case). A Telnet client, the device that sits in front of the user, accepts
keyboard input and sends those commands to the Telnet server. The Telnet server accepts
the text, interprets the text as a command, and replies back. Telnet is a TCP-based application
layer protocol that uses well-known port 23.

Cisco Catalyst switches enable a Telnet server by default, but switches need a few more
configuration settings before you can successfully use Telnet to connect to a switch.
Chapter 8 covers switch configuration to support Telnet and SSH in detail.

Using Telnet in a lab today makes sense, but Telnet poses a significant security risk in production
networks. Telnet sends all data (including any username and password for login to
the switch) as clear-text data. SSH gives us a much better option.

Think of SSH as the much more secure Telnet cousin. Outwardly, you still open a terminal
emulator, connect to the switch’s IP address, and see the switch CLI, no matter whether you
use Telnet or SSH. The differences exist behind the scenes: SSH encrypts the contents of all
messages, including the passwords, avoiding the possibility of someone capturing packets in
the network and stealing the password to network devices. Like Telnet, SSH uses TCP, just
using well-known port 22 instead of Telnet’s 23.

Subscribe To Get

Latest IT certification News 

Help You Pass Any IT Exam