Telnet | Teleinf Edu

1. Telnet: Remote Terminal Access

Telnet, short for Teletype Network, is one of the earliest remote-access protocols. The first Telnet subsystem description appeared in 1969, while the later standard protocol specification was published in 1983. Telnet is a text-based network protocol that lets a user connect to a remote computer and operate its terminal over a network. It provides interactive text communication in both directions through a virtual terminal. User data and Telnet control commands share the same TCP byte stream, so the client and server must interpret control information while processing terminal input and output.

Telnet is primarily used for sessions. A user running a Telnet client on a local machine can connect to a Telnet server on a remote machine. After the service authenticates the user, it can provide the remote system's command-line interface, or shell. Characters entered by the user are sent to the server for processing, and the resulting output returns to the client terminal. Telnet defines the terminal exchange, while the service decides how accounts, passwords, and permissions are handled.

Early implementations allowed users to operate centralized computers from remote terminals. The base Telnet design provides no default encryption or cryptographic server authentication, so an ordinary session is unsuitable for use on an untrusted network. Current uses of a Telnet client are mainly limited to testing text services and maintaining legacy equipment in isolated environments; using the protocol for administrative login requires a separately protected network.

2. Telnet Architecture and Operating Principles

Telnet uses a client-server model, a Network Virtual Terminal, and negotiated options. Together, these elements define data exchange and support interoperability between implementations that follow the base specification. The option mechanism lets endpoints agree on terminal behavior without changing the basic byte-stream transport.

Client-Server Model
A Telnet session involves two cooperating programs:
- Telnet Client: An application that runs on the user's computer. It initiates the connection, sends characters entered by the user, interprets Telnet data, and displays text received from the server.
- Telnet Server (Daemon): Software, often called a daemon ('telnetd'), that runs on the remote machine. It listens on a designated port, establishes the session, and can pass it to a login process or the host operating system's shell.
Reliable Transport via TCP
Telnet operates over the Transmission Control Protocol (TCP), which provides a reliable, connection-oriented service. This is important for a command-line interface. Data arrives at the server and returns to the client in the order defined by the TCP byte stream, while detected loss leads to retransmission. TCP handles numbering, acknowledgments, and retransmission, allowing Telnet to handle terminal formatting. Terminal characters and control commands travel through that one ordered stream, so Telnet does not define a separate datagram delivery mechanism.
Standard Port
By convention, Telnet servers listen for incoming connections on the well-known TCP port $23$ . A user initiating a Telnet session, for example by typing 'telnet server.example.com', is instructing their client software to open a TCP connection to port 23 on that server.
The Network Virtual Terminal (NVT)
Telnet uses a . Early systems and physical terminals differed in character sets and control codes, for example those used to move a cursor or clear a screen. NVT provides a standardized intermediate representation that the client and server map to their local hardware or operating system format. Its default character representation is seven-bit US-ASCII carried in an eight-bit field; the IAC value introduces Telnet commands, and options can change terminal behavior.
The Telnet client maps input from the local keyboard to NVT before sending it. The server maps commands and data from the host system to NVT in the direction of the client. This lets conforming implementations exchange data despite differences in hardware and operating systems. If an implementation does not support an option, it can reject that negotiation and continue with the NVT baseline.

3. Telnet Session Sequence

A typical Telnet session includes connection establishment, option negotiation, use of the remote service, and connection termination.

Connection Establishment: The user initiates the session. The Telnet client on the local machine opens a TCP connection to port 23 on the remote server.
Option Negotiation:After connecting, the client and server may exchange Telnet commands distinct from shell commands to agree on session parameters. The commands 'WILL', 'WON'T', 'DO', and 'DON'T' announce, accept, or reject options such as terminal type, character echo, and line-oriented operation. The result defines how NVT is used in that session. A rejected option leaves the endpoints with the behavior already supported by both sides.
Authentication: The service behind the Telnet server commonly displays a login prompt. The user provides a username and password accepted by the remote system when the service requires authentication.
Interactive Session: After authentication, the service can provide a command-line shell, such as Bash on Linux or the command prompt on Windows. Characters entered by the user travel to the server, while command output and prompts return to the client and appear in its terminal.
Session Termination:The user can log out of the remote shell, for example by typing 'exit' or 'logout'. The server then closes its side of the TCP connection, and the client closes its local side.

4. Telnet Security Limitations

The base Telnet protocol provides no confidentiality, cryptographic server authentication, or cryptographic data-integrity protection. An ordinary Telnet session should not be used on an untrusted network, including the internet.

Transmission without Encryption

In an ordinary Telnet session, data is transmitted without encryption. Telnet has a separate ENCRYPT option, but its default state is no encryption and it is not part of every implementation. This includes terminal characters, shell commands, server responses, and login data:

Usernames and Passwords: When you type your login credentials, they travel across the network as clear text, easily readable by anyone monitoring the connection.
All Commands: Every command you execute, whether it's 'ls -l', 'cat /etc/passwd', or 'sudo reboot', is sent as plain text.
All Server Output: The server response, including file contents, directory listings, error messages, and sensitive system information, is sent back as plain text.

Capturing Telnet Traffic

Without encryption, a person with access to the path between client and server can use a to capture Telnet traffic. The captured segments can be reassembled to view the session, including the username and password, and those credentials can then be used to access the system.

No Default Cryptographic Protection

The base Telnet protocol has no cryptographic mechanism to authenticate the server or protect data integrity. Extensions exist, yet their support and negotiation are not default properties of an ordinary session. The ENCRYPT option can protect confidentiality after successful negotiation, but it does not by itself authenticate the remote host or provide data integrity; an active attacker can also interfere with its negotiation.

No Server Authentication: An ordinary Telnet client cannot cryptographically verify that the server is the host it claims to be. The session is therefore vulnerable to , in which an attacker can impersonate the server and intercept login credentials.
No Data Integrity: The base protocol does not include a cryptographic mechanism for detecting changes during transmission. An attacker in a MITM position can read and modify commands or server responses without Telnet detecting the change.

5. Current Uses of the Telnet Client

Using the Telnet protocol for remote login is discouraged, but the Telnet client application can still help network administrators and developers. A simple client can open a raw TCP connection to a selected port, making it useful for basic diagnostics of other services. The client displays the exchanged text and control responses; it does not automatically interpret the application protocol running on the selected port or add encryption to that connection.

Checking Port Connectivity:The command can check whether a host accepts a connection on a given port. For example, to check a web service at 'server.example.com':
```
telnet server.example.com 80
```
If the connection succeeds, the port is reachable and accepted the connection. An error or timeout may indicate a closed port, filtering, or an unavailable host, so the result alone does not identify the cause.
Manual Protocol Interaction: A raw text client can send messages for other text-based protocols manually. It can help debug a web server by sending a simple HTTP request:
```
telnet www.google.com 80
GET / HTTP/1.1
Host: www.google.com
```
Testing Mail Servers:You can check an SMTP server's responsiveness by connecting to port 25 and sending SMTP commands such as 'EHLO'.
Managing Legacy Devices: In isolated, controlled private networks, Telnet may remain the only way to manage old network equipment or industrial control systems that do not support safer protocols. This use should be limited to a trusted environment.

6. SSH as a Secure Replacement

For remote command-line login over an untrusted network, the standard secure alternative is the protocol.

SSH provides mechanisms that are missing from the base Telnet protocol:

It encrypts session data, protecting usernames, passwords, and transmitted content.
It authenticates the server with a host key, limiting MITM risk when the key is verified correctly.
It supports user-authentication methods including public-key cryptography.
It protects data integrity with message-authentication mechanisms.

The Telnet client remains a diagnostic tool, while ordinary Telnet does not protect remote administration. For remote login over an untrusted network, SSH is the appropriate choice because its configured transport provides confidentiality, authentication, and integrity. SSH still depends on correct host-key verification and user-authentication configuration, so those operational checks remain part of a secure deployment.