用 WireShark 拆解 SSH 协议：从握手到加密传输的完整抓包实战

简介面向信息安全技术应用专业的SSH协议分析教学文档以「单兵模式分组对抗赛题资源3」为背景紧密贴合网络协议分析课程实训、技能竞赛备赛及安全运维初学者的学习需求。文档系统梳理SSH协议三个核心阶段密钥交换阶段重点讲解客户端与服务器各自发送公钥列表、协商匹配加密算法等细节用户认证阶段覆盖none方式探测、密码认证与公钥认证流程加密数据传输阶段说明会话建立后命令加密传输与结果返回机制。同时给出基于WireShark的完整分析路径从配置Ubuntu与CentOS主机IP、启动抓包过滤到实际登录SSH服务逐步观察TCP三次握手、SSH版本信息、密钥交换初始化与密钥交换消息、加密数据流以及TCP断开连接等关键报文每一步都对应预备知识中的协议过程便于对照验证。资源包为docx文档共1个文件压缩包约37KB轻量易用。已有111人学习浏览适合信息安全专业学生、实训教师及对网络协议抓包分析感兴趣的入门者下载参考。1. 直接用 WireShark 拆 SSH 协议从握手到加密数据传输的完整抓包实战做信息安全或者网络运维的几乎天天都要跟 SSH 打交道但真正问起“SSH 连接时两端到底交换了什么、密钥怎么协商出来的、密码是怎么传过去的”能答清楚的人不多。这份《通过 WireShark 进行 SSH 协议分析》的实训资源就是用来解决这个问题的——它不是给你讲一堆协议 RFC 的抽象概念而是把 SSH 协议的工作过程拆成算法协商、密钥交换、用户认证、服务请求、数据传输、连接关闭六个阶段然后带着你在 WireShark 里一步一步抓包、逐包对照分析。适合正在学网络协议分析的信息安全专业学生也适合想补强协议底层认知的运维和安服工程师——毕竟抓包分析这件事光看文档学不会必须有能照着操作的步骤和能对上号的报文特征这份资源恰好把两边都补齐了。2. SSH 协议的三阶段模型算法协商、密钥交换与用户认证是怎么串联的2.1 算法协商客户端和服务器的“能力清单”是怎么对齐的SSH 连接建立的第一个阶段是传输层协议握手眼前要解决的事情就一件通信双方得先确认彼此都支持哪些算法然后从中挑出一套双方都认的组合。资源里对这部分讲得很细SSH 协议支持多种密钥交换算法比如 diffie-hellman-group-exchange-sha256、ecdh-sha2-nistp256 这一类、多种加密算法3des-cbc、aes128-ctr、aes256-gcm 等、多种 MAC 算法hmac-md5、hmac-md5-96、hmac-sha1、hmac-sha1-96 等。因为不同客户端和服务端对这些算法的支持情况不一样所以必须有一个协商过程来对齐双方的能力。协商的逻辑其实不复杂可以理解成“客户端出题、服务端匹配”客户端把自己支持的算法列表按优先顺序发给服务端服务端从客户端的列表第一个算法开始逐个在自己的支持列表里查找匹配上就用这个匹配不上就继续看客户端的下一个直到成功或者全部失败。这个规则适用于每一类算法——密钥交换算法、加密算法、MAC 算法都是这么一个个协商出来的。如果某一类算法全部匹配失败整个 SSH 连接就直接断掉不会进入后续阶段。这套机制在实际抓包里对应的是 SSH_MSG_KEXINIT 消息客户端和服务端各发一条报文里能看到完整的算法列表是分析 SSH 握手的第一个关键观察点。2.2 密钥交换不传密钥本身却能让双方拿到同一把会话密钥算法协商完成之后紧跟着就是密钥交换。这一步的设计意图很明确后续的数据加密需要一把对称密钥但这把密钥不能直接在网络上传输否则第三方截获了就全完了。所以 SSH 协议用的是 Diffie-Hellman 类的密钥交换算法——通信双方各自生成私钥通过交换公开参数计算出一个共享密钥。即使第三方把交换过程中的报文全部抓下来也无法推算出最终的密钥因为离散对数问题在计算上不可行。这就是资源里强调的“安全动态生成交互密钥”的含义。在实际抓包里这一步会看到 SSH_MSG_KEXDH_INIT客户端发起携带自己的公钥材料和 SSH_MSG_KEXDH_REPLY服务端回复携带服务端公钥和签名。这两条报文之后双方各自计算出共享密钥 K 和会话标识符 H后续所有的加密通信都基于这把会话密钥。分析抓包时要注意这时候看到的载荷如果是明文结构的协议消息说明密钥交换还没完成一旦进入加密阶段WireShark 识别出来的就不再是具体的 SSH 消息类型了而是统一的“Encrypted packet”或类似标识——这正是区分密钥交换阶段和加密传输阶段的分水岭。2.3 用户认证none 探测、密码与公钥的完整判定逻辑密钥交换完成之后进入用户认证阶段。资源里把认证过程展开成了五个步骤每一步对应报文里的一段交互逻辑。第一步是客户端先发一个认证方式为“none”的请求这个请求本身就是一种探测——看看服务端到底要求哪些认证方式。第二步是服务端收到 none 请求后回复一个认证挑战报文里面携带服务端支持、且要求该用户完成的认证方式列表。第三步和第四步是核心客户端从服务端给的列表里挑一种方式发起真正的认证请求。密码认证就是传用户名加密码由服务端比对设备本地或远程认证服务器上的记录公钥认证则分两个阶段——先验证公钥本身是否合法再验证客户端用私钥对特定数据做的数字签名。这里有个容易忽略的点如果公钥不合法认证直接失败公钥合法但签名验证不过同样失败。第五步是服务端根据该用户配置决定认证是否结束一条路径是认证成功且不需要其他方式直接回复成功另一条路径是认证成功但还要继续其他认证会再发挑战还有两种情况是认证失败后继续尝试或者累计失败次数达到上限后服务端直接断开连接。抓包分析时报文里的 SSH_MSG_USERAUTH_REQUEST 和 SSH_MSG_USERAUTH_FAILURE / SSH_MSG_USERAUTH_SUCCESS 可以完整还原这段判断过程。3. 实训环境搭建与抓包准备双虚拟机拓扑、IP 规划与 WireShark 过滤条件3.1 拓扑与 IP 配置Ubuntu 与 CentOS 双机互联这份实训资源的实验拓扑是两台 Linux 虚拟机一台 Ubuntu 作为 SSH 客户端一台 CentOS 作为 SSH 服务端。资源里明确写了 IP 规划Ubuntu 配置为 192.168.x.x对应 IPACentOS 配置为另一网段的 IPB两个地址在同一个虚拟网络里互联互通。实操时我一般习惯用 VMware 的自定义 NAT 或仅主机模式让两台虚拟机处于同一子网确保能 ping 通再往下走。在 Ubuntu 上配置 IP 的常见做法是直接改 netplan 配置新版 Ubuntu或者用 /etc/network/interfaces老版本CentOS 上则可以用 nmcli 或直接改 ifcfg 文件。下面给一个 Ubuntu 侧的最小配置示例假设网卡名为 ens33网段 192.168.10.0/24# Ubuntu 客户端编辑 /etc/netplan/01-network-manager-all.yaml network: version: 2 renderer: networkd ethernets: ens33: addresses: - 192.168.10.10/24 gateway4: 192.168.10.1 nameservers: addresses: [192.168.10.1]配置完执行sudo netplan apply生效用ip addr确认地址已经绑上。CentOS 侧同理把地址配成同网段的另一个地址比如 192.168.10.20/24确保两端能互通。这里有个实践细节虚拟机的网络模式决定了抓包能不能看到 SSH 流量桥接模式下流量会走物理交换机NAT 模式下包要经过虚拟网关通常建议用 NAT 或仅主机模式来减少无关广播流量让 WireShark 的过滤结果更干净。3.2 启动 WireShark 并配置过滤条件只留 SSH 流量抓包前先想清楚要过滤什么。SSH 服务默认跑在 TCP/22 端口如果抓包的时候同时有其他网络活动捕获窗口里会混进 ARP、DNS、NTP 等各种噪声包。配置过滤条件的方法是在 WireShark 主界面上方的显示过滤器栏里输入过滤表达式。两种做法捕获过滤器Capture Filter在开始抓包之前设置语法是tcp port 22这样网卡驱动层面就只把 22 端口的包交上来能显著降低抓包文件体积显示过滤器Display Filter在抓完包之后设置语法是tcp.port 22适合已经抓了全量流量、事后过滤的场景。我一般推荐把两种都做一遍先设好捕获过滤器确保抓到的东西足够纯净分析过程中再用显示过滤器做二次筛选比如只看某个 TCP 流的包。捕获过滤和显示过滤的语法容易混淆前者是 BPF 语法、没有等号后者是 Wireshark 的 DSL、字段后面跟。下面是对应的配置方式# 捕获过滤器Capture Options - Capture Filter tcp port 22 # 显示过滤器Filter 栏直接输入 tcp.port 22 ip.addr 192.168.10.10 # 只看 SSH 协议层消息不看底层 TCP 确认包 ssh注意显示过滤器里ip.addr 匹配的是源或目标任一地址如果想要严格的单向流量需要写成ip.src 192.168.10.10或ip.dst 192.168.10.10。另外ssh这个过滤器只匹配被 WireShark 识别为 SSH 协议层的报文而 SSH 流量在 TCP 层之上如果先输入tcp.port 22再叠加 ssh可以把底层的 TCP ACK 包过滤掉只留下真正有协议内容的包分析阶段这样用非常顺手。3.3 从 Ubuntu 发起 SSH 登录并抓取完整交互过程环境准备好之后就可以开始抓包了。打开 WireShark选择承载虚拟机流量的网卡接口VMnet8 或 eth0 之类的虚拟网卡先启动捕获再从 Ubuntu 终端向 CentOS 发起 SSH 登录请求# 在 Ubuntu 客户端发起 SSH 连接 ssh 192.168.10.20 # 首次连接会提示确认主机指纹输入 yes 继续 # 然后输入 CentOS 对应用户的密码完成登录这里的交互过程本身就是一次完整的 SSH 协议演示输入ssh命令触发 TCP 三次握手然后立即进入 SSH 版本交换、算法协商、密钥交换、用户认证四个关键阶段。登录成功后如果执行几条命令再退出还能抓到服务请求和数据传输阶段的报文。建议多抓几轮——第一次登录抓认证过程登录后执行ls、whoami等命令抓数据传输过程exit退出抓连接关闭过程。一轮抓完点停止捕获CtrlS 保存为 pcapng 文件后续分析就不用反复重做实验了。养成“抓完就存”的习惯很重要因为虚拟机环境里的会话状态随时可能变化重新复现一次握手并不总是一模一样的节奏。4. 六步拆解 SSH 会话从 TCP 三次握手到四次断开的报文对照分析4.1 整体报文序列六个分析点对应的包特征资源里的实训步骤把 SSH 协议分析划分成六个阶段TCP 建立连接、SSH 服务版本信息、密钥交换初始化消息、密钥交换消息、加密数据、TCP 断开连接。对应到 WireShark 的报文列表里每个阶段有明确的标志性报文搞清楚“阶段 → 报文特征”的映射关系分析的时候就不用从头到尾翻包了。下面这张表把六个阶段的观察要点列出来对照表里的线索在报文列表里逐包核对就行分析阶段标志性报文关键字段或特征观察目的TCP 建立连接SYN / SYN-ACK / ACK 三条包TCP 三次握手标志位、序号确认连接建立的完整性和方向SSH 版本信息Protocol 版本交换报文明文 banner如 SSH-2.0-OpenSSH_7.4识别两端 SSH 实现与版本密钥交换初始化SSH_MSG_KEXINIT算法列表、cookie 随机数分析协商过程与算法优先级密钥交换消息KEXDH_INIT / KEXDH_REPLY公钥材料、签名、DH 参数理解共享密钥如何生成加密数据加密后的 application data已加密WireShark 无法解析内部结构确认加密生效及加密算法TCP 断开连接FIN / FIN-ACK / ACK 四条包TCP 四次挥手标志位确认会话正常关闭表里这几个特征在抓包里非常显眼TCP 建立连接的三条包是所有会话的开端在 WireShark 里标记为 SYN、SYN-ACK、ACK 的包特别好认SSH 版本信息是 SSH 连接里第一条协议层报文内容是完全明文的KEXINIT 之后的包进入密钥交换报文大小一般比较大KEXDH_REPLY 里能看到服务端签名信息再往后所有数据都变成密文WireShark 的 SSH 解析器会显示为“Encrypted packet”这一步标志着加密通道正式生效。4.2 逐个阶段的报文级验证TCP 握手与版本交换对照表里的线索逐包分析时第一个要看的是 TCP 三次握手。点开第一条 SYN 包的 Ethernet II 和 IP 头部能看到源 MAC 是 Ubuntu 虚拟机的虚拟网卡地址目的 MAC 是 CentOS 的虚拟网卡IP 层源地址是 192.168.10.10、目标地址是 192.168.10.20TCP 层源端口是随机分配的一个高位端口比如 52034目标端口固定是 22。这里有个值得留意的细节TCP 三次握手的 SYN-ACK 包里的确认号等于客户端 ISN初始序号1WireShark 默认启用了相对序号显示所以实际抓包里看到的 Seq0、Ack1 是相对值而非绝对值分析 Windows 缩放或者排查重传时要切到绝对序号再看一眼。紧接着的三条包是 SSH 版本交换。SSH 连接建立后的第一条协议消息以明文形式传输内容类似SSH-2.0-OpenSSH_7.4这样的 banner 行。客户端和服务端各发一条互相告知自己的协议版本和软件版本。分析这条消息可以直接在 WireShark 的报文详情里展开 SSH Protocol 层看到完整的版本字符串。版本信息有两个用途一是确认两端都是 SSH 2.0SSH 1.x 已经废弃遇到 1.99 这种兼容模式要特别小心安全性二是根据 banner 里的 OpenSSH 版本号排查已知漏洞——比如某些 OpenSSH 版本存在 CVE 公告的漏洞版本信息就是判断依据。4.3 密钥交换与加密数据的判别明文边界在哪里KEXINIT 和 KEXDH 这两组报文是 SSH 分析里信息量最大、也最容易看晕的部分。KEXINIT 报文里的 cookie 是随机数不必深究关键在于算法列表展开报文详情能看到 KEX 算法、Server Host Key 算法、Encryption 算法、MAC 算法各有一个列表每个列表里是客户端或服务端按优先级排列的算法名。分析协商结果时取客户端列表的第一个算法看它是否出现在服务端列表里就能预判最终选中的算法。比如客户端第一个写的是curve25519-sha256服务端列表里也有那协商结果大概率就是它。KEXDH_INIT 是客户端发给服务端的公钥材料里面是客户端侧生成的 DH 公开值KEXDH_REPLY 是服务端返回的里面携带服务端公钥、服务端对交换材料的签名以及用于生成共享密钥的参数。WireShark 的 SSH 解析器能把这两个消息类型解析出来展开就能看到具体字段。从 KEXDH_REPLY 之后客户端和服务端各自计算出共享密钥紧接着的 NEWKEYS 消息标志着加密通道正式启用——之后的报文内容全部变成密文WireShark 里会显示为 payload 不可读的状态只有 TCP 头部还能正常解析。判断“加密是否生效”最简单的方法就是看报文内容加密后的包在详情面板里只有字符长度和对齐信息不会再出现可读的协议结构。4.4 认证过程的报文还原none → 挑战 → 成功/失败循环用户认证阶段在抓包里表现为一串 USERAUTH 消息。资源里把认证逻辑展开得很细对应报文看就能理解为什么 SSH 认证不是一次性通过的客户端先发一条SSH_MSG_USERAUTH_REQUEST认证方式写 none用户名写实际登录的用户——这个请求的目的是触发服务端返回挑战。服务端收到后回复SSH_MSG_USERAUTH_FAILURE报文的authentications that can continue字段列出允许的认证方式比如 password、publickey。接下来客户端从列表里挑一种发起真正的认证请求。密码认证的报文里能看到method name: password但密码本身看不见——它是被加密通道保护着的。公钥认证比较特殊会先发一个publickey方式的请求做公钥合法性探测服务端返回失败但声明publickey可继续客户端再发起带签名的正式请求服务端验证签名成功后返回SSH_MSG_USERAUTH_SUCCESS。分析这段交互时重点对照资源里说的“认证次数达到最大值则断开”——如果抓包看到连续多个 USERAUTH_FAILURE 后跟了 TCP FIN说明服务端因为认证失败次数超限主动断开了连接这是排查 SSH 爆破攻击时非常有用的判据。5. 避坑与常见问题SSH 抓包分析中典型翻车点的排查记录5.1 抓包一片空白方向和接口选错导致捕获不到任何 SSH 流量现象WireShark 启动捕获后从 Ubuntu 发起 SSH 登录但窗口里一个包都没有或者只有少量无关的广播包。原因最常见的是选错了捕获接口。虚拟机场景里物理网卡和虚拟网卡并存流量根本不走选中的那个接口。其次是 SSH 端口不是 22实验环境改过 sshd 配置监听了其他端口捕获过滤器tcp port 22自然什么都抓不到。解决先在 Ubuntu 里执行ip addr和ip route确认默认路由走哪个接口然后到 WireShark 的接口列表里找到对应的虚拟网卡VMware 环境通常是 VMnet8 或名字里带 vmnet 的接口。不确定的话用无过滤条件的方式抓几秒看有没有任何流量确定接口有包再套过滤条件。SSH 端口方面在 CentOS 上执行ss -tlnp | grep ssh确认监听端口按实际端口修改捕获过滤器。5.2 SSH 层解不出来中间多了一层奇怪的协议或 IP 分片干扰现象部分 SSH 报文在 WireShark 里没有解析成 SSH Protocol 层而是显示为 TCP 或 TLS没错SSH 的加密特征有时会被误判或者某些包显示为 IP 分片、需要重组才能看全。原因WireShark 对 SSH 的协议解析是启发式的——它先识别 TCP 端口 22 上的流量再通过 banner 文本确认协议。如果中间隔了 GRE 隧道、VXLAN 之类的封装或者报文因为 MTU 问题被 IP 分片启发式解析就可能失效。误判成 TLS 的原因是 SSH 的加密数据流和 TLS 的 Application Data 在特征上有相似性端口不是 22 时容易搞混。解决让 WireShark 强制按 SSH 解析——右键点击报文详情里的 TCP 层选择 “Decode As”把端口或协议强制指定为 SSH。分片问题优先检查虚拟机的 MTU 设置把两端 MTU 统一为 1500尽量避免分片已经抓到的分片包可以在 WireShark 里开启 “Reassemble fragmented IP datagrams” 偏好选项通常在 Edit → Preferences → Protocols → IP 里能找到。5.3 抓不到密码和命令内容对“加密”抱有不切实际的预期现象从 Ubuntu 发起 SSH 登录时抓到了认证请求报文但展开报文详情发现看不到密码、看不到执行命令的具体文本期望的明文字段全是空的。原因这是对 SSH 协议机制的错误预期。SSH 设计的目的就是加密保护整个会话——密码、命令、回显全部在加密通道里传输。密钥交换完成后所有应用层数据都变成密文WireShark 只能识别出“这一段是加密数据”不可能还原出明文内容。如果哪个工具声称能从 SSH 抓包里直接提取密码那它要么是拿到了会话密钥要么是在实施中间人攻击都不是正常的抓包分析范畴。解决密码层面的明文本来就不该出现在抓包里——这正是 SSH 的安全性所在。想要看清加密后的内容可以用抓包分析里的“会话密钥注入”方法在 debug 模式下启动 OpenSSH 服务端并开启sshd -Ddd级别的日志用 SSLKEYLOGFILE 的方式导出会话密钥注意OpenSSH 的密钥导出需要特定编译选项不是所有发行版都支持再把密钥导入 WireShark 完成流量解密。这是教学里常用的验证手段平时排障一般用不到知道有这条路就行。5.4 SSH 认证连续失败被断开UAUTH_FAILURE 后紧跟 FIN 包现象在 WireShark 里看到多条 USERAUTH_FAILURE 之后紧接着出现 FIN 或 FIN-ACK 包SSH 连接被服务端主动关闭。原因客户端在多次认证尝试中提供的凭据都无法通过验证累计失败次数达到服务端配置的上限OpenSSH 默认 MaxAuthTries 是 6服务端按协议规定强制断开连接。这种情况既可能是密码确实输错了也可能是自动化脚本在爆破。解决在 CentOS 的/etc/ssh/sshd_config里确认MaxAuthTries参数默认是 6可以适当调低来加固同时查看/var/log/secure或/var/log/auth.log确认失败来源 IP。从分析角度说抓包里出现这个模式说明连接是被认证策略主动终止的不是网络问题排查方向应该转向凭据和认证配置。5.5 TCP 层反复重传导致 SSH 交互缓慢虚拟化环境的经典问题现象SSH 登录后敲命令明显卡顿抓包里出现大量 TCP Retransmission、Duplicate ACK 包SSH 本身的协议报文占比很低。原因虚拟机环境下 CPU 调度延迟、虚拟网卡的中断合并策略、或者宿主机网络负载波动都可能导致 ACK 响应不及时触发 TCP 重传。很多时候这不是 SSH 配置问题而是底层虚拟网络的问题。解决先确认是不是慢启动或延迟 ACK 导致——在 CentOS 上执行sysctl net.ipv4.tcp_sack和sysctl net.ipv4.tcp_timestamps检查相关参数但常规手段是把虚拟网卡的“RX/TX 队列”绑定到不同 CPU、关闭虚拟机的 TCP 分段卸载TSO/GRO这些配置在 VMware 虚拟网卡的属性里可以调整。带宽充裕的前提下也可以在 Ubuntu 侧调大 TCP 缓冲区sysctl -w net.core.rmem_max16777216这类操作临时改一下试试通常能明显缓解卡顿。6. 把抓包分析变成日常排障习惯Follow Stream、导出对象与解密通道的进阶玩法整套实验走完一遍之后抓包分析的思路可以沉淀成日常排障里能复用的习惯。第一个进阶技巧是 “Follow TCP Stream”——在 WireShark 的报文列表里选中任意一条 SSH 包右键选择 Follow → TCP Stream就能看到这次会话的完整字节流。虽然 SSH 加密通道里看到的只是一堆不可读的密文但通过 Stream Content 窗口可以确认会话的字节总量、确认报文是否完整、有没有数据在传输中被截断。配合每一条 SSH 消息的长度分布可以快速判断一次登录过程是否在某个阶段中断了——比如只有 KEXINIT 没有后续报文问题大概率卡在算法协商或密钥交换阶段。第二个技巧是导出对象和证书信息。在 WireShark 的 File → Export Objects 菜单里能看到从流量里还原出来的可识别对象。SSH 流量本身没有 HTTP 那样方便的对象导出但服务端公钥和主机密钥信息可以在 SSH 协议详情里直接查看。排查 SSH 中间人攻击时这个方法很实用——把当前连接的服务端公钥指纹记下来和服务器上ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub输出的指纹做对比不一致就说明连接被劫持了。我每次排查 SSH 连接异常都会顺手做一次指纹比对成本极低但能排除最严重的安全隐患。第三个值得养成的习惯是结合 tshark 命令行做批量分析。WireShark 的图形界面适合交互式探索但真正处理大量 pcap 文件还是得靠命令行。比如要统计一段时间内所有 SSH 连接的来源 IP 和尝试次数# 统计所有 SSH 流量的源 IP 与其发起的连接次数 tshark -r ssh_capture.pcapng -Y tcp.port 22 -T fields -e ip.src | sort | uniq -c | sort -rn # 只看 TCP 三次握手成功的连接即出现 SYN-ACK 的流 tshark -r ssh_capture.pcapng -Y tcp.flags.syn 1 tcp.flags.ack 1 -T fields -e tcp.stream | sort -u | wc -l # 导出每个 TCP 流的前三个报文方向判断握手是否完整 tshark -r ssh_capture.pcapng -Y tcp.port 22 -T fields -e tcp.stream -e tcp.flags.str | head -50这段命令里的关键在于-Y过滤语法和-T fields的字段输出组合。第一条命令统计源 IP 的分布爆力破解的特征是同一个 IP 出现大量短连接第二条命令只匹配 SYN-ACK 包统计完成了握手的连接数如果完成的连接数远小于握手尝试数说明大量请求根本没进入 SSH 协议层就被拒绝了第三条命令看每个 TCP 流的标志位序列正常是[SYN] → [SYN, ACK] → [ACK] → [PSH, ACK]SSH banner 会带 PSH 标志看到[RST]直接出现则说明端口未开放或防火墙拦截。做这套分析有一个习惯我从开始用 WireShark 起就一直保持抓包后先存原始 pcapng 文件再做任何过滤和分析。原因很简单——显示过滤器可以随时改过滤条件设错了重新输入就行但如果原始文件丢了就得重新搭环境复现整个 SSH 会话成本完全不一样。从那以后我每次做协议分析都强制走一遍“先存原始包 → 再过滤 → 按阶段逐包核对 → 最后用 tshark 做统计”的流程这套流程在这份实训资源对应的 SSH 分析场景里屡试不爽希望帮到你。本文还有配套的精品资源点击获取