AsyncSSH 项目中的 SFTP 大文件传输问题分析与解决方案

问题背景

在 AsyncSSH 项目中，用户在使用 SFTP 协议传输大文件（4GB 以上）时遇到了连接中断的问题。最初怀疑是内存耗尽导致，但经过深入分析发现实际原因是 SSH 密钥重新协商（rekey）过程中的兼容性问题。

技术分析

1. 大文件传输机制

AsyncSSH 的 SFTP 实现采用流式传输机制，默认情况下：

• 使用 16KB 的块大小
• 最大并行请求数为 128
• 每个文件传输仅需约 2MB 内存缓冲区

在 AsyncSSH 2.18.0 及以上版本中，如果服务器支持"limit"扩展并通告更大的读写大小，默认缓冲区可能会增加到约 512MB。用户可以通过调整 block_size 和 max_requests 参数来优化内存使用。

2. 密钥重新协商问题

深入分析发现，真正的故障发生在传输约 1GB 数据后的密钥重新协商过程中。调试日志显示：

1. 客户端发送 MSG_KEX_ECDH_INIT 消息
2. 服务器未响应预期的 MSG_KEX_ECDH_REPLY
3. 连接最终因 keepalive 超时而中断

3. Terrapin 攻击防护的影响

进一步调查发现，这与 SSH 协议为防范 Terrapin 攻击引入的"strict kex"扩展有关。服务器实现（基于 Nsoftware 库）在重新协商期间：

• 严格执行"strict kex"规则
• 拒绝处理任何非预期的数据包（包括 SSH_MSG_IGNORE）
• 导致连接挂起

解决方案

AsyncSSH 项目维护者提出了两个修复方案：

方案一：全面限制协商期间的数据包发送

# 修改连接处理逻辑
if (((pkttype in {MSG_DEBUG, MSG_SERVICE_REQUEST, MSG_SERVICE_ACCEPT} or
      pkttype > MSG_KEX_LAST) and not self._kex_complete) or
        (pkttype == MSG_USERAUTH_BANNER and
         not (self._auth_in_progress or self._auth_complete)) or
        (pkttype > MSG_USERAUTH_LAST and not self._auth_complete)):
    raise ProtocolError('Packet sent at wrong time')

方案二：优化 IGNORE 数据包发送策略

# 仅在加密且数据包类型大于 KEX_LAST 时发送 IGNORE
if self._send_encryption and pkttype > MSG_KEX_LAST:
    self.send_packet(MSG_IGNORE, String(b''))

最终采用了更简洁的方案二，该方案：

1. 避免在密钥交换期间发送不必要的 IGNORE 数据包
2. 保持与严格服务器的兼容性
3. 不影响正常的安全协商过程

技术讨论

值得注意的是，OpenSSH 的 strict-kex 规范明确指出限制仅适用于初始密钥交换（initial KEX），而不应适用于重新协商（rekeying）。这表明服务器实现可能存在过度严格的问题。

尽管如此，AsyncSSH 仍选择通过客户端调整来解决问题，体现了优秀的兼容性设计理念。该修复已并入 AsyncSSH 2.20.0 版本。

最佳实践建议

对于开发者使用 AsyncSSH 进行大文件传输：

1. 对于超大文件（>4GB），适当调整块大小和并行请求数
2. 监控密钥重新协商过程，特别是传输约 1GB 数据时
3. 保持 AsyncSSH 版本更新（建议 2.20.0 及以上）
4. 在兼容性要求高的场景，可考虑禁用 strict-kex（需评估安全风险）

该案例展示了开源社区协作解决复杂技术问题的典型过程，从问题报告、技术分析到方案验证和最终修复，体现了开源项目的响应能力和专业精神。