Telnet is a remote access protocol from 1969 that gives you a text terminal on a remote computer over TCP port 23. It sends all data in the clear, including the password typed at the login prompt, so anybody on the path can read the session and the credentials.
SSH replaced it by doing the same job inside an encrypted, authenticated channel. What survived is the telnet client, which is still a fast way to check whether a TCP port answers.
- A remote access protocol on TCP port 23, and it is not secure
- The password is sent as readable characters, which is the whole problem
- SSH does the same job on port 22, encrypted and authenticated
- The client is still useful for testing whether a port answers
- Modern equivalents are Test-NetConnection and nc -zv
On this page
The protocolWhat telnet actually does
Telnet negotiates a network virtual terminal between two computers: a user keystroke travels to the far end and its output comes back, character by character, as data over one TCP connection. It is one of the oldest protocols still in use and it does its job well, which is why it lasted so long.
RFC 854, published in May 1983 by Postel and Reynolds, is the specification. It defines that network virtual terminal and an escape byte called Interpret As Command, which is how telnet mixes control codes into the same data stream. The word security does not appear anywhere in the document.
The design assumption is the one that dated. Telnet was written for the early internet, a research network of mutually trusting institutions, where nobody in the middle was a security concern.
There is no encryption anywhere in the protocol and there was never meant to be, because the internet it was designed for did not have hostile intermediaries in its threat model.
That means the login exchange is readable. A packet capture on any hop between the two computers shows the user name, then the password, as ordinary characters in the data stream.
This is not a weakness in an implementation and no configuration fixes it, because the protocol has nowhere to put a key. Reading a telnet session out of a packet capture is the standard demonstration in any first networking class, and it takes about ten seconds.
The same is true in both directions. All data the far end prints, including configuration, is equally visible, so a telnet session to a switch exposes the running config to anybody watching. There is no secure mode to switch on.
SecurityThe four security properties, and which ones telnet has
Secure remote access is usually discussed as one thing. It is four, and telnet provides none of them, which is why no configuration setting rescues it.
Confidentiality. Nothing in a telnet session is hidden. Credentials, commands and output are readable by anything on the path between the two systems.
Integrity. Nothing detects a change made to the stream in flight. An attacker in the middle is not limited to reading the session and can inject commands into it, which is a larger problem than the password and gets far less attention.
Server authentication. Telnet cannot tell you which computer answered. A redirected connection to an impostor looks exactly like the real thing, and the user types the password into it.
User authentication. The login prompt belongs to the remote system, not to the protocol. Telnet carries the characters and has no concept of an identity, a key or a credential of its own.
SSH is built the other way around. RFC 4251 describes it as three protocols: a transport layer protocol that provides server authentication, confidentiality and integrity, a user authentication protocol that authenticates the client to the server, and a connection protocol that multiplexes channels inside the encrypted tunnel.
RFC 4252 names the user authentication methods. Public key authentication, written "publickey", is the only method an implementation is required to support, while "password" and "hostbased" are optional. That ordering is the reason key based access became the normal way to run anything automated.
What SSH addedWhat SSH changed
SSH arrived in 1995 and did three things telnet does not.
It encrypts the session. Every byte of data after the handshake is protected, so a capture in the middle yields nothing usable, which is the whole security difference. The encryption algorithms involved are negotiated rather than fixed, which is why an old SSH server can be weak in ways a current one is not.
It authenticates the server. The first connection presents a host key fingerprint, and every connection after that checks it. That warning about a changed host key is the protocol telling you the machine at the other end is not the one you talked to before, which is exactly the attack telnet cannot detect.
It authenticates the user with keys, not just passwords. A key pair means no shared secret crosses the network at all, and it is the practical reason SSH is used for automation.
Everything else follows from those three. Port forwarding, SFTP, SCP and tunneling all exist because SSH provides an authenticated encrypted channel that other things can be carried inside. SSH on port 22 became the default secure remote access protocol on every Unix system and on most network hardware, and telnet became the thing you find and turn off.
Still usefulThe one job telnet kept
Here is the part most articles miss while declaring the protocol dead. The telnet client is still one of the fastest ways to answer a specific question: is this TCP port open, and does something answer on it.
telnet mail.example.com 25
telnet 10.0.0.20 443If the connection opens you have proved three things at once: the route across the network works, nothing in between is blocking that port, and a server is listening. If it refuses immediately, something answered and said no. If it hangs, a firewall is dropping rather than rejecting, which is a different problem with a different fix.
For text protocols it goes further, because you can type the protocol by hand. Connecting to port 25 and typing EHLO test gets you the mail server's real banner and capabilities. That is a genuine diagnostic that no amount of clicking reproduces.
The client has a few commands of its own, and one of them matters. Control and the right bracket key returns you to the telnet prompt from inside a session, where quit closes the connection. Sessions left open because nobody knew that are a small but real reason people avoid the tool.
Two limits are worth knowing. It only tests TCP, so nothing that runs over UDP can be checked this way.
On anything encrypted, TLS included, the connection will open and then produce no readable data, because the server is waiting for a handshake that a raw terminal cannot perform. For that, openssl s_client -connect host:443 is the right tool.
ReplacementsWhat to use instead
The telnet client is not installed by default on current Windows or on most Linux distributions, and enabling it is not worth doing when better tools are already there.
| Job | Windows | Linux or macOS |
|---|---|---|
| Is this TCP port open | Test-NetConnection host -Port 443 | nc -zv host 443 |
| What answers on it | Test-NetConnection then read | nc host 25 |
| Is this an HTTP service | curl -I https://host | curl -I https://host |
| Is TLS working | openssl s_client -connect host:443 | openssl s_client -connect host:443 |
| Remote terminal | SSH | SSH |
| Scan a range of ports | Test-NetConnection in a loop | nmap |
Test-NetConnection, abbreviated tnc, is the PowerShell answer and it reports more than telnet did: whether the name resolved, whether the ping succeeded, which interface was used and whether the TCP connection completed. On Linux, nc -zv does the same job in less typing.
The one thing telnet still does better is the interactive part. Neither Test-NetConnection nor nc -z lets you type at the far end, so for hand-driving a text protocol, nc host port without -z is the closest equivalent.
Finding itWhere telnet is still running, and what to do about it
It is not gone from real networks, and the places it survives share a pattern: devices old enough or cheap enough that nobody added a second protocol.
Network hardware. Switches and routers a decade old often have telnet enabled alongside SSH, and the secure side is sometimes the one that was never configured. A device that accepts both accepts the weak one from anybody who asks.
Printers, cameras and building systems. Management interfaces on hardware whose firmware stopped being updated years ago, often reachable from the internet by accident. This is also the category most likely to have a default user and password still set.
Industrial and lab equipment. Instruments and controllers with long service lives and no upgrade path. Here the honest answer is often network isolation rather than protocol replacement, because the vendor will not ship a fix.
The remediation order that works is short. Disable telnet where SSH already exists, which is most of the switch estate. Where SSH does not exist, restrict network access so that only a management host can reach the device.
Where neither is possible, document the exception with a date and a reason rather than pretending it is not there, because an auditor will find port 23 open and the answer needs to be a decision rather than a surprise.
Finding it is straightforward: scan the management ranges for TCP 23 open. Anything that answers is either a device to fix or an exception to record.
ComparisonTelnet, SSH, a serial console and a web UI
| Criterion | Telnet | SSH | Serial console | Web UI |
|---|---|---|---|---|
| Encrypted | No | Yes | Not networked | With TLS |
| Authenticates the server | No | Host key | Physical access | Certificate |
| Key based login | No | Yes | No | Rarely |
| Works when the network is down | No | No | Yes | No |
| Scriptable | Poorly | Yes | Awkward | By API, if there is one |
| Still installed by default | No | Yes, on Unix | On the hardware | Yes |
| Good for testing a port | Yes | No | No | No |
The fourth row is why serial consoles have not disappeared either. When a device is unreachable over the network, the out of band path is the one that still works, and it is worth knowing which of your devices has one before you need it.
FAQFrequently asked questions
What is telnet?
A protocol that gives you a text terminal on a remote machine over TCP port 23. It dates from 1969, was specified in RFC 854, and sends everything including passwords in plaintext.
What port does telnet use?
TCP port 23. SSH, which replaced it, uses TCP port 22.
Is telnet secure?
No, and it cannot be made secure. There is no encryption anywhere in the protocol and nowhere to add it, so credentials and all session data are readable by anything on the network path.
Why did SSH replace telnet?
Because SSH provides secure remote access: the same job inside an encrypted channel, with the server identity verified by a host key and key based login so no user secret crosses the network.
Can I still use telnet to test a port?
Yes, and it is the one job worth keeping it for. telnet host 443 proves whether the route works, whether anything blocks the port, and whether a service is listening.
What is the modern alternative for testing ports?
Test-NetConnection host -Port 443 on Windows, nc -zv host 443 on Linux and macOS. Both report more than telnet did, and neither needs an extra component installed.
Why does my telnet test to an HTTPS port show nothing?
Because the far end is waiting for a TLS handshake that a raw terminal cannot perform. The connection opening is still useful information; to see the certificate and the negotiation, use openssl s_client -connect host:443.
Is the telnet client installed on Windows?
Not by default. It is an optional feature that has to be turned on, which is a reasonable default given that better tools ship with the operating system.
How do I find telnet still running on my network?
Scan the management ranges for TCP port 23 open. Anything that answers is either a device to fix or an exception to document with a reason and a date.
Should I disable telnet on my switches?
Yes, wherever SSH is configured and working. A device that accepts both will happily accept the insecure one from anybody who asks for it.
What if a device only supports telnet?
Put it on a management segment that only a jump host can reach, and record the exception rather than leaving it undocumented. Old industrial and lab equipment is the usual case and the vendor is usually not going to fix it.
Does telnet work over UDP?
No. It runs over TCP, which is also why it cannot be used to test a UDP service. For those, nmap -sU is the tool, and the answers are less definitive because UDP has no handshake.
Can I use telnet to talk to a mail server?
Yes, and it is a classic diagnostic. Connect to port 25 and type EHLO test to see the real banner and capability list, which tells you more than any status page.
Is telnet the same as a terminal emulator?
No. A terminal emulator such as PuTTY is the program; telnet and SSH are protocols it can speak. The confusion is common because PuTTY was for years how most people used both.
Why is Telnet insecure?
Telnet sends everything in clear text, including the username and password, so anyone on the path can read a session. It has no encryption and no way to confirm which server you reached. That is why Telnet is insecure for remote login, and why SSH replaced it.
How do I test a port with the telnet command?
Run the telnet command followed by the host and the port, for example telnet mail.example.com 25. A blank screen or a banner means the port is open, and a connection error means it is closed or filtered. To test a port with telnet on Windows, first enable the Telnet Client feature, or use Test-NetConnection instead.
Keep readingRelated concepts
Read next · Ports What Is a Port Number? Why 23 and 22 are different doors on the same machine, and what testing one actually proves. Open this next12 min- Diagnostics · 12 min Reading a Wireshark Capture Without Drowning in Packets How the left panel above is produced, which takes about ten seconds on a switched network you can see.
- Ports · 10 min Port 22, and Why Changing It Is Not the Fix People Think The protocol that replaced it, and what the host key warning is actually telling you.
- Ports · 9 min Port 21, and the Second Connection Nobody Expects The parallel case.