Telnet is the grandfather of remote access protocols, and its most surprising feature is how much of its functionality is still relevant, despite its fatal security flaws.
Let’s see it in action. Imagine you have a network device, like a router or a switch, that you want to configure remotely. If that device has a Telnet server running, you can connect to it from your machine using a Telnet client.
On your client machine (let’s say it’s Linux or macOS), you’d open a terminal and type:
telnet 192.168.1.1
If the device is listening on its default Telnet port (23) and allows the connection, you’ll be prompted for a username and password.
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
Username: admin
Password:
Once authenticated, you’re presented with a command-line interface (CLI) for that device, as if you were sitting in front of it. You can then issue commands to check its status, change its configuration, or reboot it.
Router> show version
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.7(3)M6, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2019 by Cisco Systems, Inc.
...
Router> configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# hostname MyNewRouter
MyNewRouter(config)# exit
MyNewRouter#
This ability to remotely manage devices is what made Telnet revolutionary. It allowed administrators to manage networks from a central location, saving countless hours of physical presence.
Internally, Telnet operates on a client-server model using TCP. The client initiates a connection to the server on a specific port (usually 23). Once the connection is established, the client sends keystrokes to the server, which executes them as commands on the remote machine. The output of these commands is then sent back to the client and displayed to the user. It’s a simple, text-based stream of data.
The core problem, and why it’s "insecure," is that this data stream is unencrypted. Everything you type – usernames, passwords, commands, and the output of those commands – travels across the network in plain text. Anyone sniffing the network traffic can easily capture and read all of this sensitive information. This is why Telnet is almost universally replaced by SSH (Secure Shell) for remote administration today. SSH encrypts the entire session, making it impossible for eavesdroppers to intercept credentials or commands.
The simplicity of Telnet, however, means it’s still useful for certain niche applications where security isn’t paramount, or where it’s used in a highly controlled, trusted network segment. For instance, some older network devices might only support Telnet for initial configuration, or it can be used to test if a TCP port is open on a server by simply typing telnet <ip_address> <port_number>. If you get a "Connected" message (even if it’s followed by a blank screen or an error), you know something is listening on that port.
The most common misconception about Telnet is that it’s just an older, clunkier version of SSH. While SSH offers encryption and other security enhancements, Telnet’s underlying mechanism of establishing a remote command-line session is fundamentally the same process of sending text commands and receiving text output. The difference is purely in the transport layer: unencrypted versus encrypted. This distinction is critical for understanding why Telnet persists in some corners of IT infrastructure; it’s not about features, but about the lack of security in its transport.
The next step after understanding remote shell protocols is exploring how to secure them, which naturally leads to the intricacies of key-based authentication in SSH.