Telnet: Remote Terminal Protocol

What is Telnet?

Telnet is a network protocol that allows a user to establish a remote terminal session over a TCP connection. Defined in RFC 854(published in 1983), the protocol traces its roots back to 1969, when it was one of the first applications developed on the ARPANET. The name comes from "teletype network," reflecting its origins in connecting remote terminals to mainframe computers.

At its core, Telnet creates a bidirectional, text-oriented communication channel between a client and a server. The protocol is built on the concept of a Network Virtual Terminal (NVT), which provides a standardized terminal abstraction that both sides agree on. This means any Telnet client can communicate with any Telnet server, regardless of the underlying operating system or hardware.

The most critical limitation of Telnet is that it transmits all data in plaintext, including usernames, passwords, and every keystroke typed during a session. Anyone with access to the network path between client and server can capture and read the entire session using a simple packet sniffer. This fundamental security flaw led to Telnet being replaced by SSH (Secure Shell) for virtually all remote administration tasks.

Despite its age and security shortcomings, Telnet has not disappeared entirely. Network engineers still use the Telnet client as a quick diagnostic tool for testing TCP port connectivity. Legacy embedded devices, older network equipment, and some industrial systems still rely on Telnet for configuration. It also remains a valuable educational tool for learning how text-based protocols like HTTP and SMTP work, since you can manually type protocol commands and see raw responses.

How Telnet Works

A Telnet session begins when a client opens a TCP connection to port 23 on the remote server. Once the TCP three-way handshake completes, the Telnet protocol layer takes over and both sides begin communicating through the Network Virtual Terminal abstraction.

The Network Virtual Terminal (NVT)

The NVT is the foundation of Telnet. Rather than requiring both sides to know the details of each other's terminal hardware, the NVT defines a minimal, standard terminal that every implementation must support. It specifies a basic character set (7-bit US-ASCII), a set of control codes (carriage return, line feed, bell, and others), and default behavior for echoing and line buffering.

When a user types on a local terminal, the Telnet client translates those keystrokes into NVT format and sends them over the TCP connection. The server receives the NVT data, translates it into whatever format its local system requires, processes the input, and sends the output back in NVT format. The client then translates the NVT output for display on the user's actual terminal.

Option Negotiation

While the NVT provides a baseline, Telnet includes an option negotiation mechanism that allows both sides to agree on enhanced features. This negotiation uses four command verbs: DO, DONT, WILL, and WONT. For example, a server might send DO ECHO to ask the client to enable local echoing, and the client responds with either WILL ECHO (agreeing) or WONT ECHO (refusing).

This symmetrical negotiation model means either side can propose options, and either side can accept or reject them. Common options include echo mode, suppress go-ahead, terminal type, window size (NAWS), and line mode. The negotiation happens in-band, mixed with the regular data stream, using the special IAC (Interpret As Command) escape byte to distinguish commands from data.

Character-by-Character Transmission

In its default mode, Telnet sends each keystroke individually as soon as the user types it. This provides immediate feedback but generates significant network traffic, since every single character requires its own TCP segment (plus the echoed response from the server). The line mode option can reduce this overhead by buffering an entire line before sending, but character mode remains the more common configuration for interactive sessions.

Telnet vs SSH: Why SSH Replaced Telnet

When Telnet was designed in 1969, the ARPANET was a small, trusted research network. Encryption was unnecessary because all participants were known and the network was not publicly accessible. As the internet grew and became open to everyone, the plaintext nature of Telnet became a serious liability.

In 1995, Tatu Ylonen created SSH at the University of Helsinki after a password-sniffing attack compromised the university network. SSH was designed as a direct, secure replacement for Telnet, rlogin, and rsh. It encrypts the entire session from the very first key exchange, making packet sniffing useless.

The following table highlights the key differences between Telnet and SSH.

Telnet Commands and Option Negotiation

Telnet commands are embedded within the data stream using the IAC (Interpret As Command) byte, which has the value 255. When the Telnet layer encounters byte 255, it interprets the following byte(s) as a command rather than data. If the actual data contains the value 255, it must be escaped by sending 255 twice (IAC IAC).

The most important commands deal with option negotiation, which allows both sides to dynamically enable or disable protocol features. Here are the core command bytes.

How Option Negotiation Works

A typical negotiation exchange looks like this: the server sends IAC DO 1 (asking the client to enable the ECHO option, option code 1). The client responds with either IAC WILL 1 (accepting) or IAC WONT 1 (refusing). The four-verb system (DO, DONT, WILL, WONT) ensures that both sides always reach agreement, even if one side does not support a particular option.

Sub-negotiation, using SB and SE, handles options that require additional parameters. For example, the terminal type option (option code 24) uses sub-negotiation to transmit the actual terminal type string, such as "VT100" or "XTERM." The sequence would be IAC SB 24 0 "XTERM" IAC SE, where 0 indicates "this is my terminal type."

Security Risks of Telnet

Telnet was designed in an era when network security was not a concern. The protocol has no encryption, no integrity checking, and no mechanism for verifying server identity. These limitations make Telnet dangerous to use over any network that is not fully trusted and physically isolated.

Plaintext Credential Exposure

Every byte transmitted over a Telnet connection, including usernames and passwords, travels in plaintext. Anyone on the same network segment (or anywhere along the routing path) can capture these credentials using freely available packet-sniffing tools like Wireshark or tcpdump. On modern switched networks, techniques like ARP spoofing make this interception straightforward.

Man-in-the-Middle Attacks

Because Telnet has no server authentication mechanism, a client has no way to verify that it is actually connected to the intended server. An attacker can intercept the connection, impersonate the server, capture credentials, and then relay traffic to the real server. The user sees a normal login prompt and has no indication that anything is wrong.

Session Hijacking

Since Telnet provides no encryption or integrity protection, an attacker who can observe the TCP connection can inject commands into an active session. The server cannot distinguish between legitimate keystrokes from the real user and forged packets from an attacker. This allows complete takeover of an active session without needing to know the user's password.

Credential Replay

Captured Telnet credentials can be reused at any time. Unlike challenge-response authentication or time-based tokens, a plaintext password captured today works just as well tomorrow. There is no session-specific cryptographic material that would prevent replay.

The bottom line: never use Telnet over untrusted networks. If you must manage devices that only support Telnet, do so over a physically isolated management network or through an encrypted VPN tunnel.

When Telnet Is Still Used Today

Despite its security flaws, the Telnet client remains a commonly used networking tool. In most cases, it is not used for its original purpose of remote login but rather as a lightweight tool for testing and debugging.

TCP Port Connectivity Testing

The most common modern use of the Telnet client is checking whether a TCP port is open on a remote host. Running telnet host 443 quickly tells you whether a connection can be established. If the connection succeeds, the port is open and the service is listening. If it times out or is refused, you know there is a firewall rule or service issue. Many administrators reach for Telnet first because it is installed on nearly every system.

Legacy Embedded Devices

Older routers, switches, industrial controllers, and embedded systems often provide only a Telnet interface for management. These devices may lack the processing power or firmware support for SSH. Industrial equipment running protocols like Modbus TCP sometimes uses Telnet for configuration. Replacing these devices can be expensive, so Telnet persists in many operational environments.

Network Equipment Initial Configuration

When setting up new network equipment, the device may ship with only Telnet enabled on its console or management port. Administrators typically connect via Telnet for the initial setup, configure SSH keys and credentials, and then disable Telnet permanently.

Protocol Debugging

Because Telnet provides a raw TCP connection with text I/O, it is an excellent tool for manually interacting with text-based protocols. You can connect to an SMTP server on port 25 and type EHLO, MAIL FROM, and RCPT TO commands directly. You can connect to an HTTP server on port 80 and type GET / HTTP/1.1 to see the raw response headers and body. This hands-on approach is invaluable for understanding and troubleshooting protocols.

MUD Games

Multi-User Dungeons (MUDs), text-based multiplayer games that originated in the late 1970s, traditionally use Telnet as their client protocol. A small but active community of MUD players and developers still relies on Telnet connections, often using specialized MUD clients that are built on the Telnet protocol with extensions for color and other features.

Common Use Cases

The following scenarios represent the most typical ways Telnet is encountered in practice today.

• Legacy device administration: managing older routers, switches, and embedded systems that only support Telnet for remote configuration.
• TCP connectivity testing: using telnet host port to verify that a remote service is listening and accepting connections on a specific port.
• Protocol debugging: manually sending HTTP, SMTP, FTP, or other text-based protocol commands to observe raw server responses and troubleshoot issues.
• Network equipment initial setup: performing first-time configuration on devices that ship with Telnet enabled by default, before switching to SSH.
• Educational purposes: learning how network protocols work by manually typing commands and reading responses, which provides a much deeper understanding than using higher-level tools.

Frequently Asked Questions

Is Telnet still used?

Yes, but not for its original purpose of secure remote login. Telnet is still widely used as a quick tool for testing TCP port connectivity and for managing legacy devices that do not support SSH. Some industrial and embedded systems still rely on Telnet for configuration. However, for general-purpose remote access, SSH has completely replaced Telnet.

Why is Telnet insecure?

Telnet transmits everything in plaintext, including passwords and sensitive data. It has no encryption, no server authentication, and no data integrity verification. Anyone who can observe the network traffic between the client and server can read the entire session, capture credentials, inject commands, or hijack the connection.

Can I use Telnet to test if a port is open?

Yes, this is one of the most common uses of the Telnet client today. Running telnet hostname 80 (or any port number) attempts to open a TCP connection to that port. If the connection succeeds, the port is open. If it is refused or times out, the port is closed or filtered by a firewall. Note that you are only using the Telnet client as a TCP connection tool in this scenario, not the Telnet protocol itself.

What replaced Telnet?

SSH (Secure Shell) replaced Telnet as the standard protocol for remote terminal access. Created in 1995, SSH provides full encryption, strong authentication (including public key authentication), data integrity verification, and additional features like file transfer and port forwarding. SSH is now the universal standard for remote server administration.

Is there a secure version of Telnet?

There have been attempts to add security to Telnet. The Telnet Authentication Option (RFC 2941) and Telnet Encryption Option (RFC 2946) defined extensions for adding authentication and encryption to Telnet sessions. However, these extensions never gained widespread adoption because SSH already provided a complete, well-designed solution. In practice, the "secure version of Telnet" is simply SSH.

What is the difference between Telnet and SSH?

The fundamental difference is security. Telnet sends all data in plaintext, while SSH encrypts the entire session. SSH also provides server authentication (so you can verify you are connecting to the right host), data integrity checking, multiple authentication methods (including public key), and built-in features like file transfer and port forwarding. Telnet uses port 23, while SSH uses port 22. For a detailed comparison, see the Telnet vs SSH section above.

Related Protocols

• SSH (Secure Shell): the encrypted replacement for Telnet, now the universal standard for remote server access.
• TCP (Transmission Control Protocol): the transport layer protocol that Telnet relies on for reliable, ordered data delivery.
• FTP (File Transfer Protocol): another early internet protocol that, like Telnet, transmits data in plaintext and has been largely replaced by secure alternatives.
• HTTP (Hypertext Transfer Protocol): a text-based application layer protocol that can be debugged using a Telnet client for educational purposes.