SSH vs Telnet — the core exam distinction
Both SSH and Telnet give you a remote command-line interface to a network device. The difference is everything that happens to the data in transit — and this distinction is one of the most reliably tested comparisons across A+, Network+, and Security+.
| Feature | SSH | Telnet |
|---|---|---|
| Port | TCP 22 | TCP 23 |
| Encryption | ✓ Fully encrypted | ✗ Plaintext — everything visible |
| Credentials | ✓ Encrypted in transit | ✗ Username and password sent in cleartext |
| Authentication | Password or public key | Password only |
| Integrity | ✓ MAC ensures data hasn't been tampered with | ✗ No integrity checking |
| Status | Current standard — use this | Deprecated — security risk, never use |
| Use case | Managing servers, routers, switches, firewalls remotely | Legacy only — occasionally seen on isolated lab networks |
"A network administrator needs to remotely manage a switch securely. Which protocol should they use?" → SSH (port 22) — not Telnet (port 23), which transmits credentials in plaintext.
"A technician captures network traffic and can read the administrator's username and password in the packet capture. Which remote access protocol is being used?" → Telnet — SSH would have encrypted those credentials.
How SSH works — the connection process
When you connect via SSH, several things happen before you ever type a command. The protocol establishes an encrypted channel and authenticates both the server and the client before any data is exchanged.
Password authentication vs public key authentication
SSH supports two main ways to prove your identity to a server. Password authentication is simpler but weaker. Public key authentication is more secure and is the standard for servers and network equipment in professional environments.
Your machine: private key (id_rsa — never leaves your machine) Remote server: public key (~/.ssh/authorized_keys — placed there once) During login: 1. Server sends a random challenge message 2. Your client signs it with your private key 3. Server verifies the signature using your public key 4. Signature valid → authenticated — no password ever sent
Public key authentication provides stronger authentication than passwords because the private key is never transmitted — an attacker intercepting traffic cannot capture it. It also eliminates the risk of password brute force attacks against the SSH service.
Disabling password authentication entirely and requiring key-based auth is a Security+ hardening best practice for SSH servers. The exam may describe this as "requiring certificate-based authentication."
Common SSH commands
# Connect to a remote host ssh contact@itstudyhub.org ssh contact@itstudyhub.org · Privacy Policy · Disclosure: Some links on this site may be affiliate links. I may earn a small commission at no extra cost to you.