packet_write_wait 管道损坏甚至让 top 继续运行？

Question 1

亲爱的2018年及以后的读者，

让我向您展示 MelBurslan 的评论，

如果您处于企业环境中，请咨询您的防火墙管理员，看看他们是否在发生这种情况时更新规则和/或在进行某种更改后重新启动防火墙。如果您的个人服务器发生这种情况，您需要提供有关发生这种情况时您在 sshd 服务器端执行的操作的更多信息。管道损坏通常意味着由于某种原因网络断开。

基本上，如果您尝试通过 VPN（企业环境）使用。那么这个错误一定会一遍又一遍地伴随着你。ssh [email protected]

唯一的解决办法我发现到目前为止是手机外壳。感谢创造它的人。

您需要mosh-server在目标（您想要通过 ssh 连接到的服务器）和mosh-client主机中进行安装。

当你的数据包丢失时，它会自动重新连接，我认为这非常酷并且适合我们所有的需求。

更新 03/2020：

如果您无法mosh-server在服务器上安装，那么您可以在此处使用我的脚本：https://github.com/ohmybash/oh-my-bash/blob/master/tools/autossh.sh

当 SSH 会话失效时，它会自动重新连接到 SSH。

快乐的 ssh'ing！

Answer

亲爱的2018年及以后的读者，

让我向您展示 MelBurslan 的评论，

如果您处于企业环境中，请咨询您的防火墙管理员，看看他们是否在发生这种情况时更新规则和/或在进行某种更改后重新启动防火墙。如果您的个人服务器发生这种情况，您需要提供有关发生这种情况时您在 sshd 服务器端执行的操作的更多信息。管道损坏通常意味着由于某种原因网络断开。

基本上，如果您尝试通过 VPN（企业环境）使用。那么这个错误一定会一遍又一遍地伴随着你。ssh [email protected]

唯一的解决办法我发现到目前为止是手机外壳。感谢创造它的人。

您需要mosh-server在目标（您想要通过 ssh 连接到的服务器）和mosh-client主机中进行安装。

当你的数据包丢失时，它会自动重新连接，我认为这非常酷并且适合我们所有的需求。

更新 03/2020：

如果您无法mosh-server在服务器上安装，那么您可以在此处使用我的脚本：https://github.com/ohmybash/oh-my-bash/blob/master/tools/autossh.sh

当 SSH 会话失效时，它会自动重新连接到 SSH。

快乐的 ssh'ing！

Question 2

我发现这是我的 VMware Guest 设置中的 IPQoS 选项问题。在 VM 上，我将 IPQoS 的 ~/.ssh/config 值设置为默认值“IPQoS af21 cs1”，首先是交互式的低延迟数据，其次是非交互式的较低工作量。为 af21 设置新值是我的解决方案：

Host *
     IPQoS throughput

对我有用，否则 MoSH 也可以工作，但是 mosh 不能以方便的方式处理我的代理设置，所以我坚持使用 ProxyJump 命令

Answer

我发现这是我的 VMware Guest 设置中的 IPQoS 选项问题。在 VM 上，我将 IPQoS 的 ~/.ssh/config 值设置为默认值“IPQoS af21 cs1”，首先是交互式的低延迟数据，其次是非交互式的较低工作量。为 af21 设置新值是我的解决方案：

Host *
     IPQoS throughput

对我有用，否则 MoSH 也可以工作，但是 mosh 不能以方便的方式处理我的代理设置，所以我坚持使用 ProxyJump 命令

Question 3

首先，请确保您的问题与以下内容无关这个。

如果不是并且问题仍然存在，请继续阅读。

我也遇到过这个问题，花了几天时间试图解决它。

如指定的那样，使用 SSH KeepAlive 参数或内核 TCP 参数（TCPKeepAlive 开/关）并不能解决问题。

在使用 USB 转以太网驱动程序和 TCP 转储之后，我意识到问题是由于内核 4.8 造成的。我将源（发送端）切换到 4.4 LTS，问题消失了（rsync、scp 再次正常工作）。如果您愿意，目标端可以保留在 4.8 上，在我的用例中这是有效的（经过测试）。

在技术方面，借助我制作的wireshark转储，我们可以稍微缩小问题范围。我们可以看到 SSHv2 协议的 TCP 通道正在重置（TCP 的 RST 标志设置为 1），导致连接中止。我还不知道RST的原因。为此，我需要从 4.8.1 到 4.8.11 进行一些平分。

我并不是说你的问题具体是由于内核 4.8 引起的，而是 wrt。在您发布问题/消息的日期，您可能一直在使用实际上有错误的内核版本。

最初回答于堆栈溢出。

Answer

首先，请确保您的问题与以下内容无关这个。

如果不是并且问题仍然存在，请继续阅读。

我也遇到过这个问题，花了几天时间试图解决它。

如指定的那样，使用 SSH KeepAlive 参数或内核 TCP 参数（TCPKeepAlive 开/关）并不能解决问题。

在使用 USB 转以太网驱动程序和 TCP 转储之后，我意识到问题是由于内核 4.8 造成的。我将源（发送端）切换到 4.4 LTS，问题消失了（rsync、scp 再次正常工作）。如果您愿意，目标端可以保留在 4.8 上，在我的用例中这是有效的（经过测试）。

在技术方面，借助我制作的wireshark转储，我们可以稍微缩小问题范围。我们可以看到 SSHv2 协议的 TCP 通道正在重置（TCP 的 RST 标志设置为 1），导致连接中止。我还不知道RST的原因。为此，我需要从 4.8.1 到 4.8.11 进行一些平分。

我并不是说你的问题具体是由于内核 4.8 引起的，而是 wrt。在您发布问题/消息的日期，您可能一直在使用实际上有错误的内核版本。

最初回答于堆栈溢出。

Question 4

实际上我找到了问题的解决方案，请检查您的 Linux 用户是否映射到您的 SELinux 用户。

让我解释一下，默认情况下，在 linux 上创建的所有用户都具有相同的 unconfined_u SElinux 用户上下文，这意味着普通 linux 用户能够执行 root 所做的操作，Linux 用户到 SElinux 用户之间的显式更改或映射可能会阻止 ssh 正常工作。

场景：你在这里创建普通的 Linux 用户 用户添加-m USER1

USER1现在是一个普通的Linux用户，默认情况下这个linux用户USER1被映射到SElinux unconfined_u USER1，并且默认情况下所有创建的用户都将在SElinux unconfined_u下，甚至root用户使用此命令检查 管理登录-l

当您决定将普通 linux USER1 映射到 SElinux sysadm_u 用户时，您将无法 ssh 到 USER1。 Semanage登录-m -s sysadm_u -r s0 USER1

USER1 现在映射到 SELinux sysadm_u 用户，这阻止了我使用 SSH 实用程序

如何解决这个问题？好吧，尝试将linux用户“USER1”映射到SELinux用户“user_u”，这实际上可以解决问题

不将用户映射到 SElinux sysadm_u

Answer