SSH客户端执行命令时遇意外服务器响应及包格式异常问题咨询

核心问题根源 #

你遇到的异常直接关联服务器返回的窗口大小为0——这是SSH流量控制的关键信号：窗口大小为0意味着服务器当前没有可用缓冲区接收通道数据，此时你不能直接发送whoami命令请求，必须等待服务器发送SSH_MSG_CHANNEL_WINDOW_ADJUST包扩大窗口后，才能发送命令。

你的操作顺序违反了SSH的流量控制规则，导致服务器返回异常数据包，同时你的解析逻辑可能未正确拆分连续数据包，进一步引发长度、填充字段的解析错误。

额外数据的成因 #

你看到的“额外数据”大概率是多个SSH数据包被错误合并解析的结果：

• 服务器在你违规发送命令后，先返回SSH_MSG_CHANNEL_WINDOW_ADJUST包，紧接着返回命令执行的输出包（或其他响应包）。
• 你未按照SSH包结构严格拆分数据，把两个独立的数据包当成一个来解析，就会出现“长度字段为1c但实际接收字节数远超此值”“填充长度12仍有额外数据”的情况。

修正步骤 #

1. 遵守流量控制逻辑

   • 收到通道打开确认后，检查返回的窗口大小：
     • 如果窗口大小为0，暂停发送命令，等待服务器发送SSH_MSG_CHANNEL_WINDOW_ADJUST包，更新本地记录的窗口大小后，再发送exec类型的SSH_MSG_CHANNEL_REQUEST请求（携带whoami命令）。
     • 如果窗口大小>0，可直接发送命令，但后续也要根据窗口调整包动态更新可用窗口大小。

2. 严格按照SSH包结构解析数据
   SSH每个数据包的结构固定为：

   4字节长度字段 + 1字节填充长度 + 有效载荷 + 填充数据
   

   解析时必须按以下步骤执行：

   • 先读取4字节，转换为整数得到整个包的总长度（不含长度字段本身）。
   • 读取1字节得到填充长度。
   • 读取总长度 - 1 - 填充长度字节作为有效载荷。
   • 跳过填充长度字节的填充数据，完成当前包的解析，再处理下一个包。

3. 验证命令请求包的正确性
   确保发送的exec请求包格式正确：

   • 包类型为SSH_MSG_CHANNEL_REQUEST
   • 包含通道ID、请求类型字符串exec、want_reply标志（通常设为1）、命令字符串whoami

内容的提问来源于stack exchange，提问作者Ruben Boero