How To Disable Telnet and Enable SSH on Cisco Router And Switches?

Despite being insecure by design, Telnet is still enabled by default on many Cisco devices, particularly older switches, routers, and lab-built configurations that later find their way into production.

From a security perspective, Telnet is a liability.
From an auditor’s perspective, it’s a red flag.
From an attacker’s perspective, it’s an invitation.

In modern enterprise networks, there is no valid reason to allow Telnet for remote management. SSH has been available in Cisco IOS for decades and provides strong encryption, authentication, and integrity protection.

In this article, we’ll walk through:

• The real difference between Telnet and SSH
• Why disabling Telnet is critical
• How VTY lines actually work under the hood
• Step-by-step SSH configuration on Cisco routers and switches
• Real-world hardening tips that most guides ignore

This is written from the perspective of someone who has secured production Cisco environments, not just lab devices.

Telnet vs SSH: What’s the Real Difference?

At a functional level, Telnet and SSH both allow remote CLI access to Cisco devices. The difference is how they protect (or don’t protect) that access.

Telnet (Teletype Network)

• Sends usernames and passwords in clear text
• No encryption
• No session integrity
• Vulnerable to packet sniffing, MITM attacks, and credential replay
• Fails every modern security audit (ISO 27001, SOC 2, Essential Eight, CIS)

If someone can capture packets between your workstation and the device, they own your credentials.

SSH (Secure Shell)

• Encrypts all traffic end-to-end
• Protects credentials and session data
• Supports strong cryptography (RSA/ECDSA keys)
• Integrates with local users, TACACS+, and RADIUS
• Industry-standard for secure remote access

SSH doesn’t just protect passwords—it protects everything you type and see.

Understanding VTY Lines (Why Telnet and SSH Live There)

Every remote CLI connection to a Cisco device uses a VTY (Virtual Terminal) line.

• Older IOS versions (pre-12.2): VTY 0–4
• Newer IOS versions (12.2+): VTY 0–15

If Telnet is allowed on any VTY line, it is effectively enabled on the device.

That’s why partial configuration is a common mistake—and why audits still find Telnet open “even though SSH was configured”.

Step 1: Disable Telnet on Cisco Routers and Switches

The safest approach is to explicitly allow only SSH on all VTY lines.

Disable Telnet (and All Other Remote Access Except SSH)

CiscoDevice(config)# line vty 0 15
CiscoDevice(config-line)# transport input ssh

What This Does

• Disables Telnet
• Disables rlogin and other legacy protocols
• Allows only SSH for remote access
• Applies to all 16 VTY lines

💡 Real-world tip:
Always configure all VTY lines, even if you think only a few are used. Attackers don’t respect assumptions.

Step 2: Enable SSH on Cisco IOS Devices

SSH doesn’t work by default—you must explicitly configure it.

Prerequisites for SSH

Before SSH can be enabled, the device must have:

1. A hostname
2. A domain name
3. RSA key pair
4. Local or AAA authentication

Full Example: Enabling SSH Securely

R1> enable
R1# configure terminal

Set a Domain Name (Required for RSA Keys)

R1(config)# ip domain-name supertechman.com.au

Generate RSA Keys

R1(config)# crypto key generate rsa

When prompted:

How many bits in the modulus [512]: 1024

💡 Best practice:
Use 2048-bit keys in production if supported by your IOS version.

Create a Local Admin User

R1(config)# username Admin privilege 15 secret SuperTechman

✔ Uses secret (hashed) instead of password (clear text)
✔ Assigns full admin privileges

Configure VTY Lines for SSH and Local Authentication

R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exit

Enforce SSH Version 2

R1(config)# ip ssh version 2

SSH version 1 is obsolete and insecure—always disable it.

Harden SSH Authentication Settings

R1(config)# ip ssh authentication-retries 3
R1(config)# ip ssh time-out 120

This reduces:

• Brute-force attempts
• Idle session abuse

Optional but Strongly Recommended Hardening

These steps aren’t always included in basic guides—but they matter in production.

Encrypt All Passwords in Configuration

R1(config)# service password-encryption

This protects passwords from casual inspection (not strong encryption, but better than plain text).

Restrict SSH Access by IP (Highly Recommended)

R1(config)# access-list 10 permit 192.168.1.0 0.0.0.255
R1(config)# line vty 0 15
R1(config-line)# access-class 10 in

Only trusted management networks can access the device.

Disable Unused Services

R1(config)# no ip http server
R1(config)# no ip http secure-server

Reduces attack surface.

Verifying SSH Configuration

From another device:

ssh Admin@<router-ip>

On the Cisco device:

show ip ssh
show run | section vty

You should see:

• SSH version 2 enabled
• Telnet not listed
• VTY lines restricted to SSH only

Real-World Lessons from the Field

• Many breaches start with clear-text management access
• Telnet is often left enabled “temporarily” and forgotten
• SSH misconfiguration is one of the top audit failures
• Partial VTY configuration is worse than none

In regulated environments, disabling Telnet is not just best practice—it’s mandatory.

Final Thoughts: Secure Access Is Non-Negotiable

Disabling Telnet and enabling SSH is one of the simplest and highest-impact security improvements you can make on a Cisco network.

It:

• Protects credentials
• Prevents session hijacking
• Improves audit outcomes
• Aligns with modern security frameworks

If Telnet is still enabled on any production device, the network is not secure—full stop.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.