Telnet (Terminal Network)
Telnet (Terminal Network)
Before graphical remote-desktop tools existed, network administrators still needed a way to manage a computer, router, or switch sitting in another building or another city, without physically walking over to it. Telnet was one of the earliest protocols built to solve exactly that problem: logging in to a remote machine over a network and running commands on it as if sitting right in front of it.
Telnet is rarely used in production today — it transmits everything, including passwords, as plain, unencrypted text — but it's still worth understanding. It introduced the idea of remote login and remote administration that every modern remote-access tool (SSH included) builds on, and you'll still run into it when testing raw TCP connectivity or working with older network gear.
What Is Telnet?
Telnet is a standard application-layer protocol that lets a user remotely access and control another computer through a command-line interface, over a TCP/IP network. It works over a client-server model: a Telnet client initiates a connection to a Telnet server, and from then on the client sends commands as plain text and the server sends back plain-text responses — exactly as if the user had typed those commands locally.
By default, Telnet communicates over TCP port 23.
Definition. Telnet (short for Terminal Network) is a client-server protocol that provides text-based remote login, letting a user access and manage a remote computer over TCP/IP using TCP port 23.
Why Do We Need Telnet?
Imagine a company with a server in another city. If an administrator needs to restart a service or change a configuration setting, flying or driving out to physically sit at that machine would be slow and expensive. Telnet solved this by letting the administrator log in to the server remotely and run commands directly from their own desk.
Example. A network administrator is responsible for routers installed in several branch offices. Rather than visiting each site, they connect to each router over Telnet and:
- View the current network configuration
- Restart services
- Check system status
- Update device settings
- Troubleshoot connectivity problems
This is the core value Telnet introduced: the same command-line control an administrator has locally, available from anywhere on the network — saving both time and travel cost. SSH has since replaced Telnet for this exact use case, but the underlying idea of remote administration is one Telnet pioneered.
How Telnet Works
Client-Server Architecture
A Telnet session always involves two sides:
- The Telnet client initiates the connection to a remote host.
- The Telnet server listens for incoming connections (on port 23 by default), accepts them, and gives the client a command-line session on the remote machine.
Once the client opens a TCP connection to the server, the two sides exchange commands and responses — in plain text — until the session ends.
Components
1. Telnet Client — the software running on the user's own computer. It is responsible for:
- Initiating the connection to the remote host
- Sending the commands the user types
- Receiving the server's responses
- Displaying that output back to the user
Common examples include the built-in Windows Telnet client, the Linux telnet utility, and terminal programs like PuTTY, which support a Telnet mode alongside SSH.
2. Telnet Server — the software running on the remote machine being accessed. It is responsible for:
- Accepting incoming client connections
- Authenticating the user (username and password)
- Executing the commands the client sends
- Returning the command output back over the connection
Local Login vs. Remote Login
Telnet documentation typically distinguishes between two kinds of login:
- Local login — a user runs commands directly on the machine they're physically sitting at (for example, opening a terminal on their own laptop). No network protocol is involved.
- Remote login — a user on one machine connects over the network to run commands on a different machine. This is Telnet's actual purpose: a network administrator in one city connecting to a server in another, as in the earlier example.
Network Virtual Terminal (NVT)
One reason Telnet works across such different systems — Windows talking to Linux, Linux talking to Unix, and so on — is that it doesn't send raw, OS-specific terminal data. Instead, both sides translate to and from a standardized intermediate format called the Network Virtual Terminal (NVT). The client converts its local keystrokes into NVT format before sending them, and the server converts NVT data back into whatever its local terminal expects. This abstraction layer is what makes Telnet platform-independent.
Full-Duplex, Text-Only Communication
Telnet connections are full-duplex: the client can send a command while still receiving earlier output from the server, rather than having to wait for one direction to finish before using the other. This keeps an interactive session feeling responsive — type a command, see the result stream back, keep typing.
Unlike Remote Desktop Protocol (RDP), which sends full graphical screen data, Telnet transfers only text. A user interacts with the remote machine entirely through a command-line interface; there is no concept of a mouse pointer, windows, or graphics in a Telnet session.
Example: Running a Command Remotely
Suppose a user connects to a remote Linux server over Telnet and runs:
mkdir Projects
This command creates a new directory named Projects — not on the user's own machine, but on the remote system. From the user's point of view, typing this command feels identical to running it locally; the only difference is that the keystrokes, and the server's response, travel over the network in plain text first.
Advantages of Telnet
- Simple, lightweight protocol that is easy to use
- Enables remote administration without specialized software
- Requires very little bandwidth, since it's text-only
- Fast command execution, with minimal protocol overhead
- Works across different operating systems via the NVT abstraction
- Useful for quickly testing whether a TCP port is open and responding
- Helpful for low-level troubleshooting of network devices
Disadvantages of Telnet
- No encryption — every byte, including login credentials, travels as plain text
- Usernames and passwords can be captured by anyone able to observe the traffic (packet sniffing)
- Susceptible to man-in-the-middle attacks, since there's no way to verify the server's identity or protect the session from tampering
- Limited to text-based communication only
- Considered unsuitable for any network that isn't fully trusted
These weaknesses are exactly why Telnet has been retired from production use in favor of SSH (Secure Shell), which provides the same kind of remote command-line access but encrypts the entire session and authenticates the server to the client.
Applications of Telnet Today
Even though SSH has replaced it for day-to-day remote administration, Telnet still shows up in a few specific situations:
- Configuring routers and switches in lab or training environments, where many networking courses still use Telnet to teach the fundamentals before introducing SSH
- Manually testing whether a TCP port is open and a service is responding (connecting to a port with a Telnet client and watching for a response is a classic, low-level diagnostic technique)
- Troubleshooting basic network connectivity
- Learning the fundamentals of remote login, since Telnet's protocol is simple enough to reason about by hand
- Accessing older, legacy systems that were never updated to support SSH
Common Mistakes
- Using Telnet over an untrusted network. Because credentials and data are unencrypted, Telnet should never be used over the open Internet or any network segment an attacker could observe.
- Assuming Telnet and SSH are interchangeable. They solve the same problem (remote command-line access) but Telnet provides no encryption or server authentication, while SSH provides both. They are not drop-in replacements for each other in a security-sensitive context.
- Leaving Telnet enabled on production devices "just in case." Many routers and switches ship with Telnet access enabled by default; leaving it on unnecessarily widens the attack surface even if administrators normally use SSH.
Related Concepts
- SSH (Secure Shell) — the modern, encrypted replacement for Telnet, providing the same style of remote command-line access with added encryption and server authentication.
- RDP (Remote Desktop Protocol) — provides full graphical remote access, unlike Telnet's text-only sessions.
- TCP port testing — connecting to a specific port with a Telnet client is a common, simple way to check whether a service on that port is listening and responding.
Key Points to Remember
- Telnet stands for Terminal Network and is an application-layer protocol.
- It follows the client-server model and uses TCP port 23 by default.
- It provides text-based remote login and supports full-duplex communication.
- The Network Virtual Terminal (NVT) format is what makes Telnet work across different operating systems.
- Telnet transmits all data, including credentials, without encryption — which is why SSH has replaced it as the standard for secure remote access.