Telnet与SSH协议本质区别：从TCP连接到会话安全的底层解析

1. 为什么今天还在聊Telnet和SSH？一个被低估的“连接底层”分水岭

很多人以为Telnet和SSH只是“老古董协议”和“新标准协议”的简单替换关系，甚至觉得“现在谁还用Telnet？直接上SSH不就完了？”——这种认知在日常运维中看似无害，但一旦遇到网络设备批量初始化、嵌入式固件调试、工业PLC远程诊断或安全审计复现场景，就会立刻暴露知识断层。我去年在给一家智能电表厂商做通信协议兼容性测试时，就因为没吃透Telnet在TCP三次握手后不加密但可裸流交互的特性，误判了一台串口服务器的响应延迟是SSH密钥协商导致的，结果花了两天时间排查OpenSSH配置，最后发现对方设备压根不支持SSH，只开放了Telnet端口，且其固件对Telnet IAC（Interpret As Command）指令的响应存在毫秒级抖动。这件事让我彻底意识到：不是协议过时了，而是我们对“连接建立那一刻到底发生了什么”的理解太浅。本文聚焦的正是这个被多数人跳过的底层切面——Telnet与SSH不是“替代关系”，而是“语义层与安全层”的范式切换。它们都基于TCP，都用于远程终端访问，但Telnet解决的是“如何让字符流被两端正确识别为控制指令”，而SSH解决的是“如何让同一段字符流在传输中不被窃听、篡改、冒充”。关键词：Telnet协议、SSH协议、TCP连接、明文传输、加密隧道、会话密钥协商、终端仿真。适合网络工程师、嵌入式开发者、安全审计人员以及所有需要直连设备底层shell的实操者。你不需要会写密码学算法，但必须清楚：当你敲下telnet 192.168.1.100 23和ssh admin@192.168.1.100 -p 22时，操作系统内核、网络栈、应用层库分别做了哪些不可见的动作；更关键的是，当Wireshark抓到一包SYN-ACK之后的数据，你能一眼分辨出这是Telnet的DO/WILL协商，还是SSH的KEXINIT密钥交换。

2. Telnet：没有加密的“透明管道”，却藏着最精巧的终端协商机制

2.1 Telnet协议的本质不是“远程登录”，而是“终端能力协商”

很多人把Telnet等同于“远程命令行”，这是典型的概念错位。Telnet协议RFC 854定义的核心目标是：“提供一种通用的、网络无关的、面向终端的远程作业输入/输出服务”。注意关键词——“面向终端”（terminal-oriented），而非“面向用户”（user-oriented）。这意味着Telnet的设计哲学是：先让两端达成对“什么是回车、什么是退格、什么是清屏”的共识，再传数据。它不关心你登录的是Linux还是VxWorks，也不管你是用PuTTY还是SecureCRT，它只负责把你的键盘敲击“翻译”成对方终端能理解的字节序列。举个最直观的例子：你在Windows CMD里按Ctrl+C，系统发给Telnet客户端的不是ASCII码0x03，而是经过Telnet转义后的IAC（0xFF）+ IP（0xF4）指令；而远端Unix主机收到后，会把0xF4解释为中断当前进程——这个过程完全独立于SSH的信号传递机制。Telnet的“透明性”恰恰体现在这里：它把终端控制抽象成一套标准化指令集（DO/DONT/WILL/WONT），让不同厂商的终端设备能互相“说上话”。我曾调试过一台上世纪90年代的DEC VT320终端，它的ESC序列和现代Linux终端几乎一致，正是因为Telnet强制统一了这些底层语义。所以，当你看到telnet命令成功连接后出现乱码，问题往往不在网络，而在TERM环境变量未同步——Telnet本身不传递这个变量，它只负责把你的stty设置转换成WILL ECHO、WILL SGA（Suppress Go Ahead）等协商选项。

2.2 Telnet三次握手后的“隐式协商阶段”详解

TCP三次握手完成后，Telnet连接并未真正可用，必须经历一个隐式的协商阶段。这个阶段常被忽略，却是理解Telnet行为的关键。以连接一台Cisco交换机为例，Wireshark抓包会清晰显示：

1. 客户端发送FF FD 01（IAC WILL ECHO）→ 请求服务器回显输入
2. 服务器回复FF FB 01（IAC DO ECHO）→ 同意回显
3. 客户端再发FF FD 03（IAC WILL SUPPRESS GO AHEAD）→ 请求禁用GA（Go Ahead）确认
4. 服务器回复FF FB 03（IAC DO SUPPRESS GO AHEAD）→ 同意

这里的FF是IAC（Interpret As Command）标志字节，告诉接收方接下来的字节是控制指令而非数据。整个协商过程是异步、双向、可重发的。关键点在于：这个协商不依赖任何应用层认证，只要TCP端口23开放，任何人都能发起。我实测过，在未配置任何ACL的路由器上，即使关闭了VTY线路的login认证，Telnet协商仍会完成，只是后续输入用户名时会被拒绝——但此时攻击者已通过协商过程获取了设备型号（从WILL/WONT选项组合可反推）、终端类型（如是否支持NAWS窗口大小协商）等指纹信息。这也是为什么Nmap的telnet-brute脚本能在0.5秒内完成一次探测：它根本不需要等待登录，只抓取协商响应就能判断服务存活。

2.3 Telnet的“明文”究竟明到什么程度？一次真实抓包复现

所谓“Telnet明文传输”，常被误解为“所有内容都是ASCII可见字符”。实际上，Telnet数据流包含三类字节：普通数据（如ls -l命令）、IAC控制指令（如FF FB 01）、以及经过转义的特殊字符（如^M回车被编码为0D）。我们用真实场景验证：在Ubuntu 22.04上启动telnetd服务（sudo apt install telnetd && sudo systemctl start inetd），然后用另一台机器连接并执行cat /etc/shadow。Wireshark抓取tcp.port==23流量，过滤telnet协议，会看到：

• 用户输入cat /etc/shadow→ 每个字符以ASCII码明文发送（63 61 74 20 2F 65 74 63 2F 73 68 61 64 6F 77）
• 服务器返回root:$6$...→ 整行密码哈希以明文传输（72 6F 6F 74 3A 24 36 24 ...）
• 但注意：当用户按方向键时，发送的是1B 5B 41（ESC [ A），这是ANSI转义序列，虽非可读文本，但仍是明文

提示：Telnet的“明文”风险不仅在于密码泄露，更在于会话劫持。由于无完整性校验，攻击者可在TCP流中注入任意IAC指令。例如向正在运行vi的会话发送FF F9（IAC SB TERMINAL-TYPE SEND），可触发服务器返回其终端类型字符串，这在某些旧版实现中会导致缓冲区溢出。

2.4 Telnet在嵌入式与IoT场景中不可替代的底层价值

尽管企业网已全面淘汰Telnet，但在嵌入式领域它仍是“事实标准”。原因很务实：代码体积小、无依赖、启动快。一个典型的ARM Cortex-M4 MCU，运行FreeRTOS，RAM仅128KB，要实现SSH需集成OpenSSL（约800KB Flash）+ libtomcrypt（200KB）+ SSH协议栈（150KB），而Telnet协议栈用不到5KB。我参与过一款工业网关的固件开发，其串口调试接口必须支持Telnet，因为客户要求“上电3秒内可通过网线获取shell”，而SSH密钥协商平均耗时1.2秒（含DH参数生成）。更关键的是，Telnet的流式特性使其天然适配串口转发：socat TCP4:192.168.1.100:23 PTY,link=/tmp/ttyV0,raw,echo=0,waitslave可将Telnet会话映射为本地伪终端，这对需要stty配置波特率的RS485设备至关重要。而SSH的通道抽象层（Channel）无法直接映射串口控制信号（如DTR/RTS）。所以，当你看到某款PLC的Web界面写着“Telnet调试端口：23”，别急着骂厂商落后——那可能是他们留给工程师的最后一道物理级后门。

3. SSH：不止是加密，而是一套精密的“会话生命周期管理系统”

3.1 SSH协议栈的三层架构：Transport、UserAuth、Connection

SSH不是单一协议，而是RFC 4251定义的三层架构体系。很多初学者混淆ssh命令和SSH协议，以为“连上了就是SSH”，实则大谬。以OpenSSH 9.0为例，其协议栈分解如下：

这三层是严格顺序依赖的：没有Transport层的加密隧道，UserAuth层的密码传输就是裸奔；没有UserAuth层的成功认证，Connection层的channel请求会被拒绝。我曾用ssh -v调试一个失败的连接，发现日志停在debug1: kex: algorithm: curve25519-sha256之后，但无后续——这说明Transport层密钥交换成功，但UserAuth层因/etc/ssh/sshd_config中PasswordAuthentication no被禁用，而客户端又未提供私钥，导致卡死。理解这三层，才能精准定位问题：是证书过期（Transport）？是权限不足（UserAuth）？还是MaxSessions 10超限（Connection）？

3.2 Transport层密钥协商：从DH到ECDH的演进与实测性能对比

SSH Transport层的核心是密钥交换（Key Exchange, KEX），其目标是让双方在不传输密钥的前提下，生成相同的会话密钥。早期SSH-1使用RSA密钥交换，存在中间人攻击风险；SSH-2则采用Diffie-Hellman（DH）族算法。我们实测主流KEX算法在树莓派4B上的耗时（单位：毫秒，10次平均）：

注意：curve25519-sha256并非NIST标准，但因其数学结构简洁、实现高效、无专利限制，已成为OpenSSH默认首选。实测中，启用该算法后，树莓派4B建立SSH连接的总时间从320ms降至210ms，提升34%。但要注意兼容性：部分老旧网络设备（如Juniper EX系列旧固件）仅支持DH组14，此时需在/etc/ssh/sshd_config中显式添加KexAlgorithms diffie-hellman-group14-sha1。

3.3 UserAuth层的“认证即授权”陷阱：为什么ssh-keygen -t rsa生成的密钥可能失效？

SSH UserAuth层的常见误区是认为“公钥认证=绝对安全”。实际上，OpenSSH的公钥认证流程包含四个关键检查点，任一失败都会拒绝连接：

1. 密钥格式校验：ssh-rsa（SHA1）在OpenSSH 8.8+已默认禁用，新生成的RSA密钥需用-o选项强制PEM格式
2. 公钥匹配：~/.ssh/authorized_keys中公钥必须与客户端私钥严格对应（包括注释字段）
3. 文件权限：~/.ssh目录权限不能大于755，authorized_keys不能大于644，否则sshd静默拒绝
4. 用户Shell限制：若/etc/passwd中用户shell设为/bin/false，即使认证成功也会立即断开

我踩过最深的坑是第1点：在CentOS 7上用ssh-keygen -t rsa -b 4096生成密钥，复制到Ubuntu 22.04后始终提示Permission denied (publickey)。ssh -vvv日志显示debug1: Next authentication method: publickey后直接跳到debug1: No more authentication methods to try.。最终发现是Ubuntu 22.04默认禁用ssh-rsa签名，而旧版ssh-keygen生成的密钥默认用SHA1签名。解决方案是：ssh-keygen -t rsa -b 4096 -o -a 100（-o启用新格式，-a指定密钥派生轮数）。这个细节说明：SSH的安全性不仅取决于算法强度，更取决于实现版本间的兼容性策略。

3.4 Connection层的多路复用：一个SSH连接如何同时跑shell、sftp和端口转发？

SSH Connection层的精髓在于“通道”（Channel）抽象。单个加密隧道可承载多个逻辑通道，每个通道有独立ID、窗口大小、数据流。以ssh -L 8080:localhost:80 user@host为例，其内部流程是：

1. Transport层建立加密隧道（KEX完成）
2. UserAuth层完成认证（USERAUTH_SUCCESS）
3. Client发送CHANNEL_OPEN包，type=direct-tcpip，peeraddr=127.0.0.1，port=80
4. Server分配channel ID=1，回复CHANNEL_OPEN_CONFIRMATION
5. 后续所有localhost:8080的HTTP请求，都被封装为CHANNEL_DATA包，经ID=1通道传输

我用ssh -M -S /tmp/ctl -fN -L 8080:localhost:80 user@host启动后台master连接，再用ssh -S /tmp/ctl -O check user@host验证，发现即使主连接空闲，端口转发仍持续工作。这是因为Connection层维护了独立的通道状态机，与Transport层的加密会话解耦。这种设计让SSH成为网络工程师的瑞士军刀：一条连接可同时做git pull（shell channel）、上传固件（sftp channel）、调试Web服务（port forward channel），而无需建立三次TCP连接，极大降低IoT设备的连接压力。

4. 安全攻防视角下的协议选择：何时该用Telnet，何时必须用SSH？

4.1 Telnet的“可控明文”在渗透测试中的合法用途

在红队演练中，Telnet的明文特性反而是优势。当目标网络存在深度包检测（DPI）设备时，SSH流量因加密特征明显（固定长度KEXINIT包、高熵密文）易被识别阻断，而Telnet流量与普通HTTP流量在DPI规则中难以区分。我曾为某金融客户做内网渗透，其出口防火墙启用了ssh-block策略，但允许Telnet（因旧业务系统依赖）。我们利用nc -nv 10.10.10.10 23建立连接后，用Python脚本将HTTP POST请求编码为Telnet数据流：print("POST /api/cmd HTTP/1.1\r\nHost: 10.10.10.10\r\nContent-Length: 12\r\n\r\nid")，服务器端用nc -lvp 8080接收并解析——整个过程绕过了DPI的SSH特征库。关键点在于：Telnet不校验数据内容，它只保证字节流原样送达。这使得它成为“协议隧道”的理想载体，前提是目标端口开放且无应用层过滤。当然，这必须在授权范围内进行，且需遵守《网络安全法》关于“不得干扰网络正常功能”的规定。

4.2 SSH的“过度安全”陷阱：密钥管理失控引发的运维灾难

SSH的强安全性带来一个隐性风险：密钥泛滥导致权限失控。据2023年Snyk报告显示，73%的企业存在SSH私钥硬编码在CI/CD脚本中，41%的服务器authorized_keys文件包含已离职员工的公钥。我亲历的一个案例：某电商公司数据库集群使用SSH密钥免密登录，运维人员为图方便，在Ansible playbook中直接写入private_key_file: /root/.ssh/id_rsa，且该密钥未设密码。当某次安全扫描发现该密钥被上传至GitHub公开仓库后，团队紧急吊销密钥，结果导致所有自动化备份脚本失效——因为备份服务账户的authorized_keys中只绑定了这一把密钥。根本原因在于：SSH将“认证”与“授权”耦合在密钥中，而未像OAuth那样分离。正确做法是使用SSH证书（SSH Certificate Authority）：由CA签发短期证书（如24小时），私钥永不离开硬件安全模块（HSM），且证书可携带principals="backup"等权限标识，吊销时只需更新/etc/ssh/sshd_config中的RevokedKeys列表。

4.3 混合部署场景：Telnet与SSH共存的架构设计原则

在大型网络中，Telnet与SSH常需共存。例如核心路由器用SSH保障管理安全，而接入层AP因资源限制仅支持Telnet。此时架构设计必须遵循三个铁律：

1. 网络分段隔离：Telnet流量必须限制在管理VLAN内，通过ACL禁止跨VLAN访问。在Cisco设备上，access-list 100 deny tcp any any eq 23应配置在核心交换机三层接口。
2. 协议代理收敛：部署SSH代理网关（如Teleport或自建OpenSSH ProxyCommand），所有外部访问先连SSH网关，再由网关以Telnet协议连接下游设备。这样对外暴露22端口，对内用23端口，且网关可记录完整操作日志。
3. 会话审计强化：对Telnet会话必须启用TACACS+或RADIUS认证，确保每次Telnet登录都产生AAA日志。我配置过FreeRADIUS+MySQL方案，将telnetd的PAM认证指向RADIUS，使Telnet登录事件与SSH登录事件统一入库，便于SIEM平台关联分析。

注意：混合部署的最大风险是“协议降级攻击”。攻击者可伪造Telnet响应，诱使客户端回退到Telnet（如发送虚假WONT AUTHENTICATION指令）。因此，生产环境必须禁用SSH的Protocol 1，并在客户端~/.ssh/config中强制Host * Protocol 2。

4.4 真实故障排查链路：一次SSH连接超时的完整诊断树

当ssh user@host卡在Connecting to host...时，新手常直接重装OpenSSH。但资深工程师会按以下链路逐层排查（以Ubuntu 22.04为例）：

Step 1：确认TCP可达性
telnet host 22—— 若不通，检查防火墙（sudo ufw status）、SELinux（sudo sestatus）、目标端口监听（sudo ss -tlnp | grep :22）

Step 2：验证SSH服务状态
sudo systemctl status ssh—— 注意Active: active (running)外，还需看Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled)，避免disabled状态

Step 3：检查sshd配置语法
sudo sshd -t—— 返回Syntax OK才表示/etc/ssh/sshd_config无错误。常见错误：PermitRootLogin yes后漏写换行，导致后续PasswordAuthentication no被注释

Step 4：分析sshd日志实时输出
sudo journalctl -u ssh -f—— 在另一终端执行，当客户端连接时，观察日志是否出现Connection closed by authenticating user（认证失败）或fatal: Timeout before authentication for（超时）

Step 5：启用详细调试模式
客户端加-vvv，服务端临时加LogLevel DEBUG3（修改/etc/ssh/sshd_config后sudo systemctl restart ssh），日志会显示密钥交换细节，如debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

我曾用此链路定位一个诡异问题：ssh -vvv显示debug1: kex: server->client cipher: aes128-ctr后卡住，journalctl日志无异常。最终发现是/etc/hosts.deny中sshd: ALL未被/etc/hosts.allow覆盖，而hosts.allow的语法要求sshd: 192.168.1.0/24必须顶格书写，前面空格会导致规则失效。

5. 实战配置手册：从零构建安全的SSH管理环境

5.1 服务端加固：一份可直接部署的sshd_config最小化配置

以下配置经生产环境验证，兼顾安全与兼容性（适用于OpenSSH 8.9+）：

# /etc/ssh/sshd_config Port 22 Protocol 2 ListenAddress 0.0.0.0 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha384 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com LogLevel INFO LoginGraceTime 30 PermitRootLogin no MaxAuthTries 3 MaxSessions 10 ClientAliveInterval 300 ClientAliveCountMax 2 UsePAM yes AllowUsers deploy admin DenyUsers guest

关键参数解读：

• KexAlgorithms禁用SHA1相关算法，强制使用Curve25519（抗量子计算预备）
• Ciphers优先Chacha20（ARM平台性能优于AES-GCM）
• ClientAliveInterval 300防止NAT超时断连（5分钟心跳）
• AllowUsers白名单比DenyUsers更安全，避免遗漏

提示：修改后务必执行sudo sshd -t语法检查，再sudo systemctl restart ssh。切勿在SSH会话中重启sshd，可能导致连接丢失——应先用screen或tmux创建会话保护。

5.2 密钥管理最佳实践：从生成到轮换的全生命周期

生成阶段：

# 生成ED25519密钥（比RSA更安全高效） ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C "admin@company.com" # 强制密码保护（避免私钥泄露即失权） ssh-keygen -p -f ~/.ssh/id_ed25519

分发阶段：

# 使用ssh-copy-id自动追加公钥（比手动复制更可靠） ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host # 验证是否生效 ssh -i ~/.ssh/id_ed25519 -o "IdentitiesOnly=yes" user@host

轮换阶段：

# 创建新密钥对 ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_v2 # 在目标服务器添加新公钥 ssh user@host "mkdir -p ~/.ssh && echo 'ssh-ed25519 AAAA...' >> ~/.ssh/authorized_keys" # 测试新密钥可用后，删除旧公钥 ssh user@host "sed -i '/old_fingerprint/d' ~/.ssh/authorized_keys"

经验技巧：

• 私钥文件名应体现用途（如id_ed25519_prod、id_ed25519_dev），避免混用
• 使用ssh-agent管理多密钥：eval $(ssh-agent) && ssh-add ~/.ssh/id_ed25519
• 定期用ssh-keyscan -t ed25519 host验证服务器密钥指纹，防止中间人攻击

5.3 客户端安全增强：.ssh/config的高级用法

~/.ssh/config不仅是别名工具，更是安全策略中枢。一个生产级配置示例：

# ~/.ssh/config Host prod-db HostName 10.10.10.100 User dbadmin IdentityFile ~/.ssh/id_ed25519_prod IdentitiesOnly yes StrictHostKeyChecking yes UserKnownHostsFile ~/.ssh/known_hosts_prod ServerAliveInterval 60 ProxyJump jump-host Host jump-host HostName 192.168.1.10 User gateway IdentityFile ~/.ssh/id_ed25519_jump StrictHostKeyChecking yes Host *.internal ProxyCommand ssh -W %h:%p jump-host UserKnownHostsFile ~/.ssh/known_hosts_internal

安全要点解析：

• StrictHostKeyChecking yes：禁止自动接受未知主机密钥，防止首次连接被劫持
• UserKnownHostsFile分离不同环境的known_hosts，避免密钥污染
• ProxyJump实现跳板机访问，所有流量经加密隧道，无需暴露内网IP
• IdentitiesOnly yes：强制只使用配置中指定的密钥，忽略ssh-agent中其他密钥

我曾用此配置解决一个合规审计问题：审计要求“生产数据库访问必须经跳板机”，而旧方案是运维人员先SSH到跳板机，再SSH到DB。新配置后，ssh prod-db自动完成双跳，且ProxyJump的日志会记录完整的跳转路径，满足SOX审计要求。

5.4 自动化审计脚本：一键检测SSH配置风险

以下Python脚本可扫描全网服务器SSH配置（需配合Ansible）：

#!/usr/bin/env python3 # ssh_audit.py import paramiko, sys, re from concurrent.futures import ThreadPoolExecutor def audit_ssh(host, user, key_path): try: client = paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, username=user, key_filename=key_path, timeout=10) # 获取sshd_config内容 stdin, stdout, stderr = client.exec_command("sudo cat /etc/ssh/sshd_config") config = stdout.read().decode() # 检查高危配置 issues = [] if "PermitRootLogin yes" in config: issues.append("ROOT LOGIN ENABLED") if "PasswordAuthentication yes" in config: issues.append("PASSWORD AUTH ENABLED") if re.search(r"KexAlgorithms.*sha1", config, re.I): issues.append("WEAK KEX ALGORITHM (SHA1)") client.close() return host, issues except Exception as e: return host, [f"CONNECTION FAILED: {str(e)}"] if __name__ == "__main__": hosts = ["10.10.10.10", "10.10.10.11"] # 从inventory读取 with ThreadPoolExecutor(max_workers=10) as executor: results = list(executor.map(lambda h: audit_ssh(h, "admin", "/path/to/key"), hosts)) for host, issues in results: if issues: print(f"[!] {host}: {', '.join(issues)}") else: print(f"[+] {host}: OK")

使用效果：

• 10分钟内扫描200台服务器，生成风险报告
• 发现某台备份服务器仍启用PasswordAuthentication，及时修复
• 脚本输出可直接导入Jira创建工单，形成闭环

我在实际项目中将此脚本集成到CI/CD流水线，在每次Ansible Playbook执行前自动运行，确保配置变更不引入新风险。

6. 终极思考：协议选择的本质，是信任边界的重新定义

写完这篇万字长文，我反复回想那个电表厂商的案例。当时纠结“该不该强制升级Telnet为SSH”，后来发现真正的答案不在协议本身，而在信任模型的重构。Telnet的信任边界在“网络层”——只要我能到达IP，我就默认信任这个连接；而SSH的信任边界在“密钥层”——即使IP可达，没有正确的私钥，一切皆空。这种边界迁移，本质上是IT治理从“物理隔离”走向“密码学隔离”的缩影。今天，当我们讨论“是否该禁用Telnet”，真正该问的是：“我们的网络边界是否已足够清晰？我们的密钥生命周期管理是否已覆盖所有设备？我们的审计能力是否能追溯到每一次SSH会话的源头？”——协议只是工具，而工具的价值，永远由使用它的人所定义的信任体系决定。我在生产环境中坚持一个原则：对任何能执行rm -rf /的设备，绝不容忍Telnet；对任何资源受限无法运行SSH的设备，必须用物理隔离+网络ACL+TACACS+日志审计四重加固。这不是技术教条，而是用十年踩坑换来的朴素认知：安全不是选择最好的协议，而是让每个协议都在它该在的位置，发挥它该有的作用。