Hotdry.
归档
systems

SSH 每次按键的包开销与交互模式优化参数

拆解 OpenSSH 交互模式下每次按键触发的包链：客户端发送、服务器回显、chaff 混淆包的叠加效应，并给出 chrpress 与 timing obfuscation 的配置阈值。

在 Hacker News 上看到一个有趣的问题：为什么 SSH 每次按键要发 100 个包？这个数字看起来很惊人，但背后涉及到 SSH 交互模式的协议设计、时序混淆机制以及网络层的叠加效应。理解这些机制不仅能解答这个疑问，还能帮助你在高延迟网络中针对性地调优 SSH 配置。

交互模式的包触发链

SSH 在交互式终端会话中的行为与传统批量传输完全不同。当你按下键盘上的一个键时，这个按键不是被缓冲到行尾再发送，而是立即被打包传输。这种设计有几个关键原因：服务器需要立即知道用户按下了什么键，以便在本地终端模拟器中处理（比如控制字符、转义序列）；交互式应用如 vim、tmux、数据库客户端依赖即时反馈；同时这也是实现全双工通信的基础架构。

一次按键触发的完整包链大致如下：首先是客户端发送的按键数据包，包含加密后的单个字符或转义序列，这通常是一个 SSH_MSG_CHANNEL_DATA 包；服务器收到后，通过 SSH_MSG_CHANNEL_DATA 将按键回显给客户端（如果终端设置为回显模式），客户端终端模拟器负责在屏幕上渲染这个字符；最后服务器可能发送窗口更新包（SSH_MSG_CHANNEL_WINDOW_ADJUST）以调整流量控制窗口。这是最基础的 2 到 3 个包往返。

时序混淆与 Chaff 包的叠加

从 OpenSSH 9.5 版本开始，为了缓解时序攻击，客户端引入了 keystroke timing obfuscation 机制。这个功能会在真实的按键包之间插入伪造的流量，使得外部观察者无法通过包间隔推断用户的输入节奏。默认情况下，OpenSSH 每 20 毫秒发送一个 chaff 包（SSH2_MSG_PING 或 SSH2_MSG_PONG），这些包看起来和真实的按键包大小相近，但在协议层面是空负载的占位包。

这就解释了为什么用户感知到的包数量会翻倍。在没有混淆时，一次按键可能只产生 2 到 3 个有效包；但启用了时序混淆后，20 毫秒窗口内可能叠加多个 chaff 包。如果你以较快的速度连续输入，比如每秒 5 到 10 个字符，那么每个真实按键包前后都可能跟随 1 到 2 个混淆包，包计数器自然就上去了。需要注意的是，chaff 包的密度是可配置的，参数 ServerAliveInterval 和 TCPKeepAlive 也会引入额外的保活包。

Chrpress 字符预测与压缩开销

chrpress 是 OpenSSH 的字符预测压缩功能缩写（Character Prediction Press），它通过预测用户即将输入的字符来减少实际传输的字节数。比如当你输入常见命令的前几个字母时，客户端可能已经猜到了完整单词，只传输差异部分。这在带宽受限的环境中能显著降低流量，但并不会减少包的数量 —— 它改变的是每个包的负载大小。

chrpress 的开销主要体现在计算侧：客户端需要维护一个基于历史输入的预测模型，服务器收到部分字符后需要推断完整内容。这个机制在本地网络或低延迟环境中效果有限，反而会因为额外的编解码开销增加 CPU 占用。对于高延迟链路（如跨洲际卫星链路），chrpress 能节省 30% 到 50% 的按键数据传输量，但代价是每次按键的端到端延迟增加 5 到 15 毫秒用于预测计算。

配置参数与工程决策

如果你的使用场景对包数量敏感（比如在极度受限的物联网链路上），可以通过以下参数调优。首先是禁用时序混淆，在 ssh_config 中设置 SetEnv "SSH_OBFUSCATE_TIMING=0"，或者命令行参数 -o ObfuscateTiming=no，这样每次按键只产生真实的功能包，不会插入 chaff 包，但会重新暴露时序攻击面。其次是调整 chrpress 行为，通过 SetEnv "SSH_CHRPRESS=0" 关闭字符预测，适合对延迟敏感而非带宽敏感的场景。

对于需要穿越代理或 VPN 的场景，保活包的配置会引入额外开销。ServerAliveInterval 60 会每 60 秒发送一次存活探测包，ServerAliveCountMax 3 定义了连续无响应后断开连接的阈值。如果你通过 HTTP/SOCKS 代理使用 SSH，代理层的连接管理也会引入自己的心跳包，这些通常无法通过 SSH 配置直接关闭，需要在代理侧调整或选择支持更少保活信号的代理协议。

监控与边界条件

判断当前 SSH 会话的包开销，最直接的方法是在本地或网关使用抓包工具（如 tcpdump 或 wireshark）过滤 SSH 流量，统计每秒的包数量。一个正常的交互式会话在启用时序混淆的情况下，包率大约在每秒 40 到 80 个（取决于输入速度）；禁用混淆后下降到每秒 15 到 30 个。如果你的会话持续显示每秒上百个包，检查是否有脚本或自动化工具在频繁发送命令，或者终端模拟器配置了异常的自动补全触发机制。

在工程实践中，如果你运维的 SSH 网关需要服务大量并发用户，包率是性能监控的重要指标。OpenSSH 的 MaxSessions 和 MaxStartups 参数限制并发连接数，但包率取决于用户的实际输入行为。高包率不仅消耗网络带宽，还会增加加密处理的 CPU 开销。对于面向公众的 SSH 入口，考虑启用时序混淆以提升安全性；对于内部运维网络，可以根据威胁模型选择关闭混淆以换取更低的资源消耗。

参考资料

查看归档