How to Set Up Telnet on a Cisco Router: Remote Access Configuration and Security

Telnet is one of those protocols that almost every networking student learns first, even though most production networks have moved away from it in favor of SSH. Still, understanding Telnet is important — for legacy equipment, for lab environments, and honestly, for really understanding why SSH became the standard. In this guide, I will walk through configuring Telnet on a Cisco router from scratch, explain how it works under the hood, and then spend real time on why and how to secure it (or replace it) properly.

What Is Telnet?

Telnet is an application-layer protocol that provides a text-based, interactive command-line session to a remote device over TCP port 23. It was one of the earliest remote access protocols on the internet, dating back to the early ARPANET days. On Cisco devices, Telnet allows you to remotely log in to the router’s VTY (Virtual Teletype) lines and issue commands exactly as if you were connected via the console port.

The critical thing to understand about Telnet is that it transmits everything — including usernames and passwords — in plain text. There is no encryption whatsoever. This is the single biggest reason Telnet has been phased out in favor of SSH in virtually all modern production environments.

How Telnet Works: Protocol Operation

Telnet operates over a simple client-server TCP connection:

1. Client initiates a TCP three-way handshake to the router on port 23.
2. Once the TCP session is established, the router presents a login prompt (or password prompt, depending on configuration).
3. Credentials are sent in cleartext over the TCP session.
4. Once authenticated, the client receives an interactive CLI session identical to a console connection.
5. All subsequent commands and output are transmitted unencrypted for the duration of the session.

Because there is no encryption, anyone capturing packets between the client and the router (using a tool like Wireshark) can read the entire session, including the password, character by character in some capture scenarios.

Lab Topology

[Admin PC 10.0.0.5] --- [Switch] --- G0/0 [Router R1]

We will enable Telnet access to R1 from the admin subnet.

Basic Telnet Configuration

First, configure a hostname and basic IP addressing (assuming this is already done), then move to the VTY lines.

Router> enable
Router# configure terminal
Router(config)# hostname R1
R1(config)# enable secret C1sc0Str0ngP@ss
R1(config)# line vty 0 4
R1(config-line)# password Telnet@ccess1
R1(config-line)# login
R1(config-line)# transport input telnet
R1(config-line)# exec-timeout 5 0
R1(config-line)# exit

Let’s break this down:

• line vty 0 4 selects the first five virtual terminal lines (0 through 4), which handle simultaneous remote sessions.
• password sets the password required to access the VTY line.
• login tells the router to prompt for that password.
• transport input telnet restricts remote access on these lines specifically to Telnet.
• exec-timeout 5 0 disconnects idle sessions after 5 minutes.

Using Local Usernames Instead of a Shared Line Password

A more accountable approach, even with Telnet, is to use individual usernames:

R1(config)# username admin privilege 15 secret AdminStr0ngP@ss
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input telnet
R1(config-line)# exit

This way, each administrator has a distinct login and the router logs who connected, rather than everyone sharing one password.

Verification

R1# show running-config | section line vty
line vty 0 4
 login local
 transport input telnet
 exec-timeout 5 0

R1# show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:00:00
*  2 vty 0     admin      idle                 00:00:12   10.0.0.5

R1# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     10.0.0.1        YES manual up                    up

From the admin PC, testing the connection:

C:\> telnet 10.0.0.1
Trying 10.0.0.1... Open

User Access Verification
Username: admin
Password:
R1>

Real-World Enterprise Scenario

In practice, Telnet is rarely deployed intentionally on modern production routers, but it does show up in two common real-world situations. First, legacy industrial or lab equipment that only supports Telnet, isolated on an out-of-band management VLAN with no internet reachability. Second, brand-new equipment fresh out of the box, before the initial security hardening pass replaces Telnet with SSH. A responsible enterprise workflow treats Telnet strictly as a transitional or isolated-network protocol, never as a long-term remote access method for anything internet-facing or business-critical.

Security Considerations

This is the most important section of this article, honestly. Telnet has fundamental, unfixable security weaknesses:

• No encryption – credentials and session data are sent in plain text and can be captured with any packet sniffer on the path.
• No integrity protection – a man-in-the-middle attacker can potentially alter session data undetected.
• No strong authentication mechanisms – Telnet on IOS supports only simple password or local username/password authentication, without the key-based options SSH offers.

If you must use Telnet (for legacy compatibility), mitigate the risk with these steps:

Restrict Telnet access with an ACL:

R1(config)# access-list 10 permit 10.0.0.5
R1(config)# access-list 10 deny any log
R1(config)# line vty 0 4
R1(config-line)# access-class 10 in

Isolate Telnet to an out-of-band management network that has no route to the internet or to production data VLANs.

Set aggressive exec-timeout values to reduce the window an unattended session stays open.

Log all access attempts:

R1(config)# login on-failure log
R1(config)# login on-success log

Best Practices

• Prefer SSH over Telnet for any device reachable from an untrusted or semi-trusted network.
• If Telnet must be used, restrict it with an access-class ACL bound to specific management hosts only.
• Use login local with individual usernames rather than a single shared VTY password, for accountability.
• Set exec-timeout on every VTY line, not just the ones actively in use, since attackers can target any of the five default lines.
• Disable unused VTY lines entirely if they are not needed:

R1(config)# line vty 5 15
R1(config-line)# transport input none

Performance Tuning

Telnet itself is a lightweight protocol with negligible CPU or bandwidth overhead compared to SSH’s encryption processing, which is actually one of the very few practical advantages it holds on extremely low-powered legacy hardware. That said, on any modern router, the performance difference between Telnet and SSH is negligible, and it is never worth trading security for this minor efficiency gain.

• Keep the number of concurrent VTY sessions reasonable (line vty 0 15 for larger environments) to avoid exhausting available lines during troubleshooting periods when multiple engineers need access simultaneously.
• Use show processes cpu to confirm that VTY access is not contributing meaningfully to router load; in virtually all cases it will not be.

Troubleshooting and Common Configuration Mistakes

Mistake 1: Forgetting the login command If you set a VTY password but forget login, the router will not actually prompt for that password, leading to either open or completely blocked access, depending on the IOS version.

Mistake 2: No password configured at all If login is set without a password (and no login local configuration), you will see the error: % Login disabled on line, until 'password' is set.

Mistake 3: Transport input mismatch If transport input ssh is set instead of transport input telnet (or transport input all), Telnet connections will be refused even though the rest of the configuration looks correct.

Mistake 4: ACL blocking legitimate admins An overly restrictive access-class can lock out valid administrators; always keep a console-based fallback and verify the ACL from a test host before finalizing.

Useful troubleshooting commands:

R1# show line vty 0 4
R1# show access-lists 10
R1# debug telnet
R1# show tcp brief

Frequently Asked Questions

Q: Is Telnet still used in modern enterprise networks? Rarely, and typically only for isolated legacy equipment; most organizations have fully migrated to SSH for remote CLI access.

Q: What port does Telnet use? Telnet operates over TCP port 23 by default.

Q: Can Telnet and SSH be enabled at the same time? Yes, using transport input telnet ssh on the VTY lines, though this is not recommended for production devices since it still allows the insecure Telnet path.

Q: Why does my Telnet session disconnect after a few minutes? This is controlled by the exec-timeout setting on the VTY line, which disconnects idle sessions after the configured period, and is a deliberate security best practice.

Q: Is Telnet completely unencrypted, or just the password? The entire session — commands, output, and credentials — is transmitted without encryption from start to finish.

Summary and Key Takeaways

Telnet remains a foundational protocol to understand conceptually, even though it should almost never be used on modern production networks due to its complete lack of encryption. If you configure it, do so only for isolated legacy environments, always pair it with an access-class ACL restricting source hosts, use local usernames for accountability, and set aggressive timeout values. In nearly every real-world scenario, SSH should be your default choice for remote router access — a topic I cover in depth in the companion article on configuring SSH on Cisco routers.

References

• Cisco IOS Terminal Services Configuration Guide: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/termserv/configuration/xe-16/tsv-xe-16-book.html
• Cisco Password Recovery and Security Configuration: https://www.cisco.com/c/en/us/support/docs/security-vpn/configuring-passwords-privileges/13814-3.html