SSH vs Telnet

Telnet: Remote Access Before Encryption

Telnet was one of the first application protocols defined for the ARPANET. Standardized in 1969 and formalized in RFC 854, it was designed to allow a user at one terminal to interact with a remote system as if directly connected. The protocol defines a Network Virtual Terminal (NVT) — a simplified abstraction of a terminal device — that allows clients and servers with different character encodings and terminal capabilities to communicate.

The fundamental design assumption of Telnet was that the network was trusted. In the early ARPANET era, this was reasonable: the network connected a small number of research institutions with vetted users. Telnet worked adequately under those conditions. What it was never designed to do was operate securely across an untrusted public network — and that design limitation became catastrophic as the internet grew.

The Security Problem with Telnet

Telnet operates over TCP port 23 and transmits every byte of data in plaintext — including usernames, passwords, commands, and output. Any device positioned between the Telnet client and server can read the entire session with a standard packet capture tool. This is not a theoretical attack: it is trivial to execute on shared Ethernet, Wi-Fi networks, or any network where an attacker controls an intermediate router or switch.

The consequences are severe for administrative sessions. An attacker who captures a Telnet login to a network router or server obtains the administrator's credentials in cleartext. They can replay those credentials, use them on other systems (credential reuse), or watch in real time as the administrator makes changes. There is no way to add encryption to Telnet without replacing it entirely — the protocol has no provision for negotiating a secure channel.

SSH: Built as a Direct Response to a Real Attack

SSH was created in 1995 by Tatu Ylönen, a researcher at Helsinki University of Technology, after his university network suffered a password-sniffing attack that harvested credentials from plaintext protocols including Telnet. He developed SSH specifically to replace Telnet, rsh, and rcp with an encrypted alternative. The first version was released as freeware and spread rapidly through the Unix community.

The Internet Engineering Task Force later standardized SSH-2 (RFC 4251–4256, published 2006), fixing cryptographic weaknesses in the original SSH-1 design. OpenSSH, the most widely deployed SSH implementation, is open-source software maintained by the OpenBSD project and shipped in virtually every Linux distribution, macOS, and Windows 10 and later.

How SSH Addresses Every Telnet Weakness

SSH replaces Telnet's plaintext channel with a cryptographically secure one. Before any authentication occurs, the client and server perform a Diffie-Hellman key exchange to establish a shared secret, then derive a symmetric session key that encrypts all subsequent traffic. An observer who captures the handshake cannot derive the session key without solving the discrete logarithm problem — computationally infeasible with modern key sizes.

SSH also verifies the identity of the server through host keys. The first time you connect to a server, your SSH client records its public host key in ~/.ssh/known_hosts. On every subsequent connection, the client verifies the server presents the same key. If the key changes unexpectedly — a sign of a potential man-in-the-middle attack — the client refuses to connect and alerts you. Telnet has no equivalent mechanism; you cannot verify you are connected to the server you intended.

Port Differences and Protocol Versions

Telnet uses TCP port 23. SSH uses TCP port 22. Both are IANA-registered well-known ports. Unlike SSH, Telnet has no "secure variant" — there is no TLS-wrapped Telnet that is safe to use over untrusted networks. Some implementations support "Telnet over TLS" (TELNETS) on port 992, but this is extremely rare and effectively abandoned. The practical choice is always between Telnet (port 23, plaintext) and SSH (port 22, encrypted).

When Telnet Is Still Used

In the modern internet, legitimate Telnet use is narrow. The most common surviving case is console server access: a terminal server connects to the serial console ports of network equipment (routers, switches, out-of-band management interfaces) in a physically isolated lab or data center. The terminal server itself may offer Telnet access to those serial ports, but the network carrying that Telnet traffic is air-gapped or tightly controlled.

The other common use is port testing. Running telnet hostname port — for example telnet mail.example.com 25 — opens a raw TCP connection to verify a service is listening and see its banner. This is a diagnostic technique, not actual remote management. For this purpose, nc -v hostname port or ncat hostname port are better alternatives that work without a Telnet client installed.

SSH vs Telnet Compared

nc and ncat as Safer Alternatives for Port Testing

If your goal is to verify that a TCP port is open and inspect a service banner, you do not need the Telnet client. nc -v hostname port opens a raw TCP connection and lets you interact with the service directly. ncat hostname port (from the Nmap project) does the same with additional options for TLS and UDP. Both tools are available on Linux, macOS, and Windows, and neither requires the telnetd daemon or the telnet client package to be installed. On systems where even nc is unavailable, curl -v telnet://hostname:port opens a TCP connection and can substitute for basic port reachability testing.

Frequently Asked Questions

Why is Telnet considered insecure?

Telnet transmits all data — including usernames, passwords, and every command you type — as unencrypted plaintext over TCP. Any device on the network path between you and the server can read the entire session using a packet capture tool like Wireshark. This is especially dangerous on shared networks such as Wi-Fi hotspots, campus networks, or ISP infrastructure where a compromised router can silently log all Telnet sessions. SSH eliminates this risk by encrypting the entire session.

What port does Telnet use vs SSH?

Telnet listens on TCP port 23 by default. SSH listens on TCP port 22 by default. Both port numbers are well-known and registered with IANA. Unlike SSH, Telnet has no encrypted variant — port 23 always means plaintext. SSH servers are sometimes moved to non-standard ports to reduce automated attack traffic, but port 22 remains the universal default.

Can I use Telnet to test if a port is open?

Yes, this is one of the few remaining legitimate uses of the Telnet client. Running telnet hostname port — for example, telnet smtp.example.com 25 — opens a raw TCP connection and lets you verify that the port is listening and inspect the service banner. However, nc (netcat) or ncat are better tools for this purpose because they are available on more systems, support both TCP and UDP, and do not require the Telnet daemon to be installed.

Is Telnet still used anywhere?

Telnet survives in a few narrow contexts: console access via terminal servers connected to the serial ports of network equipment in isolated lab environments; legacy embedded devices such as industrial controllers and old printers that have no SSH support and are air-gapped from public networks; and as a diagnostic tool for checking TCP port connectivity. For any system reachable from the internet or a shared network, Telnet should be disabled and replaced with SSH.

What replaced Telnet for network device management?

SSH replaced Telnet as the standard remote management protocol for network devices. Cisco, Juniper, Arista, and all major network equipment vendors have supported SSHv2 for over two decades and actively recommend disabling Telnet. Modern devices also support NETCONF over SSH and RESTCONF over HTTPS for programmatic configuration management, which provide structured data interfaces beyond the traditional command-line session.

How do I connect via Telnet vs SSH?

To connect via Telnet: telnet hostname (uses port 23) or telnet hostname port for a specific port. To connect via SSH: ssh user@hostname (uses port 22) or ssh -p 2222 user@hostname for a non-standard port. Telnet requires only the hostname because it does not authenticate users at the protocol level — authentication happens in the application after the connection is established. SSH requires a username because it performs cryptographic authentication before granting access.