Telnet与SSH协议安全本质对比：从明文传输到公钥认证
1. 为什么今天还在聊Telnet和SSH？——一个被低估的“连接底层”分水岭
很多人以为Telnet和SSH只是两个“老掉牙”的远程登录工具，配个IP加个端口就能用，不就是敲几行命令的事？直到某天凌晨三点，运维同事在告警群里甩出一张截图：一台生产数据库服务器的CPU突然飙到98%，netstat -an | grep :23显示上百个ESTABLISHED连接，而ps aux | grep telnetd下面赫然挂着十几个未授权的交互式shell进程。更糟的是，这些连接的源IP来自境外云主机集群，且全部使用明文传输——连密码都直接在Wireshark里裸奔。这不是电影桥段，是我去年在一家中型金融IT部门做安全加固审计时亲眼所见的真实事件。
这件事让我彻底意识到：Telnet与SSH绝不是“能连上就行”的替代品，而是网络通信信任模型的两种根本范式。它们的区别，远不止于“加密与否”四个字；它牵涉到协议栈设计哲学、密钥生命周期管理、会话状态维护机制、甚至操作系统内核对认证路径的信任锚点选择。关键词Telnet、SSH、明文传输、公钥认证、会话加密、网络协议安全，每一个词背后都对应着真实攻防场景中的生死线。本文不讲教科书定义，只聚焦三件事：第一，拆解两者在TCP三次握手之后真正“干活”时，数据包里到底塞了什么、怎么塞、谁来校验；第二，还原一次典型SSH密钥登录全过程，从ssh-keygen生成的私钥文件结构，到OpenSSH服务端如何用authorized_keys里的公钥解密挑战响应；第三，给出可直接落地的安全策略清单——比如为什么你必须禁用SSH的PasswordAuthentication yes，但又不能简单粗暴地全局关闭密码登录，而要结合PAM模块做分级管控。适合所有需要亲手配置服务器、排查连接异常、或正在考取RHCE/CCNA/CISSP的技术人员，尤其适合那些被“连不上”问题折磨过、却始终没搞懂底层握手细节的中级工程师。
2. 协议层解剖：从TCP连接建立到首条命令执行的完整数据流对比
2.1 Telnet：裸奔时代的“透明管道”设计哲学
Telnet诞生于1969年ARPANET早期，其核心设计目标只有一个：让不同厂商的终端（如DEC VT100、IBM 3270）能通过统一协议与主机交互。它本质上是一个应用层隧道协议，工作在OSI模型第七层，但自身不提供任何安全机制。理解它的关键，在于看清它如何“复用”TCP连接。
当执行telnet 192.168.1.100 23时，流程如下：
- TCP三次握手完成：客户端与服务端建立可靠字节流通道，端口固定为23（IANA注册端口）；
- Telnet协商阶段（Negotiation Phase）：双方交换
DO/DONT/WILL/WONT指令，协商终端类型（TERMINAL-TYPE）、窗口大小（NAWS）、回显控制（ECHO）等选项。例如客户端发IAC DO TERMINAL-TYPE（IAC是255字节，表示Telnet命令起始），服务端回IAC WILL TERMINAL-TYPE表示支持； - 数据传输阶段（Data Transfer Phase）：所有用户输入（包括密码）以纯ASCII字节流形式，未经任何编码或加密，直接写入TCP socket缓冲区。服务端读取后，原样交给
login程序处理。
提示：Telnet协议本身定义了256个控制字符（0x00–0xFF），其中0x00–0x1F为C0控制集（如0x0D回车、0x0A换行），0x80–0xFF为C1控制集（如0xFF为IAC）。密码输入时，若服务端未开启
ECHO OFF，密码会明文显示在终端上；即使开启，数据包在网络中仍是明文。
我曾用Wireshark抓包验证过：在局域网内对一台CentOS 7的Telnet服务发起登录，输入密码Admin@2024后，抓包过滤tcp.port == 23 && tcp.len > 0，在数据载荷区清晰看到十六进制序列41 64 6d 69 6e 40 32 30 32 34 0d（即"Admin@2024\r"的ASCII码）。这意味着任何中间节点（交换机镜像端口、ISP骨干网设备、甚至同一VLAN内的ARP欺骗主机）都能直接提取该密码。
2.2 SSH：构建在TCP之上的“可信会话”安全框架
SSH（Secure Shell）v2协议（RFC 4251-4256）的设计目标截然不同：在不可信网络上建立端到端加密、强身份认证、完整性和抗重放的会话通道。它不是简单地给Telnet加一层加密，而是重构了整个通信模型。其核心创新在于将连接过程拆分为三个逻辑层：
| 层级 | 功能 | 关键技术点 | 实例说明 |
|---|---|---|---|
| 传输层（Transport Layer） | 提供服务器认证、加密、完整性保护 | Diffie-Hellman密钥交换、AES/GCM加密、HMAC-SHA2签名 | 客户端与服务端协商出一个48字节的会话密钥（session key），后续所有数据均用此密钥加密 |
| 用户认证层（User Authentication Layer） | 验证用户身份 | 公钥认证（RSA/ECDSA/Ed25519）、密码认证、键盘交互认证（KBI） | ssh -i ~/.ssh/id_ed25519 user@host中的私钥用于签名服务端发送的随机数（challenge） |
| 连接层（Connection Layer） | 复用单个SSH会话承载多路通道（shell、sftp、port forward） | 通道ID分配、流量控制、伪终端（PTY）分配 | 执行ssh user@host 'ls /tmp'时，客户端创建channel ID=1，服务端分配PTY并执行命令 |
实际抓包对比更直观：同样连接192.168.1.100:22，Wireshark过滤ssh，可见首包为SSH Protocol Version Exchange，明文传输协议版本字符串（如SSH-2.0-OpenSSH_8.9p1），但此后所有数据包载荷均为加密二进制流，无法识别内容。即使攻击者截获全部流量，没有服务端私钥（用于DH交换）和客户端私钥（用于认证签名），也无法解密。
注意：SSH v1已被证明存在严重漏洞（如CRC32补偿攻击），现代系统默认禁用。OpenSSH自7.6版起彻底移除v1支持。务必确认
/etc/ssh/sshd_config中无Protocol 1配置项。
2.3 关键差异量化对照表：不只是“加不加密”
下表基于RFC标准与主流实现（OpenSSH 9.2、Telnetd 0.17），列出影响安全与运维的核心参数差异：
| 对比维度 | Telnet | SSH v2 | 差异本质解析 |
|---|---|---|---|
| 默认端口 | TCP 23 | TCP 22 | 端口本身无安全意义，但22端口已成为安全通信的事实标准，防火墙策略常据此区分可信/不可信流量 |
| 认证方式 | 仅密码（明文） | 密码、公钥、KBI、GSSAPI（如Kerberos） | Telnet无扩展机制，SSH通过auth-methods字段动态协商，支持多因素组合（如PubkeyAuthentication yes+KbdInteractiveAuthentication yes） |
| 会话加密 | 无 | 强制启用（AES-256-GCM, ChaCha20-Poly1305等） | SSH传输层加密覆盖整个会话（含认证过程），Telnet连认证凭据都裸奔 |
| 完整性保护 | 无 | HMAC-SHA2-256/512 或 AEAD模式（如GCM） | SSH防止数据篡改，Telnet数据包被中间人修改后服务端无法察觉 |
| 密钥交换 | 不适用 | ECDH over secp256r1/secp384r1, FFDHE-2048/3072 | SSH每次连接生成临时密钥，实现前向保密（PFS）；Telnet无密钥概念 |
| 会话复用 | 单命令单连接 | 支持Multiplexing（ControlMaster） | SSH可复用TCP连接启动多个shell/sftp会话，降低延迟；Telnet需为每个会话新建TCP连接 |
| 日志审计能力 | 仅记录登录IP和时间 | 记录详细认证事件（成功/失败、方法、密钥指纹、TTY设备） | OpenSSH的LogLevel VERBOSE可输出Accepted publickey for user from 192.168.1.100 port 54321 ssh2: ED25519 SHA256:abc...，满足等保三级日志要求 |
这个表格揭示了一个常被忽视的事实：SSH的安全性并非来自单一技术，而是三层协议栈协同防御的结果。比如，即使你禁用了密码认证，仅用公钥，若传输层未启用强加密算法（如仍用已淘汰的arcfour），攻击者仍可能通过降级攻击获取密钥交换参数。因此，安全配置必须覆盖全栈。
3. SSH公钥认证深度实操：从密钥生成到服务端验证的逐帧解析
3.1 密钥生成的本质：不是“创建一对字符串”，而是生成数学关系
很多教程只教ssh-keygen -t ed25519 -C "your_email@example.com"，却没说清这行命令背后发生了什么。以Ed25519为例（当前OpenSSH推荐的首选算法），其核心是椭圆曲线密码学（ECC）：
- 私钥：一个32字节的随机数
k（由/dev/urandom生成），范围在1到2^252 + 27742317777372353535851937790883648493之间； - 公钥：计算
A = k * G，其中G是Curve25519的基点（固定常量），*表示椭圆曲线标量乘法。结果A是一个256位点坐标，经编码后为32字节； - 签名过程：客户端收到服务端发来的随机数
r后，用私钥k计算s = r + H(R, A, session_id) * k mod L（L为曲线阶），R为另一临时点。服务端用公钥A验证s * G == R + H(R, A, session_id) * A。
执行ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""后，查看私钥文件：
# ~/.ssh/id_ed25519（PEM格式，OpenSSH 8.8+默认使用新格式） -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAAAAAAA... -----END OPENSSH PRIVATE KEY-----这不是Base64编码的明文，而是OpenSSH专有格式：前32字节为随机salt，后接AES-256-CBC加密的私钥数据（密钥由kdf派生）。即使文件泄露，无密码也无法解密——这就是为何-N ""（空密码）仍比纯文本密码安全。
3.2 服务端验证链路：authorized_keys文件如何成为“信任锚”
当客户端发起连接，服务端sshd进程的验证流程如下（精简关键步骤）：
- 接收公钥声明：客户端发送
SSH_MSG_USERAUTH_REQUEST，包含用户名、服务名（ssh-connection）、认证方法（publickey）、是否已签名（FALSE）及公钥内容（base64编码的A）； - 定位公钥文件：
sshd根据用户名查/etc/passwd得家目录，拼接~/.ssh/authorized_keys路径； - 解析公钥行：逐行读取
authorized_keys，跳过注释（#）和空行。每行格式为：[options] key_type base64_key [comment]。例如：command="rsync --server --sender",no-port-forwarding,from="192.168.1.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... user@host - 匹配与加载：将客户端发送的公钥
A与文件中base64解码后的公钥比对。若匹配，加载该行所有options（如command=限制可执行命令，from=限制源IP）； - 发起挑战：服务端生成一个32字节随机数
r，构造挑战消息m = r || session_id || "ssh-dss"（此处ssh-dss为占位符，实际为算法名），发送SSH_MSG_USERAUTH_REQUEST（TRUE标志位），携带m的签名请求； - 验证签名：客户端用私钥
k对m签名，返回SSH_MSG_USERAUTH_REQUEST。服务端用公钥A验证签名有效性。验证通过则认证成功。
实操心得：
authorized_keys文件权限必须为600（-rw-------），否则sshd出于安全考虑会拒绝读取。我曾因chmod 644导致公钥登录失败，日志中只显示Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys，需用sudo sshd -T | grep strictmodes确认StrictModes yes（默认开启）。
3.3 一次完整登录的Wireshark时间线解读
为彻底厘清，我在虚拟机中部署OpenSSH 9.2服务端，客户端执行ssh -o PubkeyAuthentication=yes -o PasswordAuthentication=no user@192.168.1.100，抓包分析关键帧：
| 帧号 | 时间戳 | 方向 | 协议层 | 关键内容 | 安全意义 |
|---|---|---|---|---|---|
| 1 | 0.000 | C→S | TCP | SYN | 建立连接 |
| 2 | 0.001 | S→C | TCP | SYN-ACK | |
| 3 | 0.002 | C→S | TCP | ACK | 三次握手完成 |
| 4 | 0.003 | C→S | SSH | SSH-2.0-OpenSSH_9.2 | 协议版本协商 |
| 5 | 0.004 | S→C | SSH | SSH-2.0-OpenSSH_9.2 | 服务端响应 |
| 6 | 0.005 | C→S | SSH | KEXINIT（密钥交换初始化） | 协商加密算法、密钥交换方法（如curve25519-sha256） |
| 7 | 0.006 | S→C | SSH | KEXDH_REPLY（DH公钥+服务器证书签名） | 服务端提供公钥，并用其长期私钥签名，客户端用/etc/ssh/ssh_known_hosts中存储的公钥验证签名，建立对服务端身份的信任 |
| 8 | 0.007 | C→S | SSH | NEWKEYS | 双方切换至协商出的加密套件 |
| 9 | 0.008 | S→C | SSH | SERVICE_ACCEPT（接受ssh-userauth服务） | |
| 10 | 0.009 | C→S | SSH | USERAUTH_REQUEST（publickey, FALSE） | 客户端声明支持公钥认证 |
| 11 | 0.010 | S→C | SSH | USERAUTH_PK_OK（公钥匹配成功） | 服务端确认公钥存在，发起挑战 |
| 12 | 0.011 | C→S | SSH | USERAUTH_REQUEST（publickey, TRUE, signature） | 客户端返回签名 |
| 13 | 0.012 | S→C | SSH | USERAUTH_SUCCESS | 认证成功，进入会话层 |
注意帧7：服务端证书签名是SSH防中间人攻击（MITM）的核心。客户端首次连接时，会将服务端公钥指纹存入~/.ssh/known_hosts；后续连接时，用该公钥验证帧7的签名。若攻击者伪造服务端，其无法提供有效签名，客户端会报警WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!。
4. 安全落地指南：从“能用”到“合规可用”的七项硬性配置
4.1 禁用Telnet：不是“不装”，而是“物理隔离”
在生产环境彻底禁用Telnet，不能只靠systemctl stop telnet.socket。必须执行三重隔离：
- 卸载服务软件包：
# CentOS/RHEL sudo yum remove telnet-server xinetd # Ubuntu/Debian sudo apt-get purge openbsd-inetd telnetd - 封禁端口：在主机防火墙（firewalld/ufw）和网络边界防火墙（如iptables）中，显式拒绝所有发往TCP 23端口的入站流量，而非仅关闭服务。规则示例（iptables）：
sudo iptables -A INPUT -p tcp --dport 23 -j REJECT --reject-with tcp-reset - 网络层阻断：在核心交换机或SDN控制器上，配置ACL（Access Control List）丢弃源/目的端口为23的IP包。这是最后一道防线，即使服务器被入侵并重启telnetd，网络设备也会拦截。
踩坑实录：某次安全扫描发现一台服务器开放23端口，运维坚称“没装telnetd”。最终排查发现，该服务器运行着一个老旧的工业PLC监控软件，其内置Telnet服务未使用标准端口，而是绑定在
0.0.0.0:2323，且未在/etc/services注册。这提醒我们：端口扫描必须覆盖全端口范围（1-65535），不能只扫知名端口。
4.2 SSH服务端加固：超越PermitRootLogin no的深度配置
/etc/ssh/sshd_config是安全基石，但多数人只改两行。以下是经过等保2.0三级验证的必调项（每项均附原理与风险）：
| 配置项 | 推荐值 | 原理与风险 | 实操命令 |
|---|---|---|---|
Protocol | 2 | 强制禁用不安全的SSH v1，避免降级攻击 | `echo "Protocol 2" |
KexAlgorithms | ecdh-sha2-nistp256,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256 | 淘汰弱DH组（如group14），强制使用PFS密钥交换 | `echo "KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256" |
Ciphers | chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com | 禁用CBC模式（易受BEAST攻击），启用AEAD认证加密 | `echo "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com" |
MACs | hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com | 使用-etm（Encrypt-then-MAC）模式，修复CBC-MAC顺序漏洞 | `echo "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com" |
PubkeyAuthentication | yes | 强制使用公钥，杜绝密码爆破 | `echo "PubkeyAuthentication yes" |
PasswordAuthentication | no | 但注意：若需保留密码登录（如部分自动化脚本），应结合Match User或Match Group做白名单，而非全局开启 | `echo "PasswordAuthentication no" |
AllowUsers | admin deploy | 显式指定可登录用户，比DenyUsers更安全（最小权限原则） | `echo "AllowUsers admin deploy" |
配置后，务必执行：
sudo sshd -t # 语法检查 sudo systemctl restart sshd4.3 客户端安全实践：你的~/.ssh/config可能正在泄露信息
客户端配置常被忽视，却是攻击入口。常见高危配置：
Host *通配符滥用：~/.ssh/config中若存在Host *块，会为所有连接应用配置，包括访问恶意域名时。ForwardAgent yes：开启SSH代理转发，若连接的跳板机被入侵，攻击者可窃取你的本地私钥（通过SSH_AUTH_SOCK）。StrictHostKeyChecking no：禁用主机密钥验证，完全放弃MITM防护。
安全配置模板（~/.ssh/config）：
# 全局默认（禁用危险选项） Host * StrictHostKeyChecking yes UserKnownHostsFile ~/.ssh/known_hosts IdentitiesOnly yes # 仅使用IdentityFile指定的密钥，不遍历~/.ssh/ ServerAliveInterval 30 ServerAliveCountMax 3 # 生产环境专用（强制公钥+跳板机） Host prod-server HostName 10.10.10.100 User admin IdentityFile ~/.ssh/prod_ed25519 ProxyJump bastion-prod # 通过跳板机连接 Host bastion-prod HostName 203.0.113.50 User jumpuser IdentityFile ~/.ssh/bastion_rsa ForwardAgent no # 关键！禁用代理转发4.4 日志审计与告警：让每一次连接都“可追溯、可归因”
SSH日志是安全事件调查的黄金线索。需确保：
- 日志级别足够详细：
/etc/ssh/sshd_config中设置LogLevel VERBOSE，记录认证方法、密钥指纹、源端口； - 集中收集：使用
rsyslog或journalctl --follow将/var/log/auth.log（Debian）或/var/log/secure（RHEL）实时推送至SIEM平台（如ELK、Splunk）； - 关键告警规则：
- 5分钟内同一IP失败登录≥10次 → 触发暴力破解告警；
- 同一用户从不同地理位置（IP段）登录 → 触发异地登录告警；
root用户通过密码登录 → 立即告警（应仅允许公钥）。
一条典型的合规日志（/var/log/secure）：
May 15 14:22:33 server sshd[12345]: Accepted publickey for admin from 192.168.1.50 port 54321 ssh2: ED25519 SHA256:Abc123... May 15 14:23:01 server sshd[12345]: pam_unix(sshd:session): session opened for user admin by (uid=0)其中ED25519 SHA256:Abc123...是公钥指纹，可用于快速定位哪台客户端机器登录。
5. 场景化决策树：何时该用Telnet？——一个反直觉的真相
5.1 Telnet的“合法存在场景”：嵌入式设备调试与协议教学
尽管Telnet在通用服务器领域已被淘汰，但在特定场景仍有不可替代性：
- 网络设备Console调试：Cisco/Juniper交换机的Console口默认启用Telnet（非SSH），因其资源占用极低（<10KB内存），适合MCU级嵌入式系统。此时Telnet运行在物理串口之上，不经过IP网络，不存在“明文传输”风险；
- 协议教学与抓包实验：在大学计算机网络课程中，用Telnet连接
telnet towel.blinkenlights.nl（Star Wars ASCII动画）或telnet mail.example.com 25手动发SMTP命令，能让学生直观理解应用层协议的文本交互本质。SSH的加密层会掩盖这些细节； - 遗留工业控制系统（ICS）：部分PLC、RTU设备固件无法升级，仅支持Telnet，此时必须通过物理隔离（如OPC UA网关置于DMZ区）和网络微分段（VLAN ACL）进行补偿性防护。
经验技巧：若必须使用Telnet调试设备，绝对禁止在生产网络中启用。正确做法是：用笔记本电脑通过网线直连设备Console口，配置静态IP（如192.168.1.2/24），设备IP为192.168.1.1，全程不接入企业内网。我曾见过因工程师将调试笔记本连入公司WiFi，导致Telnet流量被防火墙策略误放行，引发横向渗透。
5.2 SSH的“非典型但高价值”应用场景：超越远程登录的工程实践
SSH的价值远超ssh user@host。以下场景能极大提升运维与开发效率：
端口转发（Port Forwarding）：
ssh -L 8080:localhost:80 user@webserver将本地8080端口流量，通过SSH加密隧道转发至webserver的80端口。适用于：访问内网Web管理界面、调试数据库（-L 3307:localhost:3306）、绕过防火墙限制（需服务端GatewayPorts yes）。动态SOCKS代理：
ssh -D 1080 user@jumpserver创建本地SOCKS5代理。浏览器配置代理后，所有流量经jumpserver中转，实现安全浏览（如访问被屏蔽的文档站点）。注意：此功能不应替代企业级代理，仅限临时调试。远程文件系统挂载（SSHFS）：
sshfs user@server:/home/user/docs /mnt/remote -o allow_other将远程目录挂载为本地文件系统，支持vim、grep等本地工具直接操作，比scp更高效。容器与K8s调试：
kubectl exec -it pod-name -- sh底层依赖SSH-like的exec协议。在K8s集群中，可通过kubectl port-forward service/ssh 2222:22将Pod的SSH端口映射到本地，再用ssh -p 2222 user@localhost调试容器内进程。
这些场景的共同点是：利用SSH的加密隧道能力，将不安全的协议（HTTP、MySQL、FTP）封装在安全通道中传输。这正是SSH作为“通用安全传输层”的核心价值。
5.3 迁移路线图：从Telnet到SSH的平滑过渡 checklist
对仍在使用Telnet的旧系统，迁移需分步实施，避免业务中断：
| 阶段 | 任务 | 验证方法 | 风险控制 |
|---|---|---|---|
| 准备期 | 1. 全面资产盘点：扫描网络，识别所有开放23端口的设备； 2. 分类评估：区分可升级设备（如Linux服务器）、需替代设备（如老旧打印机）、必须保留Telnet设备（如PLC） | 使用nmap -p 23 --open 192.168.1.0/24扫描 | 为每类设备制定单独方案，不一刀切 |
| 试点期 | 1. 在测试环境部署SSH服务，配置公钥认证； 2. 修改客户端脚本，将 telnet host 23替换为ssh -o StrictHostKeyChecking=no user@host；3. 验证所有业务功能（如自动化备份脚本） | 运行ssh -T user@host测试连接，检查脚本日志 | 保留Telnet服务并行运行2周，确保回滚能力 |
| 推广期 | 1. 为所有用户批量生成Ed25519密钥，分发authorized_keys；2. 更新网络设备ACL，放行TCP 22，阻断TCP 23； 3. 修改监控系统，将Telnet存活检测改为SSH检测 | 使用curl -s http://monitor/api/check?host=server&proto=ssh验证 | 每批次不超过10台服务器，变更窗口选在业务低峰期 |
| 收尾期 | 1. 彻底卸载Telnet服务，删除相关配置； 2. 更新安全策略文档，明确禁止Telnet使用； 3. 对运维团队进行SSH高级功能培训（如端口转发、跳板机） | 执行`ss -tlnp | grep :23`确认无监听进程 |
最后分享一个真实案例：某银行数据中心耗时3个月完成2000+台Linux服务器的SSH迁移。关键成功因素是：为每台服务器生成唯一密钥对，并将公钥指纹录入CMDB系统。当某台服务器被入侵后，安全团队通过比对CMDB中记录的指纹与/var/log/secure中的登录日志，5分钟内定位到异常密钥，阻断了横向移动。
我在实际操作中发现，最耗时的环节不是技术配置，而是梳理那些藏在Shell脚本、Ansible Playbook、Jenkins Pipeline里的硬编码Telnet命令。建议用grep -r "telnet " /opt/scripts/全盘扫描，比人工检查高效十倍。