Telnet port guide: legacy remote access on port 23

Telnet opens a TCP connection and presents a text-based terminal session. After the server accepts the connection, the client and server can negotiate terminal options, then the user sends commands and receives output as plain text.

That simplicity is why Telnet survived in device management, labs, manufacturing equipment, and old appliances. It is also why it is risky: without a separate encrypted tunnel, anyone who can capture traffic between the client and server may read credentials and commands.

SSH replaced Telnet for most remote administration because SSH encrypts the session, verifies the server host key, and supports stronger authentication. SSH normally uses TCP port 22, while Telnet normally uses TCP port 23.

If the device supports SSH, use SSH instead of Telnet. Keep Telnet only for systems that cannot be upgraded, for isolated lab access, or for short emergency workflows where compensating controls are already in place.

Telnet still appears on older routers and switches, PBX systems, out-of-band console servers, building controls, industrial controllers, storage arrays, printers, and vendor appliances that were designed before SSH became standard.

It is also used as a simple diagnostic client for raw TCP services, although modern tools such as nc, ncat, curl, openssl s_client, and purpose-built protocol clients usually provide better visibility and fewer surprises.

Port 23 should almost never be open to the public internet. Public Telnet attracts automated scanning, default-password attacks, botnet activity, and opportunistic device takeover. If a Telnet service is reachable from outside a trusted network, treat it as an urgent exposure to review.

If Telnet is unavoidable, restrict it to a management VLAN, VPN, bastion host, jump box, serial-console network, or source-IP allowlist. The goal is to make Telnet reachable only by the people and automation that truly need it.

Before allowing TCP 23, confirm why Telnet is still required and whether SSH, HTTPS management, a vendor API, or a serial console can replace it. Then identify who should connect, from which network, for how long, and what logging is available.

A port checker can tell you whether TCP 23 is reachable from outside, but it cannot tell you whether credentials are safe or whether the device supports modern access controls. Test the actual login path only from a trusted network and avoid sending real passwords over untrusted links.

On Windows, Telnet Client can be enabled for testing, but Telnet Server should not be used for normal administration. If a Windows system needs remote command access, use PowerShell Remoting, SSH, RDP through a gateway, or another encrypted management path.

On Linux, Telnet server packages are usually unnecessary and should stay disabled. If a legacy daemon must run, bind it to a private interface and restrict access with firewalld, ufw, nftables, iptables, or a host-based allowlist.

On network devices and appliances, disable Telnet when SSH or HTTPS management is available. If vendor limitations force Telnet, place the device on a restricted management network and document the exception so it can be removed during the next refresh cycle.

Start with an external port check against the hostname or IP address and port 23. If the result is open, a remote client can establish a TCP connection to the Telnet listener. That does not mean it is safe to log in from the public internet.

From a trusted network, you can test the banner with telnet host 23, nc -vz host 23, or ncat. On the server or device, inspect service status and firewall rules. For appliances, check the management settings because Telnet may be enabled separately from SSH or web administration.

If port 23 is closed, Telnet may be disabled, the device may support SSH only, the service may be bound to a management interface, or a firewall may be blocking the path. If it times out, a router, ACL, VPN policy, cloud firewall, or source-IP restriction may be dropping the traffic.

If the port is open but login fails, inspect username format, password state, device access class rules, local vs directory authentication, line configuration, and lockout settings. On network equipment, VTY line policy or management-plane ACLs often explain the failure.

Disable Telnet wherever possible. Replace it with SSH, HTTPS management, VPN-only access, serial console, or vendor tooling. Remove default accounts, rotate shared passwords, and keep device firmware current until the Telnet dependency is gone.

If Telnet must remain, isolate it from user networks and the internet, log access attempts, monitor unexpected source addresses, and document ownership. Treat every Telnet exception as temporary operational debt, not a normal management pattern.