在 TCP/IP 协议栈的演进长河中，Telnet 的兴衰是一部关于安全觉醒与技术替代的经典剧本。诞生于 1969 年 ARPANET 的襁褓，作为最早的互联网应用层协议之一，Telnet 曾是实现远程终端登录的基石。1983 年，RFC 854 与 RFC 855 的发布将其正式标准化，确立了其在早期互联网中的核心地位。然而，随着网络环境从可信的学术圈扩展到开放的商业世界，Telnet 与生俱来的安全原罪 —— 完全无加密的明文传输 —— 使其迅速从必备工具沦为高危漏洞。本文将从网络协议演进的技术视角，深入解构 Telnet 消亡的必然性，并聚焦于一个更为棘手的现实：在嵌入式设备与工业控制系统（ICS）中，Telnet 为何 “死而不僵”，以及工程师应如何应对这一遗留挑战。
一、技术性死亡：安全缺陷与 SSH 的全面超越
Telnet 的消亡，首先是一场技术上的彻底溃败。其协议设计根植于一个 “网络即信任” 的过时假设。所有数据，包括最敏感的用户名和密码，都以纯文本形式在 TCP 连接（通常为端口 23）上传输。这意味着任何能够进行网络嗅探的攻击者（例如通过 ARP 欺骗或接入同一广播域）都可以轻而易举地捕获完整会话，实现凭证窃取。更严重的是，Telnet 缺乏任何形式的加密完整性校验（MAC）或服务器身份验证机制。攻击者不仅可以被动窃听，还能发起中间人（MITM）攻击，冒充服务器截获凭证，甚至实时注入或篡改命令与输出，而通信双方无从察觉。
这种设计上的根本缺陷，在协议框架内几乎无法修补。虽然存在通过 TLS 或 SASL 扩展 Telnet 的 RFC 提案，但这些方案极少被实现，且无法解决协议解析器本身可能存在的漏洞（如缓冲区溢出）。近期曝光的 CVE-2026-24061 漏洞便是一个残酷的例证：GNU Inetutils 的 Telnet 守护程序中存在严重缺陷，可导致未经身份验证的远程攻击者获取 root 权限。这暴露了遗留协议代码库普遍缺乏维护、积压大量未修补安全漏洞的严峻现实。
正是为了填补 Telnet 留下的安全真空，SSH（Secure Shell）于 1995 年应运而生。SSH 从设计之初就将安全作为核心：
- 加密通道：通过 Diffie-Hellman 等算法进行密钥交换，随后使用 AES 等对称加密算法对整个会话进行加密，确保传输机密性。
- 强身份验证：采用服务器主机密钥（公钥密码学），客户端可验证服务器身份，有效防御 MITM 攻击。客户端认证支持密码（在加密隧道内）、公钥、证书等多种方式，安全性远超静态口令。
- 完整性保护：每个数据包都附有消息认证码（MAC），任何篡改都会被检测并导致连接中断。
因此，在面向互联网的服务器管理领域，用 SSH 替代 Telnet 已成为毋庸置疑的最佳实践和安全基准。主流操作系统发行版早已默认禁用 Telnet 服务。
二、工程僵尸：嵌入式与工控领域的顽固存留
尽管在通用 IT 世界中已被宣判 “死刑”，Telnet 却在另一个维度展现了惊人的 “生命力”—— 嵌入式系统与工业控制领域。在这里，它并非作为首选协议，而是作为难以根除的 “工程僵尸” 存在。其存留根源复杂且深刻：
- 资源限制与历史惯性：大量路由器、交换机、打印机、PLC（可编程逻辑控制器）等设备设计于十数年前，其 CPU、内存和存储资源极其有限。当时为实现简单、降低成本，Telnet 成为内置管理接口的自然选择。升级到计算密集型的 SSH 协议栈，对这些设备而言可能是不可承受之重，甚至因固件空间不足而无法实现。
- 封闭的供应链与长生命周期：工业设备固件通常由设备制造商闭源提供，更新周期漫长。许多关键设备（如电力、水务系统的控制器）设计运行寿命超过 20 年，且已停产，制造商不再提供安全更新。替换这些 “沉默的资产” 在经济和操作上都不现实。
- 高业务连续性要求与替换成本：工厂、油气、交通等连续生产行业，停机维护窗口极其珍贵，成本高昂。更换涉及核心控制协议的设备，需要经过漫长的计划、测试和验证周期，组织阻力巨大。
- 协议耦合与运维路径依赖：许多设备的管理界面并非标准 shell，而是基于 Telnet 会话构建的定制文本菜单或专用指令集。迁移至 SSH 不仅意味着更换传输层，还可能需重构整个管理应用层。同时，运维人员积累的脚本、工具和操作流程都深度绑定 Telnet，改变需要重新培训和投入。
正如《工业互联网安全架构白皮书》所指出的，工业现场充斥着大量 “不安全控制协议、不安全工业设备、不可靠工控网络”，而更新迭代的速度远远落后于 IT 领域。这使得 Telnet 等明文协议在假设的 “物理隔离” 环境中延续使用，但在当今工业互联网与 IT 网络融合的趋势下，这种假设已日益脆弱。
三、运维现实：可落地的遗留系统维护策略
对于必须与遗留 Telnet 系统共存的工程师而言，理想化的 “全面替换” 往往不切实际。更为可行的是一种基于 “防御纵深” 和 “渐进迁移” 的务实策略。以下提供一套可操作的技术与管理清单：
1. 网络隔离与访问控制（立即执行）
- 严格分区：使用工业防火墙或网闸，将包含 Telnet 设备的操作技术（OT）网络与信息技术（IT）网络进行逻辑或物理隔离。遵循 IEC 62443/ISA-99 标准，建立安全区域和管道。
- 最小化暴露：在防火墙上严格限制访问 Telnet 端口（默认 23）的源 IP 地址范围，仅允许运维堡垒机或特定管理终端访问。
- 跳板机 / 堡垒机：所有远程访问必须通过配置了强认证（如 SSH 密钥 + 多因素认证）的堡垒机进行。外部人员通过 VPN+SSH 连接堡垒机，再从堡垒机通过 Telnet 访问目标设备。这将明文 Telnet 流量限制在最内部的受控网段。
2. 系统加固与监控（持续进行）
- 凭证管理：强制更改所有默认密码，实施强密码策略（长度、复杂度、定期更换）。理想情况下，在堡垒机层面进行统一身份管理，设备本地仅保留最低权限的应急账号。
- 服务精简：关闭设备上所有非必需的 Telnet 实例或其他未加密服务。
- 网络监控与审计：部署工业入侵检测系统（IDS）或利用网络流量分析（NTA）工具，监控 Telnet 端口的异常登录行为（如非常用 IP、频繁失败登录）、异常命令序列（如下载固件、修改配置）。所有通过堡垒机的会话必须录制完整日志以供审计。
3. 渐进式替换与生命周期管理（中长期规划）
- 新购设备强制要求：在采购新设备或进行系统升级时，将 “支持 SSHv2 或更现代的安全管理协议” 作为强制性技术条款写入合同。
- 风险评估与优先级排序：对存量设备进行资产清点和风险评估。优先替换那些暴露程度高（如可通过互联网间接访问）、承载关键功能、且存在已知严重漏洞的设备。
- 利用维护窗口：将协议升级与设备定期大修、系统改造项目相结合，在计划停机窗口内分批实施替换或升级。对于无法升级固件的设备，可考虑在前端部署 “协议转换网关”（一种专用设备或软件），对外提供 SSH 接口，内部转换为 Telnet 协议与设备通信。
结论
Telnet 协议的消亡，是网络安全需求驱动技术迭代的必然结果。其设计缺陷在 SSH 面前显得不堪一击，这奠定了其在通用计算领域被淘汰的命运。然而，技术的演进并非在所有领域同步发生。在嵌入式与工业控制这片由硬件限制、经济成本和路径依赖构成的 “冻土” 中，Telnet 作为一种遗留协议，仍将在未来相当长的时间内继续存在。对于工程师而言，真正的挑战不在于怀旧或简单地谴责，而在于如何在接受这一现实的基础上，构建起一套务实、多层次的安全防护与迁移体系。这要求我们不仅精通现代加密协议，也深刻理解遗留系统的约束，并在安全、成本与业务连续性之间做出精妙的权衡。最终，管理 Telnet 遗产的过程，本身就是一部关于工程现实主义的生动教材。
资料来源参考
- 关于 Telnet 安全缺陷与 SSH 对比的权威技术分析（基于 Serverspace.io, Wikipedia, Lightyear.ai 等资料）
- 工业互联网产业联盟发布的《工业互联网安全架构白皮书》中关于遗留不安全协议的分析