Port 23: Telnet (and Why You Shouldn't Use It)

In 1969, when Telnet was born, the Internet was a few hundred machines run by researchers who knew each other. Sending commands across the network in plain text wasn't naive—it was practical. Why add complexity for encryption when you trusted everyone on the network?

That assumption aged catastrophically. Today, port 23 is a warning sign: any system still running Telnet is either dangerously misconfigured or trapped in legacy infrastructure. Understanding why requires seeing what Telnet actually does—and what happens when you do it on a network full of strangers.

How Telnet Works

Telnet gives you a terminal on a remote machine. You connect to port 23, see a login prompt, type your credentials, and get a command line. From there, you can do anything the remote system allows—configure servers, manage files, run diagnostics.

For three decades, this was how system administrators managed machines they couldn't physically touch. Data centers across the country, branch offices overseas, university servers across campus—all accessible from your desk through Telnet.

The protocol itself is simple. Your keystrokes travel to the remote machine; its responses travel back. Character by character, command by command, the entire session flows over the network.

Every character in plaintext.

The Problem You Can't Unsee

When you type your password into a Telnet session, each character travels across the Internet as readable text. Through your local network. Through your ISP. Through backbone routers. Every hop along the way can read it.

This isn't a theoretical vulnerability. Anyone running packet capture software on any network segment between you and the server sees everything: your username, your password, every command you type, every response you receive.

It gets worse. Without encryption, there's no way to verify you're talking to the real server. An attacker who intercepts your connection can present a fake login prompt, capture your credentials, and either relay the connection invisibly or walk away with valid authentication for your system.

SSH: The Protocol That Made Telnet Obsolete

In 1995, a Finnish researcher named Tatu Ylönen created SSH after a password-sniffing attack on his university network. The design was straightforward: provide everything Telnet does, but encrypt the entire session before anything sensitive crosses the wire.

SSH establishes an encrypted tunnel first, then authenticates. Your password never travels in plaintext. The server proves its identity cryptographically, so you know you're talking to the right machine. The entire session—commands, responses, file transfers—remains encrypted end to end.

SSH also added capabilities Telnet never had: public key authentication (no passwords needed), secure file transfer, port forwarding, and tunneling. It wasn't just more secure—it was more useful.

By the early 2000s, SSH had replaced Telnet everywhere security mattered. Today, choosing Telnet over SSH for remote administration is like mailing your passwords on postcards instead of in sealed envelopes.

Why Port 23 Still Exists

Telnet hasn't disappeared entirely. A few legitimate uses remain:

Protocol testing: Telnet clients let you manually type HTTP requests, SMTP commands, or other text protocols to see how servers respond. You're testing unencrypted protocols anyway, so Telnet's lack of encryption adds no risk.

Legacy equipment: Some industrial control systems and older network devices only speak Telnet. These typically sit on isolated networks where the security risk is contained.

Initial configuration: Network equipment sometimes requires Telnet for out-of-box setup before SSH gets configured. This happens over direct console cables, not networks.

Retro computing: BBS enthusiasts and retrocomputing hobbyists use Telnet for historical authenticity where security isn't a concern.

The pattern: controlled environments, isolated networks, testing scenarios, or situations where confidentiality doesn't matter.

What Happens When You Leave Port 23 Open

Attackers constantly scan the Internet for open port 23 services. Automated scripts try default credentials—admin/admin, root/root, the manufacturer defaults nobody changed—hundreds of times per day against any exposed Telnet service.

This isn't speculation. The Mirai botnet compromised hundreds of thousands of IoT devices specifically by exploiting Telnet services with default passwords. Cameras, routers, DVRs—devices shipped with Telnet enabled and never secured—became weapons in massive distributed attacks.

Even if your credentials are strong, the plaintext problem remains. Anyone who can observe your network traffic—your ISP, a compromised router, an attacker on your local network—captures those credentials. And since people reuse passwords, compromised Telnet credentials often unlock other systems. One weak link becomes a foothold for broader compromise.

The Lesson Port 23 Teaches

Telnet's story isn't about a protocol designed badly. It's about a protocol designed for a network that no longer exists.

The Internet of 1969 was a trusted space. Today's Internet routes your traffic through infrastructure controlled by strangers, across networks you've never heard of, past countless opportunities for interception. Protocols designed for trusted networks fail catastrophically in adversarial environments.

This lesson extends beyond Telnet. Every unencrypted protocol—FTP, HTTP without TLS, SMTP without STARTTLS—carries the same fundamental risk. The only difference is degree.

If you're running a Telnet service, disable it. If you're managing equipment that requires Telnet, isolate it. If you need remote access to anything, use SSH.

Port 23 served its purpose. That purpose ended decades ago.