VMware ESXi and vSphere Cluster Management
Telnet Protocol: Remote CLI Access and Security Considerations
Learn how Telnet provides remote CLI access, how TCP port 23 connections work, and why SSH is preferred for secure network administration.
Telnet is an application-layer protocol for communicating with a remote device. It commonly provides remote command-line interface (CLI) access, allowing an administrator to work with a host, router, switch, or other system from another machine.
Telnet was historically used to administer network devices and remote hosts. Today, it is mainly important for understanding legacy systems and remote-access security because its session data is sent in clear text.
What Telnet Provides
A Telnet session creates a virtual terminal. A virtual terminal is an interactive command-line session that lets a user enter commands as though the user were working directly at the remote device.
Commands entered through the session execute on the remote device, subject to the permissions and authorization associated with the authenticated account. The local computer supplies the interface, but the remote system performs the command processing.
The Telnet Client-Server Model
Telnet uses a client-server model:
- Telnet client: Software running on the administrator's workstation or local host. It initiates the connection.
- Telnet server: A service running on the remote device. It listens for and accepts incoming Telnet sessions.
- Remote device: The host, router, switch, or other system being accessed from another machine.
- Virtual terminal session: The interactive CLI presented by the client after the remote service accepts the connection.
A successful session requires both network reachability to the remote device and an enabled, running Telnet server on that device. A Telnet client alone cannot provide access if the destination is unreachable or the remote service is disabled.
| Component | Location | Role in the Connection |
|---|---|---|
| Telnet client | Administrator workstation or Host A | Initiates the remote Telnet connection and displays the session |
| Telnet server | Remote router or host such as R1 | Accepts incoming Telnet connections |
| TCP port 23 | Remote device | Well-known destination port used by the Telnet server |
| Virtual terminal session | Displayed on the local client | Provides the interactive CLI through which commands are sent to the remote device |
How a Telnet Session Is Established
- The administrator starts a Telnet client on the local host.
- The administrator specifies the destination by an IP address or hostname. An IP address identifies the destination on the network; a hostname is a name that can be resolved to an IP address.
- The client attempts to create a TCP connection to the remote device's Telnet service.
- If the device is reachable and the Telnet server is accepting connections, the remote device presents a login prompt or another access prompt.
- The administrator supplies credentials. After successful authentication and authorization, the client presents the remote device's interactive CLI.
- Commands entered in that CLI are processed by the remote device, not by the administrator's workstation.
Transport Protocol and Port
Telnet uses TCP, a transport-layer protocol that provides a connection-oriented byte stream. Telnet's well-known server port is TCP port 23.
The destination port matters when configuring or examining network controls. Firewalls, access-control policies, and filtering devices can allow or block Telnet traffic by checking TCP port 23. During diagnosis, seeing that port blocked can explain why a client cannot reach the Telnet service.
Example: Host A Connects to Router R1
Assume the following setup:
- Host A is the local administrator workstation.
- Host A has a Telnet client.
- Router R1 is reachable at
10.0.0.1. - R1 has an enabled and running Telnet server.
The administrator can initiate the connection with:
telnet 10.0.0.1This command tells the local Telnet client to connect to the device at IP address 10.0.0.1. The client uses TCP and targets the Telnet service on port 23 unless another port is explicitly specified by the client software.
A destination can also be written using a hostname:
telnet <IP-address-or-hostname>After the connection reaches R1, the administrator receives a login prompt. If authentication succeeds and the account is authorized for remote CLI access, the administrator can manage R1 from Host A.
Telnet's Security Limitations
Telnet transmits session data in clear text. Clear text means data is sent without encryption and may be readable to a party that can observe the traffic.
Potentially exposed information includes:
- Usernames
- Passwords
- Commands entered during the session
- Output returned by the remote device
This creates unacceptable risk on untrusted or production networks. An observer with an appropriate position on the network may capture credentials and reuse them, or learn sensitive configuration and operational information from the commands and responses.
Why SSH Is Preferred
SSH, or Secure Shell, is the modern replacement for Telnet remote administration. SSH provides a protected remote-management connection, whereas Telnet sends the session without encryption.
When a modern device supports both protocols, use SSH. SSH helps protect administrative credentials, commands, and returned session data from network observers. Telnet should generally be limited to exceptional cases, such as legacy equipment that supports Telnet but does not support SSH. Even then, access should be constrained and treated as exposed communication.
| Feature | Telnet | SSH |
|---|---|---|
| Primary purpose | Remote terminal and CLI access | Protected remote terminal and CLI access |
| Transport protocol | TCP | TCP |
| Default or well-known port | TCP port 23 | TCP port 22 |
| Encryption protection | None; session data is clear text | Provides a protected connection for remote administration |
| Credential exposure risk | High because usernames and passwords may be observed | Much lower because the administrative session is protected |
| Recommended administrative use | Only when a secure alternative is unavailable and risk is controlled | Normal choice for remote administration |
| Typical modern status | Legacy and generally avoided | Preferred modern remote-access protocol |
Troubleshooting Telnet Connections
The Client Cannot Establish a Connection
- Confirm that the target IP address or hostname is correct.
- Verify basic network reachability between the client and the remote device.
- Verify that the remote Telnet server is enabled and running.
- Check whether TCP port 23 is blocked by a firewall, access-control policy, or filtering device.
The Connection Reaches the Device but Login Fails
- Verify that valid remote-access credentials are being used.
- Confirm that the account and access method are permitted to use the remote CLI.
- Verify that the intended device was reached rather than a different host caused by an incorrect address or name-resolution result.
Telnet Works but Is Rejected for Production Administration
- Recognize that Telnet exposes credentials and session data in clear text.
- Determine whether SSH is available on the device.
- Migrate routine administrative access to SSH.
- Reserve Telnet for constrained legacy scenarios instead of normal management.
Exam-Relevant Summary
- Telnet is an application-layer protocol for remote terminal and CLI access.
- The Telnet client runs on the administrator's local host; the Telnet server runs on the remote device.
- Telnet uses TCP port 23.
- A reachable destination and an active Telnet server are both required.
- The remote device executes commands entered through the virtual terminal session.
- Telnet sends usernames, passwords, commands, and other session data in clear text.
- SSH is the preferred protocol for normal remote administration.
- Telnet is mainly a legacy compatibility option when SSH is unavailable.
For the secure alternative, continue with remote command-line access concepts and compare the protocol behavior before choosing an administrative method.