在一次常规的 SSH 会话抓包实验中，作者观察到一个令人惊讶的现象：按下单个按键竟然产生了近 270 个 IP 包，其中 36 字节的数据报文占 179 个，TCP ACK 占 90 个。这意味着交互式 SSH 会话的包开销远超普通人的直觉预期。理解这一现象的成因，需要从 SSH 协议设计、操作系统 TTY 子系统以及 2023 年引入的安全特性三个层面展开分析。
时序混淆机制：安全加固的代价
SSH 在 2023 年引入了 keystroke timing obfuscation（击键时序混淆）特性。这一设计的初衷是防御流量分析攻击：攻击者可以通过观察网络包的时间间隔，推断用户正在输入的内容。每个人的打字节奏具有独特的个人特征 —— 特定字母组合的输入速度、按键间的自然停顿 —— 这些细微的时序模式可以被机器学习模型识别，从而泄露敏感信息如密码或命令输入。
为了打破这种时序关联性，OpenSSH 实现了一套干扰机制。客户端在发送真实按键数据的同时，会夹杂大量 SSH2_MSG_PING 类型的 "干扰包"（chaff）。这些 ping 包本身不携带业务数据，纯粹用于混淆网络流量的时间特征。值得注意的是，这套机制依赖服务器端的配合 —— 只有当服务器在密钥交换阶段 advertise 了 ping@openssh.com 扩展时，客户端才会启用时序混淆功能。
从量化角度看，这种混淆带来的开销相当可观。单次按键产生约 100 个数据报文意味着，在高频率交互场景下，网络带宽的相当比例被非业务流量占据。对于普通终端用户而言，这可能只是带宽预算中的可忽略噪声；但对于需要同时维护数千个并发 SSH 会话的场景 —— 例如 2000 个玩家同时通过终端连接游戏服务器，每秒 10 帧更新、每次 80x60 字符显示 —— 按键包的累积开销将成为系统的主要带宽消耗来源。
协议层的报文交互链路
撇开时序混淆特性，SSH 交互式会话本身的协议设计也会产生多轮包交换。当用户在终端按下字母 'a' 时，整个交互流程涉及至少三类报文：客户端发送到服务器的加密按键数据、服务器回传的 ACK 确认、以及服务器将字符回显到客户端的响应报文。
在典型的 TCP_NODELAY 配置下，每个按键字符都会被立即发送，而不会等待 Nagle 算法的 200 毫秒合并窗口。服务器端收到加密报文后，需要完成解密、写入伪终端（PTY）、等待 shell 或应用程序处理、最后将回显内容加密发回客户端。这一来一回的过程在网络层面体现为多个 IP 包的序列，每个包都带有自身的 TCP 头、IP 头以及 SSH 协议开销。即使没有时序混淆，交互式 SSH 的单字符延迟也主要由往返时程（RTT）和协议栈处理开销决定。
值得注意的是，36 字节是实验中观察到的典型 SSH 消息长度。这包含了 1 字节的真实字符数据、填充至块密码对齐边界的 padding、以及 SSH 协议头字段如消息类型码和序列号。对于使用块加密算法（如 AES 或 ChaCha20-Poly1305）的 SSH 连接，每个包还需要额外的认证标签开销，进一步放大了小报文的相对传输成本。
安全与性能的工程权衡
关闭时序混淆是降低包开销的直接手段。通过在 ssh_config 中添加 ObscureKeystrokeTiming=no，或者确保服务器端不 advertise ping@openssh.com 扩展，可以完全禁用这一特性。然而，这一选择需要放在具体的威胁模型下评估。对于通过公共网络访问敏感系统的场景，保留时序混淆可以有效防御流量分析攻击；对于隔离内网环境中的运维终端，关闭混淆可能是一个合理的性能优化。
Berkeley 研究团队在 2004 年发表的经典论文揭示了 SSH 时序泄露的严重性。他们开发的 Herbivore 攻击系统通过监控 SSH 会话的包时间间隔，利用隐马尔可夫模型预测用户输入。实验结果表明，这种攻击可以将密码暴力搜索的效率提升 50 倍。这一研究直接推动了后续 SSH 版本引入时序混淆作为默认安全强化措施。因此，是否禁用混淆的决策，本质上是安全团队与性能团队之间的风险权衡。
对于真正对延迟和带宽敏感的高频场景 —— 如在线游戏终端、大规模集群管理接口 —— 或许需要考虑超越传统 SSH 协议的定制方案。设计专用的二进制协议，在连接建立阶段协商更激进的压缩策略、合并多个按键的批量传输、或采用更高效的帧结构，都可能带来数量级的性能提升。当然，这需要以丧失 SSH 提供的标准化安全特性为代价。
资料来源：Hacker News 讨论（2026-01-22）、UC Berkeley 时序攻击研究论文（2004 年）。