SSH and Telnet solve a similar user problem but provide radically different security
Both protocols can provide remote command-line access, but the important distinction is how they protect the administrative session. Telnet sends terminal traffic without modern session encryption. SSH protects credentials and command traffic with encryption and integrity mechanisms, supports stronger authentication options, and provides host identity checks. For secure remote administration, SSH is the correct default.
SSH vs. Telnet at a glance
| Feature | SSH | Telnet |
|---|---|---|
| Default port | TCP 22 | TCP 23 |
| Session encryption | Yes | No modern session encryption |
| Credential protection | Protected in encrypted session | Plaintext exposure risk |
| Integrity protection | Yes | No comparable protected session integrity |
| Public-key authentication | Supported | Not equivalent |
| Server identity check | Host keys | No equivalent SSH host-key model |
| Modern administration | Preferred | Legacy/testing only |
Swipe horizontally to compare SSH and Telnet.
TCP 22 and TCP 23 identify defaults, not complete security policies
SSH commonly listens on TCP 22 and Telnet on TCP 23. Those defaults help identify the intended service, but a port number does not authenticate an administrator, verify a host, or restrict which source networks may connect. Services can also be configured on different ports.
Why plaintext administration is dangerous
Telnet session
An observer who can capture the traffic may be able to read credentials, commands, and output.
SSH session
The transport protects session content from straightforward passive reading and includes integrity protections.
SSH supports multiple authentication methods
SSH can use password authentication, public-key authentication, and other methods depending on server configuration. Public-key authentication can reduce reliance on reusable passwords, but security still depends on protecting the private key, controlling authorized keys, and limiting who is permitted to log in.
Key-based authentication changes what must be protected
The server stores or references the authorized public key. The administrator protects the private key. If the private key is copied or exposed, the security of that credential can be undermined even though SSH transport encryption remains intact.
SSH verifies more than the user—it also helps verify the server
SSH clients can remember server host keys. On later connections, an unexpected key change can trigger a warning. That warning should not be ignored automatically because it may represent either a legitimate server rebuild/change or an attempt to intercept the session.
The warning itself is evidence that transport connectivity reached an SSH endpoint; the unresolved issue is server identity trust.
SSH can fail at several distinct checkpoints
Hostname fails, numeric IP works
SSH transport itself is not the first problem. DNS or name resolution is the stronger dependency.
Server IP is reachable, but TCP/22 times out
Basic IP reachability is substantially proven. Investigate firewall policy, ACLs, service listener state, return path, or transport loss before replacing the cable.
TCP/22 is refused
An active refusal often means the path reaches a device capable of rejecting the connection. A missing SSH listener or local host policy becomes stronger than “all routing is broken.”
The SSH connection establishes, but authentication fails
The network path and SSH service are already substantially working. Move to account state, authorized keys, password policy, authentication method, or authorization—not basic connectivity.
The client warns that the host key changed
Do not simply delete the known-host entry without verification. Confirm whether the device was rebuilt, replaced, rekeyed, restored from backup, or is being intercepted. The warning is a security signal, not a nuisance message.
Least privilege matters even when the protocol itself is encrypted
SSH encryption protects the session content, but it does not eliminate the need to restrict administrative exposure.
Why Telnet still matters as a comparison protocol
Telnet remains useful for understanding why security requirements matter. It illustrates how two protocols can deliver similar terminal functionality while offering very different protections. It may also appear on legacy systems or in controlled lab environments.
A capture can visually demonstrate the security difference
In a controlled lab, Telnet payload data may be readable in captured traffic. SSH application payload is encrypted. The capture does not mean SSH is invulnerable; it demonstrates that passive observation does not expose ordinary SSH session content the way plaintext Telnet can.
SSH security depends on more than encryption
Transport protection
Encrypt and integrity-protect the session.
Identity
Verify the server host key and authenticate the user.
Authorization
Limit what an authenticated account may do.
Network policy
Restrict which source networks can reach management services.
What each successful checkpoint proves
| Checkpoint | What it proves | What remains unresolved |
|---|---|---|
| DNS resolves | Name resolution works for that query | TCP/22 reachability |
| Ping succeeds | Useful IP/ICMP reachability | SSH transport/service |
| TCP/22 connects | Transport to SSH port is open | SSH handshake/authentication |
| SSH handshake succeeds | SSH service is responding | User auth/authorization |
| User authenticates | Credential accepted | Command authorization/session policy |
Swipe horizontally to see the evidence matrix.
Verify secure access and prohibited access after a change
If you enable SSH on a router, test from the authorized management network, confirm the expected host key, authenticate with the intended method, and verify required commands work. Then test a prohibited source and confirm access remains blocked. If Telnet is being retired, verify TCP/23 is no longer available where policy forbids it.
Answer the security requirement, not just the port number
Instead of writing “SSH uses port 22,” write: “Use SSH for secure remote administration because it encrypts the session and provides integrity and host identity mechanisms. Restrict TCP/22 to authorized management sources and verify both successful authorized access and blocked unauthorized access.”
24 SSH vs. Telnet digital flashcards
Practice default ports, encryption, plaintext risk, authentication, public keys, host keys, SSH troubleshooting stages, firewall policy, packet-capture evidence, and secure verification.