☰

为什么 SSH/SFTP 对于返回值较大的命令会失败？

tag-icon • tag-icon linux networking ssh sftp
为什么 SSH/SFTP 对于返回值较大的命令会失败？

我们有一个 SFTP 服务器，在我们添加另一个 ISP 之前，它一直运行良好。我向 确认，与 SFTP 服务器的连接不会通过新 ISP tracert。服务器上也没有发生任何变化。但从那时起，如果执行的命令有较大的返回值，某些用户的 SFTP 或 SSH 连接会超时/挂起。以下是场景：

  1. 我可以继续 ping 并且即使 SSH/SFTP 超时，ping 也总会返回
  2. 我可以连接到服务器，它要求身份验证并允许我登录。
  3. 如果ls我的根目录的命令返回少量文件或文件夹，则它会显示文件和文件夹的列表
  4. 如果ls我的根目录的命令大于 5 或​​ 6 个文件或文件夹，那么它就会挂起/超时。
  5. 在尝试此操作时，我尝试对服务器进行 ping，并且它一直在返回。

  6. 这种情况不会发生在每个人身上，但似乎发生在另一个城市的用户身上。

  7. 我尝试了不同的 SFTP 客户端（FileZilla 和 WinSCP）。两者都有同样的问题。

我在我的电脑上运行了 WireShark（它在我们的网络之外，也在城市之外），当 SFTP/SSH 超时时，我看到重新传输和部分段未捕获错误出现，这让我相信在跳跃之间可能存在一些数据包丢失。

Expert Info (Note/Sequence): Retransmission (suspected)
Previous segment not captured (common at capture start)

SFTP/SSH 对数据包丢失如此敏感吗？SSH/SFTP 不会重新传输/重新确认以避免这些数据包丢失错误吗？我可以调整服务器设置以使其正常工作吗？

答案1

我认为评论者说到了点子上，这是一个典型的 MTU 问题（路径 MTU 无法正确检测发生故障的特定路径所需的较小 MTU）。您应该检查发生故障的路径中的中间设备是否正确允许 MTU 路径发现数据包通过，并且没有任何中间路由器具有不必要的较小 MTU。您可以通过向沿途的每一跳发送最大为 MTU 大小的大型 icmp 数据包来缩小范围，以发现故障位置（尽管这并不总是有效）。

相关内容