SSH vs Telnet
SSH and Telnet both provide remote terminal access, but SSH wraps the session in encryption while Telnet sends raw text over TCP. A single packet capture on a network segment reveals every Telnet password, command, and response. SSH negotiates encryption algorithms, authenticates the server to the client (preventing MITM), and optionally uses public key authentication eliminating passwords entirely. Telnet (RFC 854, 1983) predates security concerns of modern networks. SSH (RFC 4251, 2006) was designed specifically to replace it. The only remaining legitimate use of Telnet is the initial out-of-band console setup of new network equipment that ships without SSH keys provisioned.
SSH encrypts the entire session including authentication. Telnet transmits everything in cleartext – passwords, commands, and output are visible to any network observer. SSH replaced Telnet for all remote administration. Telnet remains only for initial console setup of network devices with no SSH firmware.
| Feature | SSH | Telnet |
|---|---|---|
| Encryption | Full session encryption (AES-256-GCM, ChaCha20) | None – all traffic in cleartext |
| Authentication | Public key, password, Kerberos (GSSAPI), certificate | Password only – sent in cleartext |
| Server verification | Host key fingerprint prevents MITM | None – no way to verify server identity |
| Port forwarding | Local, remote, and dynamic (SOCKS) tunneling | Not supported |
| File transfer | Built-in SFTP and SCP | Not supported (requires separate FTP) |
| Default port | 22 | 23 |
| Key exchange | Diffie-Hellman, ECDH, curve25519 | None |
| Integrity | HMAC-SHA2 or AEAD protects against tampering | None – traffic can be modified in transit |
| Session multiplexing | Multiple channels over one connection | Single stream only |
| Compression | Optional zlib compression | Not supported |
| Current status | Universal standard for remote access | Deprecated – security liability |
When to use SSH
Always. SSH is the correct choice for any remote terminal access, file transfer, or port forwarding. Use key-based authentication with Ed25519 keys, disable password auth, and restrict with AllowUsers/AllowGroups.
When to use Telnet
Only for initial console setup of network devices (switches, routers) that ship without SSH configured, accessed via serial console or out-of-band management. Replace with SSH immediately after initial provisioning.
Common Mistakes
- Leaving Telnet enabled on network equipment after SSH is configured – attackers fall back to Telnet if SSH fails or times out.
- Using Telnet for quick debugging ('just checking if the port is open') on production networks where credentials might be typed – use 'nc -zv host port' instead.
- Assuming internal networks are safe for Telnet – ARP spoofing on the LAN captures Telnet sessions trivially.
- Not disabling Telnet in router configs after enabling SSH – 'transport input ssh' on Cisco IOS, 'set system services delete telnet' on Junos.
FAQ
Is there any scenario where Telnet is acceptable?
Only for initial out-of-band device provisioning via serial console adapter, or testing TCP connectivity (replaced by nc/ncat). Never for production remote access.
Does Telnet have any advantage over SSH?
Marginally less CPU usage on extremely constrained devices (rare today). Some legacy SCADA/ICS equipment only supports Telnet – isolate these on a dedicated management VLAN with no internet path.