Telnet 端口指南：端口 23 上的传统远程访问

Telnet 打开 TCP 连接并呈现基于文本的终端会话。服务器接受连接后，客户端和服务器可以协商终端选项，然后用户发送命令并接收纯文本输出。

这种简单性正是 Telnet 在设备管理、实验室、制造设备和旧设备中得以生存的原因。这也是它存在风险的原因：如果没有单独的加密隧道，任何能够捕获客户端和服务器之间流量的人都可以读取凭据和命令。

SSH 在大多数远程管理中取代了 Telnet，因为 SSH 可以加密会话、验证服务器主机密钥并支持更强的身份验证。 SSH 通常使用 TCP 端口 22，而 Telnet 通常使用 TCP 端口 23。

如果设备支持 SSH，请使用 SSH 而不是 Telnet。仅对无法升级的系统、隔离实验室访问或补偿控制已就位的短期紧急工作流程保留 Telnet。

Telnet 仍然出现在 SSH 成为标准之前设计的老式路由器和交换机、PBX 系统、带外控制台服务器、楼宇控制、工业控制器、存储阵列、打印机和供应商设备上。

它也用作原始 TCP 服务的简单诊断客户端，尽管 nc、ncat、curl、openssl s_client 和专用协议客户端等现代工具通常提供更好的可见性和更少的意外。

端口 23 几乎不应该向公共互联网开放。公共 Telnet 会吸引自动扫描、默认密码攻击、僵尸网络活动和机会性设备接管。如果可以从可信网络外部访问 Telnet 服务，请将其视为需要审查的紧急风险。

如果 Telnet 不可避免，请将其限制为管理 VLAN、VPN、堡垒主机、跳线盒、串行控制台网络或源 IP 允许列表。目标是让 Telnet 只能由真正需要它的人员和自动化设备访问。

在允许 TCP 23 之前，请确认为什么仍然需要 Telnet，以及 SSH、HTTPS 管理、供应商 API 或串行控制台是否可以替代它。然后确定谁应该连接、从哪个网络进行连接、连接时长以及可用的日志记录。

端口检查器可以告诉您 TCP 23 是否可以从外部访问，但它无法告诉您凭据是否安全或设备是否支持现代访问控制。仅从受信任的网络测试实际登录路径，并避免通过不受信任的链接发送真实密码。

在 Windows 上，可以启用 Telnet 客户端进行测试，但 Telnet 服务器不应用于正常管理。如果 Windows 系统需要远程命令访问，请通过网关或其他加密管理路径使用 PowerShell 远程处理、SSH、RDP。

在 Linux 上，Telnet 服务器软件包通常是不必要的，应保持禁用状态。如果必须运行旧守护程序，请将其绑定到专用接口并使用firewalld、ufw、nftables、iptables 或基于主机的白名单限制访问。

在网络设备和装置上，当 SSH 或 HTTPS 管理可用时禁用 Telnet。如果供应商限制强制使用 Telnet，请将设备置于受限管理网络上并记录异常情况，以便可以在下一个刷新周期中将其删除。

首先根据主机名或 IP 地址和端口 23 进行外部端口检查。如果结果打开，则远程客户端可以与 Telnet 侦听器建立 TCP 连接。这并不意味着从公共互联网登录是安全的。

从受信任的网络，您可以使用 telnet 主机 23、nc -vz 主机 23 或 ncat 测试横幅。在服务器或设备上检查服务状态和防火墙规则。对于设备，请检查管理设置，因为 Telnet 可能与 SSH 或 Web 管理分开启用。

如果端口 23 关闭，Telnet 可能被禁用，设备可能仅支持 SSH，服务可能绑定到管理接口，或者防火墙可能阻止路径。如果超时，路由器、ACL、VPN 策略、云防火墙或源 IP 限制可能会丢弃流量。

如果端口打开但登录失败，请检查用户名格式、密码状态、设备访问类别规则、本地与目录身份验证、线路配置和锁定设置。在网络设备上，VTY线路策略或管理平面ACL通常可以解释故障。

尽可能禁用 Telnet。将其替换为 SSH、HTTPS 管理、仅 VPN 访问、串行控制台或供应商工具。删除默认帐户、轮换共享密码并保持设备固件最新，直到 Telnet 依赖性消失。

如果必须保留 Telnet，请将其与用户网络和互联网隔离，记录访问尝试，监视意外的源地址和文档所有权。将每个 Telnet 异常视为临时运营债务，而不是正常的管理模式。