replace Telnet with SSH on a Cisco router in six lines

the six lines that stop your router from broadcasting its password

telnet is one of those protocols that just refuses to die. it's old, it's simple, and it's everywhere in lab environments, home labs, and unfortunately still some production networks. the problem is telnet sends everything in plaintext. your username, your password, every command you type to configure that router. anyone sniffing traffic on the same network segment can read it like a text message. ssh fixes this by encrypting the whole session. and switching from one to the other is six lines of config. that's it.

why telnet is a gift to anyone watching your network

when you telnet into a router, the packets carrying your login credentials go across the wire completely unencrypted. if someone has a packet capture running anywhere between you and that router, they don't need to guess your password, they just read it off the screen. this is why telnet shows up on every "things auditors flag immediately" list. it's not theoretical risk, it's a plaintext credential handoff happening in real time.

ssh solves this by encrypting the session with keys instead of sending raw text. same login experience for you, completely different story for anyone trying to intercept it.

breaking down the config

here's the full block again, then we'll go line by line.

hostname R1
ip domain-name lab.local
crypto key generate rsa modulus 2048
username admin secret <StrongPass>
line vty 0 4
 transport input ssh
 login local

hostname R1 sets the device name. ssh needs this because the hostname and domain name together form part of what the router uses to generate its rsa key. skip this step and the key generation command won't even work.

ip domain-name lab.local gives the router a domain name for the same reason. these two lines exist purely to feed the crypto key command below.

crypto key generate rsa modulus 2048 is where the actual encryption keys get created. modulus 2048 means a 2048 bit key, which is the current baseline for something you'd actually trust. anything smaller and you're basically using a lock that's easy to pick. this command is also what quietly enables ssh on the device, ios won't let you turn on ssh without a key pair to encrypt the session.

username admin secret <StrongPass> creates a local login account. use "secret" not "password" here, secret hashes the credential in the config, password stores it in a reversible format that's barely better than plaintext if someone gets a copy of your config file.

line vty 0 4 moves you into the configuration for the virtual terminal lines, which is the config that controls remote access. 0 4 covers five simultaneous remote sessions, which is the default range on most cisco gear.

transport input ssh is the line that actually matters. this tells the router which protocols are allowed on those vty lines. setting it to ssh only means telnet is refused outright, not just deprioritized. if someone tries to telnet in after this, the router won't even accept the connection.

login local tells the router to check logins against the local username database you just created, instead of an open line with no authentication or an old shared password. no local login config here and your vty lines might still be wide open depending on prior settings.

protecting your own gear

if you're running cisco equipment at home, in a lab, or managing anything for other people, check your running config right now:

show running-config | include transport input

if that comes back with "transport input telnet" or "transport input all" anywhere, you've got plaintext management access sitting open. fix it with the six lines above. while you're in there, also check for any leftover telnet-only access on the console or aux lines, and make sure you're not still allowing password-only logins with no local user database backing them.

one more thing worth doing, restrict which ip addresses can even attempt to connect to those vty lines using an access-list. ssh encrypts the session, but it doesn't stop someone from hammering the login prompt if it's reachable from anywhere. lock it down to your management subnet.

the takeaway

telnet isn't dangerous because it's old, it's dangerous because it hands your credentials to anyone listening. ssh costs you six lines of config and a couple minutes, and in exchange your management traffic is actually encrypted instead of readable. if you manage any cisco gear right now, go check those vty lines. this is a five minute fix that closes a door that should've been closed years ago.