3.8. Network Device Management Access
💡 First Principle: Every network device needs to be managed—configured, monitored, troubleshot. Think of it like doors to a building: the console port is the physical front door that requires a key, while SSH is a secure remote entrance with a keypad and camera. Telnet? That's leaving the back door wide open with a welcome mat. The challenge is balancing accessibility with security—which doors do you leave open, and how do you protect them?
What happens with insecure management access: Consider this attack scenario—your network uses Telnet for remote management. An attacker on the guest WiFi runs Wireshark and captures a Telnet session. They now have the enable password for your core router. With SSH, that same capture shows encrypted gibberish. Protocol choice isn't a preference—it's a security decision with real consequences.
Consider this real-world situation: You're at home at 2 AM when monitoring alerts fire. The core switch needs attention immediately. Without remote management access, you drive to the data center. With SSH configured, you fix it from your laptop in 10 minutes. But if that SSH is exposed to the internet without proper controls (ACLs, strong passwords, rate limiting), attackers have been trying to brute-force it all day.
The telnet problem: Telnet sends everything in cleartext—including your passwords. Anyone sniffing the network sees your credentials. Yet telnet is still enabled by default on many devices. That's why "disable telnet, enable SSH" is one of the first security steps.
| Method | Port | Encryption | Security | When to Use |
|---|---|---|---|---|
| Console | Physical | None (local) | Highest (physical access required) | Initial setup, password recovery |
| Telnet | TCP 23 | ❌ None | Terrible | Never (legacy only) |
| SSH | TCP 22 | âś… Yes | Good | Daily remote CLI access |
| HTTP | TCP 80 | ❌ None | Terrible | Never (legacy only) |
| HTTPS | TCP 443 | âś… TLS | Good | Web GUI access |
| TACACS+ | TCP 49 | âś… Full packet | Excellent | Centralized device admin |
| RADIUS | UDP 1812/1813 | ⚠️ Password only | Good | Network access control |
Securing SSH—the four prerequisites: SSH won't work until you configure all four of these. Miss one, and SSH silently fails:
- Hostname (can't be "Switch")
- Domain name (for key generation)
- RSA keys (the actual encryption keys)
- Authentication (local user or AAA)
Switch(config)# hostname SW-Access-01 ! Step 1: Hostname
Switch(config)# ip domain-name company.com ! Step 2: Domain
Switch(config)# crypto key generate rsa modulus 2048 ! Step 3: Keys (2048-bit minimum)
Switch(config)# ip ssh version 2 ! Force SSHv2 (v1 is broken)
Switch(config)# username admin privilege 15 secret StrongPassword123 ! Step 4
Switch(config)# line vty 0 15
Switch(config-line)# transport input ssh ! Disable telnet
Switch(config-line)# login local ! Use local usernames
What breaks if you skip a step:
- No hostname → Key generation fails ("Please define a hostname")
- No domain → Key generation fails ("Please define a domain-name")
- No keys → SSH connections refused
- No authentication → Login denied
Verification:
Switch# show ip ssh ! SSH version, timeout, auth retries
Switch# show ssh ! Active SSH sessions
Switch# show users ! All logged-in users (console + VTY)
⚠️ Exam Trap: transport input ssh on VTY lines disables telnet. If you just add SSH without this command, telnet remains enabled and your security improvement is pointless.