23 Telnet TCP Flagship

What it's for

Port 23 is the default port for Telnet, one of the earliest remote-access protocols on the internet — it lets a client open an interactive text session on a remote machine, essentially a virtual terminal over the network. For decades this was the standard way to administer remote servers and network equipment.

Telnet has been almost entirely superseded by SSH (port 22) for anything touching production systems, but the protocol itself lives on in a narrower, still-legitimate role: quick manual testing of whether a TCP port is open and responding (telnet host port), and administration of older network hardware that never got an SSH upgrade.

Protocol basics

• Protocol: TCP, providing the reliable connection needed for an interactive terminal session.
• No encryption whatsoever. Every character typed — including usernames and passwords — is transmitted in plaintext, visible to anyone who can observe the network path.
• Simple negotiation. Telnet has an option negotiation mechanism (terminal type, echo mode, window size) but nothing resembling modern authentication or encryption layers.
• Still useful as a raw TCP testing tool. Because a telnet client simply opens a raw TCP connection and lets you type, it's commonly repurposed to manually test whether any TCP service (not just Telnet servers) is reachable, independent of its actual protocol.

Security considerations

• Never use Telnet for anything beyond isolated legacy equipment on a trusted internal network. Credentials sent over Telnet are trivially interceptable by anyone with network access, including basic packet capture tools.
• Exposing port 23 to the internet is a well-known target for botnets — the Mirai botnet, one of the most notorious IoT malware campaigns, specifically scanned for devices with Telnet open and default credentials.
• If you must administer legacy hardware over Telnet, isolate it on a dedicated management VLAN with no direct internet exposure, rather than treating it as routinely accessible.
• The fix, in almost every case, is migrating to SSH — nearly all modern network equipment supports SSH as a drop-in replacement for the same administrative functions Telnet used to provide.

Troubleshooting

"telnet: command not found":

• Many modern OSes (including recent Windows and macOS) no longer ship the Telnet client by default since it's considered legacy/insecure — it needs to be explicitly installed or enabled

Using telnet host 80 to test a web server and getting garbled output:

• This is expected — you're opening a raw TCP connection to an HTTP server, not speaking HTTP. Typing an actual HTTP request manually (e.g., GET / HTTP/1.1) will get a real response; this is a legitimate low-level debugging technique, not a bug

Connection refused on port 23:

• No Telnet service is running (increasingly the norm and a good sign, not a problem), or a firewall is blocking it

Comparison / FAQ

Is it ever okay to use Telnet in 2026?

Only for two narrow cases: administering isolated legacy hardware with no internet exposure, or using the telnet client purely as a generic raw-TCP connectivity testing tool (not actually speaking the Telnet protocol to a Telnet server). For any real remote administration, SSH is the correct choice.

Why do people still use the telnet command if the protocol is insecure?

Because the client itself is a convenient, universally available way to test whether a raw TCP port is open and responding, regardless of what protocol actually runs on it — it's a debugging tool as much as a protocol client.

Why was Telnet such a common target for botnets like Mirai?

Because so many IoT and embedded devices shipped with Telnet enabled and default (often hardcoded) credentials, combined with Telnet's total lack of encryption, making mass automated compromise straightforward at internet scale.

What replaced Telnet for network equipment administration?

SSH is now standard on virtually all modern routers, switches, and network appliances, providing the same interactive command-line access with encryption and stronger authentication.