Telnet: The Network Virtual Terminal for Remote Systems
Telnet standardized terminal interaction across incompatible hosts using a virtual terminal and negotiated options long before encrypted shells.
Telnet is commonly described as a remote-login command, but its original purpose was broader: provide a general bidirectional communication facility between terminal devices and terminal-oriented processes on different hosts. RFC 854, published in May 1983, defines Telnet as an eight-bit byte-oriented protocol whose primary goal is to offer a standard interface between terminal equipment and applications. The remote login use case made it famous, but the protocol’s central abstraction was a Network Virtual Terminal (NVT) that gave unlike systems a common baseline.
The problem was heterogeneity. Terminals and operating systems differed in character handling, line endings, echo behavior, interrupt signals, and interactive conventions. A program written for one local terminal could not assume that a remote terminal used the same control characters or display model. Telnet introduced a virtual terminal representation and a negotiation mechanism so the two ends could start with shared defaults and agree on optional behavior.
The Network Virtual Terminal is a common denominator
The NVT is a conceptual endpoint at each side of a Telnet connection. Each local system maps its own terminal and process behavior to the NVT representation, and the network carries that shared representation. This does not mean every physical terminal had the same capabilities. It means a Telnet implementation could provide a baseline and negotiate extensions for capabilities that both ends understood.
RFC 854 specifies a TCP connection and standard representations for control functions such as Interrupt Process, Abort Output, Are You There, Erase Character, and Erase Line. It also defines rules for carriage return and line feed behavior. Those details addressed real incompatibilities: a carriage return could move the cursor without advancing a line, while a line feed could advance without returning to the first column. A network terminal protocol needed to say what those bytes meant rather than assume every host made the same choice.
Telnet data and commands share the same byte stream. The Interpret As Command byte, decimal 255, introduces a Telnet command. If an application needs to send a literal 255 as data, it must escape it by sending it twice. That in-band command mechanism keeps the protocol compact but requires clients and servers to parse the stream correctly. It is one reason Telnet implementations are protocol engines, not just programs that copy keyboard input to a socket.
Negotiated options let systems adapt
Telnet’s negotiation commands include WILL, WON'T, DO, and DON'T. One side proposes or agrees to perform an option; the other can accept or refuse it. RFC 855 defines the option mechanism. Options can specify behavior such as echo, binary transmission, suppress-go-ahead, terminal type, or window size. The two endpoints negotiate directionally, which matters because a client might echo locally while a server refuses to echo, or one side may support binary mode while the other does not.
The negotiated model avoided requiring every host to implement every terminal capability. A basic NVT connection could still work, while more capable pairs could agree on richer behavior. It also created failure modes: clients and servers can disagree on option state, incorrectly answer negotiations in loops, or interpret data under a mode that only one side believes is active. Implementations need explicit state tracking and should follow the option specification rather than assume a modern terminal emulator’s behavior.
Telnet became useful not only for remote login but also as a transport substrate for other interactive services and diagnostics. FTP’s 1985 specification, RFC 959, says its control connection uses Telnet rules, either through a shared Telnet module or by implementing those rules internally. That is a revealing example of how the Network Virtual Terminal escaped the narrow idea of logging into a shell: its common representation helped unrelated host applications exchange structured commands.
Option negotiation also gave the protocol a deliberately asymmetric vocabulary. DO and DON'T ask a remote peer to enable or disable an option on its side; WILL and WON'T state whether the sender will perform an option locally. For example, an endpoint might send IAC DO ECHO to ask the peer to echo characters, then accept IAC WILL ECHO or handle IAC WONT ECHO. The meanings are defined per option, so the same four verbs do not imply a universal behavior independent of the option specification. A robust implementation tracks the state for each direction and option, avoids endless renegotiation, and treats unsupported options as a normal outcome rather than as a protocol crash.
The command introducer is also an example of a compatibility trade-off. Because ordinary data can contain any eight-bit value, the protocol needs a way to distinguish the byte 255 as data from byte 255 as a control marker. Doubling it represents the literal data value; following it with a command code changes parser state. If an implementation loses framing after a malformed or truncated command, subsequent user input may be interpreted as negotiation rather than terminal text. Protocol-aware testing should include fragmented TCP reads, doubled command bytes, refusals, and options proposed simultaneously by both endpoints.
The NVT’s defaults were chosen to work across the terminal conventions of its era, not to reproduce every local terminal exactly. The standard described a half-duplex, line-buffered conceptual device even though the underlying TCP connection is full duplex, and it defined behavior for carriage return and line feed. Options such as binary transmission changed assumptions that were otherwise suitable for ordinary terminal text. That baseline let minimal systems interoperate, while option negotiation gave more capable systems a path to agree on richer operation. It is an early example of the protocol-design pattern of a conservative base mode plus explicit capability negotiation.
The security weakness is fundamental to the old use case
Telnet’s base protocol does not encrypt traffic or authenticate the remote host. Usernames, passwords, and session data can be observed by an attacker with access to the network path. A firewall that permits TCP port 23 does not make Telnet safe, and an obscure terminal option does not add cryptographic protection. The convenience of an interactive session was designed for a network environment with assumptions that do not hold on today’s untrusted networks.
Secure Shell emerged as a safer remote-login alternative by adding server host keys, user authentication, confidentiality, and integrity. SSH was first published in 1995, and later SSH-2 documents specify distinct transport, authentication, and connection layers. SSH is not merely “Telnet with encryption”: it has its own protocol architecture, key exchange, host-key trust model, and channel semantics. The comparison is useful because it shows how the threat model changed from terminal compatibility to authenticated secure remote access.
Telnet still appears in controlled laboratory setups and in diagnostic access to services that speak a simple text protocol. Even there, operators should avoid sending secrets and should prefer a purpose-built client that handles the target protocol’s framing, TLS, and authentication correctly. A successful TCP connection to port 23 or another port proves only that a socket accepted data; it does not prove that the remote service is Telnet or that the connection is safe.
What Telnet reveals about protocol design
Telnet shows how standards can preserve a minimum interoperable behavior while allowing optional features. The NVT gave unlike systems a common basis. Explicit control functions made interactive actions more portable. In-band command negotiation allowed endpoints to discover shared terminal behavior. These ideas were useful when machines and peripherals were far less uniform than they are today.
It also illustrates how assumptions become liabilities. The original specification focused on compatibility and interaction, not encryption. Later deployments inherited the protocol’s name and port but often used it over networks where passive observation and active interception were realistic. The protocol did not become insecure because its users failed to configure a hidden encryption checkbox; its core design simply did not provide modern transport protection.
For historical troubleshooting, RFC 854 and RFC 855 are more reliable than descriptions that equate Telnet with a specific command-line program. The RFCs explain the virtual terminal, byte stream, command introducer, and option negotiation. RFC 5198 later updates the character-format guidance for network interchange, while SSH illustrates a different security architecture developed for remote administration. Read together, those documents show the evolution from agreeing how terminals talk to protecting who is talking and what can safely travel over the connection.
Telnet’s legacy is therefore twofold. It standardized terminal interaction across heterogeneous hosts, and its limitations helped make the need for secure remote access impossible to ignore. The NVT was a powerful interoperability idea; plaintext remote login is not an acceptable default on an untrusted network. Modern administrators can appreciate the former while retiring the latter from exposed infrastructure.
Related:
- SSH’s History: Turning Remote Login into an Encrypted Protocol
- FTP’s Long Evolution: From ARPANET File Sharing to RFC 959
Sources: