13.7 Telnet

Overview

Telnet is one of the earliest network application protocols used to remotely access and manage devices over a network using a text based interface. It allows a user on one computer to open a command line session on another device, as if they were typing directly on its keyboard.

In modern networks Telnet is mostly a legacy tool. It is important to understand it for historical reasons, for working with very old equipment, and for specific troubleshooting tasks. However, it is generally considered unsafe for routine administration and is almost always replaced by SSH, which you will study in another chapter.

Basic Concept of Telnet

Telnet is a client server protocol that runs at the application layer. A Telnet client program connects to a Telnet server process (often called a Telnet daemon) that listens on TCP port 23 by default.

Once a connection is established, both sides exchange plain text data. Every key you press in the Telnet client is sent to the server. The server sends back text responses which appear in your terminal window. This creates a remote command line session.

Most network devices such as routers and switches originally supported Telnet as the main way for administrators to log in and configure them across the network. Today, the same style of management is normally done with SSH, but the user experience is very similar: you see a command prompt and type commands.

How Telnet Sessions Work

When a Telnet connection is created, the client first establishes a TCP connection to the server, usually to port 23. This uses the underlying transport and network layers, which are covered in other chapters, so here we focus only on the Telnet session behavior.

After the TCP connection is set up, the Telnet client and server may exchange some control commands to negotiate options, such as whether to echo characters locally or remotely, or whether to support certain terminal features. Most of this negotiation is automatic and invisible to the user.

Once negotiation is complete, the user is typically prompted for a username and password. If the device uses simple password authentication, the server checks the credentials. If they are valid, the server gives the user access to a shell or command line interface.

From this point, every character sequence typed on the client is transmitted to the server. The server executes commands and sends back the output. When the user types an exit command or closes the client, the Telnet session ends and the TCP connection is closed.

Telnet and TCP Port 23

Telnet uses TCP as its transport protocol. The well known port assigned to Telnet servers is port 23. This makes it easy for Telnet clients to know which port to connect to, unless the service has been configured to listen on a different port for special reasons.

::danger
The default Telnet server port is TCP port 23.
::

For administrators and security tools, the presence of an open TCP port 23 on a device is a strong indicator that Telnet is running and that the device may be using an insecure remote access method.

Use Cases and Typical Commands

Although Telnet is rarely used for secure administration today, there are still some common use cases where understanding Telnet is helpful.

One traditional use is remote management of legacy network equipment or embedded systems that only support Telnet. In such environments, Telnet may still be the only available option, especially in isolated or lab networks.

Another frequent use is simple application layer testing. Since Telnet provides a raw text connection to a TCP port, you can connect to arbitrary TCP services, not just Telnet servers. For example, you can connect to a web server on port 80 and manually type HTTP requests to observe the responses at a very low level. This is useful for learning and basic troubleshooting.

On many operating systems, the Telnet client can be launched with a command similar to:

$$
\text{telnet } \langle\text{hostname or IP}\rangle \ \langle\text{port}\rangle
$$

For example, to connect to a Telnet enabled router at address 192.0.2.10 on the default port, you might run:

$$
\text{telnet 192.0.2.10 23}
$$

To test a web server using Telnet, you could try:

$$
\text{telnet example.com 80}
$$

Then manually type an HTTP request. The syntax of HTTP is discussed separately in the HTTP chapter.

In many modern systems, the Telnet client is not installed by default because of security concerns. In those cases, it must be added manually if you still want to use it for troubleshooting.

Telnet vs SSH at a High Level

You will study SSH in detail in a separate chapter, so here we only outline the most important difference from the perspective of Telnet.

Telnet sends all data in plain text. This includes usernames, passwords, and commands. Anyone who can capture the network traffic between client and server can read these credentials and contents.

SSH, in contrast, provides encrypted remote access. The traffic between client and server is protected. This makes SSH the preferred protocol for remote management across untrusted or shared networks such as the internet.

The following table summarizes some high level differences:

::danger
Never use Telnet for remote administration across untrusted networks. Use SSH instead.
::

Even on internal networks, many organizations disable Telnet completely and enforce SSH for consistency and security.

Security Concerns

Telnet has several serious security weaknesses that you must understand.

First, Telnet does not encrypt traffic. The content of a Telnet session is transmitted as readable text. An attacker with access to the same network segment can capture the packets and directly view login credentials and commands. This is known as a clear text protocol vulnerability.

Second, Telnet usually relies on simple password based authentication without additional protection. There is no built in mechanism to verify the server identity in a cryptographic way, so it is vulnerable to impersonation if an attacker can redirect traffic to a malicious host.

Third, Telnet servers can be a target for automated attacks. Attackers scan the internet for devices that still expose port 23 and then attempt default or weak password combinations. Many compromised devices are old routers, IoT devices, or misconfigured systems that left Telnet enabled.

The lack of modern security features in Telnet has led to strong best practice recommendations.

::danger
General rule: Disable Telnet on production systems and do not expose Telnet to the public internet.
::

When Telnet must be used, it should be restricted to tightly controlled, isolated networks, with strong access controls and monitoring.

Telnet for Troubleshooting and Learning

Even with its security issues, Telnet can be a valuable tool for understanding how application layer protocols work, especially for beginners.

Because Telnet simply opens a text based TCP connection, it lets you see and type application level messages directly. For example, when you use Telnet to connect to a mail server or web server, you can type protocol commands by hand and immediately see the server responses. This helps you visualize how application protocols sit on top of TCP.

Telnet can also help you verify basic connectivity to a specific TCP port. For instance, if a web browser cannot reach a site, you can try connecting to the server with Telnet on port 80 or 443 to check if the TCP connection itself can be established. If Telnet cannot connect, the problem may involve firewalls or listening services rather than the application protocol itself.

Because Telnet is simple and transparent, it often appears in training labs and entry level certification exams as a way to demonstrate remote CLI access, even if SSH is recommended in real environments.

Summary

Telnet is a legacy application layer protocol that provides text based remote access over TCP, usually on port 23. It offers a straightforward way to open a remote command line session and to interact directly with application layer services for testing and learning.

However, Telnet traffic is not encrypted and is vulnerable to interception and password theft. For this reason, Telnet is largely replaced by SSH for secure remote management. In modern networking, Telnet’s primary roles are limited to legacy device access, controlled lab environments, and simple troubleshooting of TCP based services.