简介面向信息安全技术应用专业聚焦通过WireShark进行SSH协议抓包分析的赛题配套文档内容源自单兵模式赛题资源分组对抗赛题资源3适合网络信息安全方向学生、竞赛备赛者及课程实训师生参考。文档系统讲解SSH协议密钥交换、用户认证、加密数据传输三个阶段详细介绍客户端与服务器算法协商、基于none方式发起认证挑战、密码或公钥认证、服务请求与会话建立等机制并配合WireShark实操从TCP三次握手开始逐步分析SSH版本信息、密钥交换初始化、加密数据、TCP断开连接等报文特征让读者理解每个阶段在网络抓包中的具体呈现从而建立协议排错与安全分析思路。资源包仅含1个docx文档大小约37KB文件体量小、结构清晰便于直接阅读和按实训步骤对照操作。目前已有111人学习下载可用于课程设计、技能竞赛备赛或日常网络协议分析练习是快速掌握WireShark分析SSH通信流程的实用参考资料。1. 为什么SSH协议分析是Wireshark抓包里的硬骨头搞信息安全技术应用的人迟早要过这一关用Wireshark去分析SSH协议。SSH是所有远程管理通道里用得最多的一个服务器维护、设备调试、自动化运维全依赖它一旦这条链路出问题你连排查的入口都没有。Wireshark抓SSH包最大的价值在于你能亲眼看到一次完整的SSH会话从TCP三次握手、版本协商、密钥交换直到加密隧道建立的全过程而不是面对黑匣子瞎猜。但这恰恰是最容易劝退新手的地方SSH协议本身是加密的抓到的包看起来全是乱码和一堆Encrypted packet标记根本不知道从哪下手。很多初学者装好Wireshark设置好过滤器tcp.port 22一敲抓了半天全是一堆不认识的东西最后只能放弃。这篇笔记就是来解决这个问题的——我把一套能直接复现的SSH协议分析流程拆开从环境准备、抓包姿势到参数解读一路讲清楚哪些窗口值得看、哪些标记是误导、哪些坑是几乎每个人都踩过的。内容面向两类人一是信息安全技术应用专业的学生作为《通过WireShark进行SSH协议分析》这类实训任务的配套参考二是刚上手Wireshark的运维或安全工程师需要快速掌握SSH流量分析的基本套路。下一章先从工具本身说起——Wireshark怎么装、抓包接口怎么选、显示过滤器怎么写这些基础不牢后面全白搭。2. WireShark抓SSH包前的准备安装、接口与过滤器2.1 Wireshark的工作机制与SSH协议分析的对应关系在真正开始抓SSH包之前你得先理解Wireshark是靠什么工作的。Wireshark本质是一个包嗅探器它把网卡上经过的数据帧原样复制一份交给上层解析引擎然后通过一系列协议解码器dissector把二进制数据翻译成你能看懂的结构化字段。这个过程是旁路的——它不修改包、不参与通信所以对业务本身零干扰这也是它适合做协议分析而不是故障注入的原因。SSH协议在Wireshark里对应的解码器叫ssh和ssh2。早期版本的Wireshark只区分SSHv1和SSHv2两个协议现在新版已经全部走ssh2解码路径。但有个容易让新手迷惑的现象过滤条件写ssh能显示出来写ssh2也能显示出来这两个在显示过滤器中的匹配对象并不完全一致。我一般直接写ssh兼容性最好也不容易漏包。Wireshark解析SSH包是分层的第一层是TCP负责把字节流按序列号重组成完整的报文段第二层才是SSH协议本身只有当你看到SSH的二进制包协议标识比如SSH-2.0-OpenSSH_7.4时Wireshark才确定这是SSH流量并启动对应的dissector。如果抓包时链路层不是以太网而是其他类型或者中间有隧道封装SSH解析会直接失败表现为所有包停留在TCP层。2.2 Wireshark安装与抓包接口选择的四个关键点Wireshark的安装本身没有太多技术含量官网下载对应平台的安装包一路下一步就行。但有几个配置项会直接决定你后面能不能抓到SSH包。先说Windows平台安装时有个Install Npcap的勾选项这个一定要装上。Npcap是Wireshark在Windows下访问网卡的底层驱动如果你用的是老版本WinPcap在新系统上经常出现抓不到包或者接口列表空白的问题。安装完成后打开Wireshark主页面上会列出所有可用的捕获接口。你要做的第一件事是确认哪个接口对应你实际的物理网卡而不是那个叫Npcap Loopback Adapter的虚拟接口。判断方法很简单点开接口旁边的图表看有没有实时流量跳动。如果你要抓的SSH会话发生在远程服务器之间而不是本机发起的那就不能靠本机WiresHark直接抓了。常见做法是在服务器上装tcpdump把流量存成pcap文件再拷贝到本地用Wireshark打开分析。这个流程在后面第5章的避坑部分还会再提。如果本机有多个网卡比如有线加无线或者装了虚拟机虚拟网卡接口选错会导致完全抓不到SSH流量。这时候有个技巧显示过滤器区域先放空直接看接口列表里哪个接口的收到数据包数量在持续增长基本就是当前实际通信的那块网卡。捕获选项里有混杂模式Promiscuous Mode的开关。默认开启意思是网卡会接收并非发给本机的数据帧。但这个模式在交换网络环境里基本无效——交换机不会把别人的流量广播给你。所以如果是为了分析自己的SSH调试流量开不开无所谓如果是做局域网流量监控你需要的是端口镜像而不是指望混杂模式。2.3 显示过滤器语法SSH抓包的三个必会表达式Wireshark的过滤分两层捕获过滤Capture Filter和显示过滤Display Filter。捕获过滤在抓包时就丢弃不匹配的包用的是BPF语法功耗低但写起来受限显示过滤是在已抓到的包里做筛选用的是Wireshark自定义语法功能强大支持字段级匹配。对于SSH分析我建议直接在显示过滤上做因为捕获过滤一旦写错你会丢包但浑然不知而显示过滤随时可以改。做SSH协议分析真正高频使用的显示过滤器就这么几条tcp.port 22这是最基本的一条筛选所有源或目的端口为22的TCP流量包括握手包和SSH数据包。如果你抓的是SSH默认端口这一条就能覆盖整个会话。ssh || tcp.port 22当Wireshark能把部分包正确解码为SSH协议时ssh这个过滤条件会匹配。但TCP握手的三个包SYN、SYN-ACK、ACK在SSH连接建立之前还没有任何SSH特征它们只会被tcp.port 22匹配到。我一般写ssh || tcp.port 22这样从第一个SYN包到最后的加密通道关闭整个生命周期一条不漏全显示出来。tcp.port 22 tcp.flags.syn 1如果你只想看连接建立过程或者想快速定位某次SSH会话的起始位置用这个过滤条件直接跳到握手包。实际分析时我经常先用这条定位到会话起点然后右键选择Follow TCP Stream把整个TCP流完整还原出来。给刚上手的朋友一个建议不要试图记住所有过滤器语法只需要会组合tcp.port、ip.addr、tcp.flags这三个基础条件就能覆盖90%以上的日常分析需求。真遇到复杂场景再查过滤器参考手册那才是它该出场的时候。3. 用WireShark完整捕获一次SSH会话抓包到手分析3.1 搭建本地SSH实验环境最小可复现方案做SSH协议分析最理想的学习对象是自己能完全控制的会话。我强烈建议别一上来就分析生产环境的SSH流量——加密内容你根本看不懂碰到问题也不知道是协议问题还是网络问题。自己搭一个最小环境反复抓包、反复比对把SSH握手每个阶段长什么样记在心里再去看真实流量才会有感觉。最小环境有两种搭法。第一种最简单本机装一个OpenSSH客户端Windows 10以上系统自带ssh命令再在局域网里找一台开了SSH服务的Linux机器直接ssh userhost连上去执行一条命令就断开。第二种是纯本机方案如果你有Linux虚拟机直接在虚拟机里跑sshd从宿主机连过去。两者抓包姿势一样都是Wireshark监听物理网卡。以Windows宿主机连接Ubuntu虚拟机为例操作步骤是这样的先在Ubuntu里确认SSH服务在跑。sudo systemctl status sshd # 如果没装先安装 sudo apt update sudo apt install -y openssh-server sudo systemctl enable --now sshd ip addr show | grep inet # 记下虚拟机IP比如192.168.1.100这段命令干了三件事检查sshd是否存活没有就装设置开机自启并立即启动最后打印本机IP地址这是后面连接时要用到的目标地址。然后在宿主机上打开Wireshark选定物理网卡显示过滤器输入tcp.port 22点击开始捕获。接着打开命令提示符执行ssh admin192.168.1.100用户名和IP换成你自己的实验环境。连接时输入密码进入Shell后随便敲一条ls或者uname -a然后exit退出。这一步的操作是有讲究的——你登录后执行的命令会产生加密后的交互数据这些数据在Wireshark里虽然看不懂明文但它们的长度、频率、方向本身就是分析素材。如果只是建立连接就断开你就错过了一半的观察对象。3.2 SSH握手五阶段在Wireshark里的对照观察抓完包后停止捕获你会看到一长串端口22的TCP包。SSH协议的建立过程可以按顺序拆成五个阶段每个阶段在Wireshark的Packet List面板里都有明显的特征。第一阶段是TCP三次握手。你会看到三个标记为[SYN]、[SYN, ACK]、[ACK]的包TCP层的Sequence Number和Acknowledgment Number在这几个包之间是严格对应的。这三个包确认了连接双方的初始序列号是后续所有TCP传输的基石。第二阶段是SSH版本协商。客户端连接建立后立刻发送一个文本行内容类似SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5服务端也会回一个类似的行。这个阶段是SSH会话中仅有的明文部分Wireshark直接在Info列就能看到完整版本字符串。这行文本太重要了——它同时暴露了SSH协议版本2.0、服务端软件OpenSSH、版本号和操作系统发行版信息安全分析里第一眼就要看它。第三阶段是密钥交换Key Exchange。从这之后所有SSH消息都是以SSH二进制包格式传输的Wireshark会显示SSHv2 - MSG_KEXINIT这样的报文类型。KEXINIT消息里携带的是双方各自支持的算法列表包括密钥交换算法、加密算法、MAC算法和压缩算法。在Wireshark的Packet Details面板里展开这条消息你能看到每个算法候选清单这部分可以直接证明对方支持的加密强度。接下来是实际的密钥交换数据如ECDH参数一旦经过这一步后续所有数据都是加密的。第四阶段是认证。这阶段的包数量不多通常表现为几条SSHv2 - MSG_USERAUTH_REQUEST和MSG_USERAUTH_SUCCESS的标记。如果你用的是密码认证Wireshark能识别出这是用户认证请求但具体的用户名和密码不会明文显示——用户名会以明文出现在USERAUTH_REQUEST的字段里但密码部分是不可读的加密块。第五阶段是加密通道中的交互数据。认证成功后所有包都变成Encrypted packet标记Info列不再显示任何可读信息。如果Wireshark的版本较新有时会显示Ignored packet或Data (encrypted)字样。这阶段你能做的是观察流量模式连接保持活动时会有规律的SSH_MSG_IGNORE或心跳包执行命令时会产生明显的突发流量。把这五个阶段按顺序走一遍你才算真正完成了一次SSH协议分析的完整闭环。对新手来说前面三个阶段是重点——那里面有SSH协议最核心的握手细节也是后面做问题排查时最容易看出异常的环节。3.3 Follow TCP Stream把SSH会话从头看到尾的正确姿势在Wireshark里分析任何TCP协议右键选择Follow TCP Stream都是快速概览会话内容的首选操作。点开之后会弹出一个窗口里面以文本形式展示了整个TCP流的双向数据。但SSH在这里有个大坑因为SSH从密钥交换开始就加密了Follow TCP Stream看到的是一堆乱码和控制字符你根本没法阅读。很多新手第一次点开这个窗口就懵了以为Wireshark坏了或者自己抓包有问题。其实这是完全正常的现象——SSH协议的安全模型要求除了版本协商和KEXINIT之外的一切内容都加密传输Wireshark在没有私钥的情况下无法解密payload它只能把加密后的原始字节流展示给你。但Follow TCP Stream窗口不是没用。SSH连接早期的版本协商文本是明文的你可以在这台窗口的最顶部看到类似SSH-2.0-OpenSSH_7.4的内容这一行足以确认协议版本和软件指纹。再往下还会有KEXINIT消息的明文部分能直接观察到协商前段的算法列表。如果确实需要看加密内容Wireshark提供了解密SSH的功能入口但前提是你持有会话密钥。实际操作中几乎没人会把私钥交给Wireshark——这等于放弃SSH的安全意义。所以对于SSH流量分析正确的心态是接受加密现实把分析重点放在握手阶段和流量模式上而不是死磕payload内容。这跟分析HTTP流量是完全不同的思路及时转换认知能省掉大量无用功。4. SSH握手深度解析三个关键参数的判定与脚本验证4.1 SSH版本字符串与算法协商中容易被忽略的安全信号SSH版本协商阶段虽然只有两条短消息但信息密度极高。客户端和服务端各自发送以SSH-开头的协议标识行Wireshark会把这个字符串解析到ssh.protocol字段。正常情况下一条完整的版本行格式是SSH-协议主版本-软件版本 注释。其中协议主版本对现代SSH来说几乎都是2.0如果你在某次抓包中看到SSH-1.99或SSH-1.5说明对端可能还支持已经被淘汰的SSHv1协议这在安全审计中是一个高危信号。软件软件部分直接暴露SSH实现指纹。比如OpenSSH_7.4说明服务端使用的是Red Hat系LinuxOpenSSH_8.2p1 Ubuntu-4ubuntu0.5则说明是Ubuntu 20.04的发行版。攻击者拿这些指纹去匹配CVE漏洞库就能找到对应的攻击载荷。所以做网络安全加固时有一个常规动作修改sshd_config里的版本字符串让它不暴露真实软件版本。但这里有个前提——这只对防扫描有心理安慰层面的意义真正的安全强度还是取决于密钥算法强度和你是否及时打补丁。算法协商发生在KEXINIT消息中双方各自列出支持的算法清单然后选择双方都支持且优先级最高的组合。在Wireshark的Packet Details里你可以在SSHv2报文里逐个展开key exchange algorithms、encryption algorithms、mac algorithms这三个字段。以我的实战经验值得关注这几个具体项密钥交换算法现代OpenSSH默认支持curve25519-sha256这是目前推荐度最高的算法安全性好且性能开销低。如果清单里出现diffie-hellman-group1-sha1说明老版本兼容性被开启了这在等保测评里可能会被扣分。加密算法看到aes128-ctr或aes256-gcm是可接受的如果只支持aes128-cbc或3des-cbc说明配置有年头了建议升级。MAC算法hmac-sha2-256是常见默认值hmac-md5则属于弱算法不建议保留。4.2 用tshark命令行验证SSH抓包结果的三个命令Wireshark的图形界面做交互分析是利器但做批量验证、提取特征时命令行工具tshark效率更高。tshark是Wireshark套件自带的命令行版本装好Wireshark后直接在终端里输入tshark就能用。我不会把tshark和图形界面对立起来——实际工作中两者配合使用图形界面做精细分析命令行做批量处理和脚本化。先说第一条命令读取pcap文件只看SSH相关包的摘要信息。tshark -r ssh_capture.pcapng -Y tcp.port 22 -T fields -e frame.number -e frame.time_relative -e ip.src -e ip.dst -e ssh.protocol -e tcp.flags.syn这条命令的含义是把ssh_capture.pcapng里的SSH流量提取出来每行输出包序号、相对时间、源IP、目的IP、SSH协议标识和TCP SYN标志。-Y后面跟的是显示过滤器表达式和Wireshark图形界面里写的过滤语法完全一致。运行结果会让你一眼看出整个SSH会话里哪些包是TCP建立连接哪些包真正包含SSH协议内容。第二条命令用于单独提取SSH版本协商的明文内容tshark -r ssh_capture.pcapng -Y ssh.protocol -T fields -e frame.number -e ssh.protocol当Wireshark解析到SSH协议标识时ssh.protocol字段被填充这条命令帮你快速列出每次会话的协议版本和服务器指纹。实际执行时会看到类似SSH-2.0-OpenSSH_7.4的输出这就是前面讲过的版本协商内容。第三条命令查看加密算法协商结果tshark -r ssh_capture.pcapng -Y ssh.msg.kexinit -T fields -e frame.number -e ssh.kex.algorithms -e ssh.encryption.algorithms.client_to_server这里ssh.msg.kexinit过滤出KEXINIT消息然后提取密钥交换算法清单和客户端到服务器的加密算法清单。抓包时如果客户端和服务端的算法清单分别出现在两条不同的KEXINIT消息里这个命令能让你把双方各自支持的算法直接拉到终端进行比较比在图形界面里一个一个展开字段快得多。顺便说一个经验很多人在图形界面里找不到ssh.kex.algorithms这类字段名其实只需在Wireshark的Packet Details里选中想看的字段下方状态栏会显示该字段的完整过滤名。记下图形式界面里的字段名再拿去tshark里用这是提升效率最直接的办法。4.3 时区设置与时间显示分析SSH会话时间线的前提做SSH流量分析时间戳的准确性直接决定你的判断对不对。默认情况下Wireshark的Time列显示的是从抓包开始到每个包的相对时间秒数这在分析单个会话的先后顺序时够用。但如果你需要把Wireshark里的包时间和服务器日志、应用报错时间做关联比对相对时间就不行了必须改成绝对时间。一个极其常见的坑是时区问题。Wireshark的Time列默认以UTC协调世界时显示而我们在国内看日志通常用的是东八区时间。如果你的Windows系统时间已经是北京时间抓到的包里时间戳却是UTC对照服务器本地日志就差出了8小时排查问题时很容易把对应关系搞错。调整方法菜单栏选择View - Time Display Format改成Date and Time of DayWireshark会使用系统本地时间显示。如果发现还是差8小时去Edit - Preferences - Time Display确认格式选项同时检查Windows系统时区设置确实是UTC8 北京。还有一个小细节如果你是通过远程桌面在服务器上打开Wireshark分析抓包文件时间显示会以Wireshark运行所在机器的时区为准而不是抓包机器的时区。这意味着同一份pcap文件在两个时区不同的机器上打开显示的本地时间不同。规范做法是分析报告里统一写清楚时间为Wireshark显示时间已转换为UTC8避免后续交接时说岔了。5. WireShark抓SSH包的5个坑现象根因与排查路径5.1 抓了半天全是TCP包SSH协议字段一个都看不见现象显示过滤器写的是tcp.port 22包确实抓到了一大堆但Packet Details面板里就是找不到SSH协议的字段树所有包都停留在TCP层。原因最常见的两种情况。第一SSH连接还没完成TCP握手就被中断了比如对端端口不通或者防火墙直接丢弃了后续包你看到的只是三次握手或RST包第二Wireshark的协议解析器没有把这段流量识别为SSH这可能是因为SSH版本协商字符串在抓包中被截断或者IP分片导致重组失败。解决先确认你抓到了完整的SSH会话——至少有版本协商的两条文本消息。如果没有回到源头去查TCP三次握手是否完成、是否存在重传或乱序。如果TCP层面正常尝试右键选中会话的第一个数据包选择Decode As手动指定为SSH协议。在交互窗口的列表里找到当前端口对应的协议改成SSH点OK之后Wireshark会重新解析一次。这个方法能救回大部分因协议识别失败而无字段可看的包。5.2 SSH协议版本协商出现了但后面全是Encrypted packet现象能看到SSH-2.0-OpenSSH_7.4这些版本字符串但从KEXINIT开始所有包的Info列都显示Encrypted packet无论怎么点都看不到更多信息。原因这根本不是故障是SSH加密的正常表现。从密钥交换开始SSH会话的所有内容都被加密除非Wireshark持有了会话密钥否则任何工具都看不到明文内容。解决接受这个现实然后把分析视角转移到你能看到的东西上——握手的流程是否正常、KEXINIT的算法组合是否符合预期、认证请求是否成功、加密通道建立后是否有规律的流量模式。很多人在这里卡很久本质上是对SSH协议的加密边界理解不到位误以为Wireshark能像解析HTTP一样解析SSH的内容层。早一天认清这个边界早一天把精力放到有效分析上。5.3 用IP过滤SSH流量结果一条都显示不出来现象过滤条件写的是ip.addr 192.168.1.100 tcp.port 22但结果为空明明刚刚还在用tcp.port 22看到了这个IP的流量。原因ip.addr匹配的是IPv4或IPv6的源或目的地址。如果你的SSH服务监听在IPv6地址上包里的地址是::ffff:192.168.1.100这种IPv4映射地址或者直接的IPv6地址用IPv4地址过滤就匹配不上。另一种可能是Wireshark当前显示窗口里确实没有该IP的流量因为你的过滤表达式本身写在了显示过滤器里而不是捕获过滤器里之前的包根本没有被保留。解决先用tcp.port 22看清流量里到底有哪些IP然后改成ip.src 192.168.1.100 || ip.dst 192.168.1.100分开匹配源和目的。如果你确认流量里有但怎么都过滤不出来打开Statistics - Conversations看看实际参与通信的地址。这条经验同样适用于其他协议——ip.addr不是不能用而是你得先确认地址的地址族和映射方式。5.4 不同机器打开同一个抓包文件时间显示差8小时现象同一份ssh_capture.pcapng文件在自己电脑上打开显示的是北京时间发给同事后他说显示的是凌晨时间两人看到的时间戳差了8个小时。原因Wireshark保存pcap文件时存储的是UTC时间戳显示时按照本机的时区设置换算成本地时间。你本机是UTC8同事的机器如果是UTC时区自然差出8小时。解决在分析文件上和报告里统一约定时区格式。Wireshark里把时间显示格式设为Date and Time of Day后同时在报告的图注或表格标题里标注时区UTC8。如果你经常和跨时区团队协作还有一个进阶做法把时间显示设置为UTC所有沟通都基于UTC时间彻底消除换算歧义。另外如果需要精确对齐服务端日志优先用frame.time字段的绝对UTC时间而不是界面显示的本地化时间。5.5 tshark命令行过滤结果和图形界面不一致现象同样的过滤表达式在Wireshark图形界面里能正常显示结果复制到tshark命令行里运行却一个包都没有或者结果数量对不上。原因两者虽然共用同一套过滤语法但有一个关键差别tshark的命令行参数中-Y后面是整个过滤表达式shell会把它作为一个参数传递。如果表达式里包含空格或管道符|你没有加引号shell会把过滤器拆成多个参数tshark只取到了第一段自然匹配不上。另一个常见原因是tshark直接读pcap文件时用的解析方式和图形界面的默认设置存在细微差别比如某些字段必须在TCP重组完成后才可用。解决在bash或cmd里写tshark命令过滤表达式一律用双引号括起来例如tshark -r file.pcapng -Y tcp.port 22 || ssh。如果图形界面能显示但tshark结果为空先加-V参数打印包的完整字段树找到对应字段实际存在的过滤名列再替换到-Y里重试。这招我在实际使用中解决过不少次诡异不一致的问题。6. 进阶技巧把SSH会话过滤到固定IP并输出分析报告6. 进阶技巧把SSH会话过滤到固定IP并输出分析报告做完前面几步基础分析你已经能掌握SSH会话的全貌了。但实际工作中抓包文件里往往混着大量无关流量——同一台机器上可能有Web请求、DNS查询、后台同步任务它们的包会污染你的分析窗口。把SSH流量精确锁定到固定IP再把关键信息输出成一份简洁报告才是从会抓包走向会分析的分水岭。第一步把抓包范围锁定到固定IP的SSH交互。在显示过滤器里输入ip.addr 192.168.1.100 tcp.port 22如果之前的过滤是tcp.port 22这一步就是把范围缩小到和192.168.1.100这台机器相关的SSH通信。需要注意这条过滤包含双向流量——不仅包含从你本机发往该IP的包也包含该IP回给你的包。如果你只关心某个方向的流量就把ip.addr换成ip.src或ip.dst精确指定方向。第二步用tshark输出固定IP的SSH会话摘要。这个方法适合需要把分析结果存档或者发到工作流工具里的场景tshark -r full_capture.pcapng -Y ip.addr 192.168.1.100 tcp.port 22 -T fields -e frame.number -e frame.time -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e ssh.protocol -e ssh.kex.algorithms ssh_analysis_report.txt这条命令输出每个匹配包的序号、时间、源IP端口、目的IP端口、SSH协议标识和密钥交换算法列表保存为txt或其他格式。执行完打开这个txt你得到的其实是一份结构化程度很高的SSH会话清单配合Excel或Python的pandas库可以做进一步统计分析比如统计每次会话的密钥算法分布、连接持续时间等。第三步验证结果。打开输出文件确认每行的SSH协议字段都正常填充KEXINIT消息对应的算法列表没有空值。如果某些列的字段为空回看-Y过滤条件和那一段的Packet Details找出字段名拼写是否有差异。字段选错时tshark往往不报错只会输出空字符串这一步排查是很多人容易忽略的。这一步的进阶操作是按照四元组提取单条完整的TCP流。在Wireshark的Packet Details里右键任何一个SSH数据包选择Conversation Filter - TCPWireshark会自动把过滤条件切换为同时对源IP、源端口、目的IP、目的端口四个维度做精确匹配。这个操作比手写过滤条件更可靠尤其在多路SSH并发时能准确切出你关注的会话。拿到单条会话后再去翻KEXINIT的算法协商细节、认证包的数量和时间差分析结论的颗粒度会比全量流量下清晰得多。以我的个人习惯做完一次SSH协议分析后会顺手把Wireshark的过滤表达式和tshark命令都复制到自己的笔记里标注上加密区域不可读、只看握手和流量模式的提醒。这个动作帮我避免过很多次反复试错的重复劳动。你如果在自己的环境里跑通了这套流程也应该沉淀一套自己的命令备忘遇到新问题时会发现省下的时间远超当初整理笔记的投入。希望这篇笔记能帮你少走几步弯路把Wireshark的SSH分析从看乱码变成看门道。本文还有配套的精品资源点击获取