☰

Fedora SSH 客户端在 3 次握手后发送 RST

tag-icon • tag-icon debian ssh fedora openssh oh-my-zsh
Fedora SSH 客户端在 3 次握手后发送 RST

我有一个运行 Fedora 38 和 OpenSSH_9.0p1、OpenSSL 3.0.9 2023 年 5 月 30 日的客户端。服务器是运行 Debian 11.8 Bulleye 的旧 Buffalo NAS，它有 OpenSSH_8.4p1 Debian-5+deb11u3 和 OpenSSL 1.1.1w 2023 年 9 月 11 日。

ssh 连接在挂起后超时 debug3: set_sock_tos: set socket 3 IP_TOS 0x48。在 Wireshark 中，我看到客户端发起 SYN，服务器发送 SYN-ACK，然后服务器发送 ACK，然后立即发送 RST。

74446   6348.950713461  192.168.8.198   192.168.8.174   TCP 74  44446 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=3749347152 TSecr=0 WS=128
74447   6348.952546002  192.168.8.174   192.168.8.198   TCP 74  22 → 44446 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2278029303 TSecr=3749347152 WS=16
74448   6348.952595078  192.168.8.198   192.168.8.174   TCP 66  44446 → 22 [ACK] Seq=1 Ack=1 Win=32128 Len=0 TSval=3749347154 TSecr=2278029303
74449   6348.952616726  192.168.8.198   192.168.8.174   TCP 66  44446 → 22 [RST, ACK] Seq=1 Ack=1 Win=32128 Len=0 TSval=3749347154 TSecr=2278029303
74453   6353.268747244  192.168.8.198   198.168.8.174   TCP 74  38366 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=4212327032 TSecr=0 WS=128
74459   6354.283146552  192.168.8.198   198.168.8.174   TCP 74  [TCP Retransmission] 38366 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=4212328047 TSecr=0 WS=128
74460   6355.307183990  192.168.8.198   198.168.8.174   TCP 74  [TCP Retransmission] 38366 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=4212329071 TSecr=0 WS=128

我可以从另一个客户端连接，猜测版本不兼容。

我尝试过但没有成功的是设置 update-crypto-policies --set LEGACY 和 update-crypto-policies --set DEFAULT:FEDORA32

但是，如果存在某种加密不兼容问题，我希望得到更清晰的错误消息。是什么导致客户端重置连接而不是发送其协议版本？我怎样才能解决这个问题？

PS 事实证明，当我在 Fedora 客户端上以 root 身份时，连接成功。知道缺少什么吗？

更新1：这是带有 root 的...看起来应该如此。

123 49.011405139    192.168.8.198   192.168.8.174   TCP 74  58228 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=3787055761 TSecr=0 WS=128
124 49.014421022    192.168.8.174   192.168.8.198   TCP 74  22 → 58228 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2362587143 TSecr=3787055761 WS=16
125 49.014450365    192.168.8.198   192.168.8.174   TCP 66  58228 → 22 [ACK] Seq=1 Ack=1 Win=32128 Len=0 TSval=3787055767 TSecr=2362587143
126 49.014630252    192.168.8.198   192.168.8.174   SSHv2   87  Client: Protocol (SSH-2.0-OpenSSH_9.0)
127 49.016417357    192.168.8.174   192.168.8.198   TCP 66  22 → 58228 [ACK] Seq=1 Ack=22 Win=65152 Len=0 TSval=2362587145 TSecr=3787055767
128 49.616114970    192.168.8.174   192.168.8.198   SSHv2   106 Server: Protocol (SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3)
129 49.616195199    192.168.8.198   192.168.8.174   TCP 66  58228 → 22 [ACK] Seq=22 Ack=41 Win=32128 Len=0 TSval=3787056369 TSecr=2362587700
130 49.617586438    192.168.8.198   192.168.8.174   SSHv2   1426    Client: Key Exchange Init
131 49.618658862    192.168.8.174   192.168.8.198   SSHv2   1146    Server: Key Exchange Init
...

更新2：事实证明，除了我经常使用的用户之外，它适用于所有用户。另外 sudo ssh 对这一用户不起作用。我移动了该用户的整个.ssh文件夹来测试，没有效果。还有什么会影响特定用户的 ssh？ $HOME 变量应该有两个不同的值，导致使用不同的点文件配置。比较那些。

更新3：它似乎与 Oh My Zsh 有关：当我移动 zshrc 并打开一个新会话时发现它起作用了。卸载了哦我的 zsh - 有效。重新安装它并使用默认的 zshrc - 不起作用。清空插件（） - 不起作用。注释掉源 oh-my-zsh.sh - 有效。 oh my zsh 到底能在这里发挥什么作用呢？

更新4：这样做修复了它。在多次重新启动、更新到 Fedora 39、试验多天的过程中，错误仍然存​​在。现在，在摆弄 .zshrc 之后，错误消失了，不知道为什么。

答案1

您向我们展示了临时端口 44446 正在尝试连接。当您是 root 时，当尝试来自低编号端口时，它可能会成功。即小于 1024。

您有两个环境：{损坏，工作}

$ which ssh比较两者的输出，验证它们是否相等。

$ ssh -v ...比较两者之间的输出，看看无特权的“破坏”有多远。

用来$ type ssh说服自己这中间没有一些疯狂的别名来误导我们。

比较env | sort两个环境之间的输出。您已经检查了 PATH，因此我们正在寻找 LD_LIBRARY_PATH 或手册页上提到的 SSH_USE_STRONG_RNG 等内容。比较$ ldd /usr/bin/ssh。我们想要验证非特权用户是否有权读取所有相关的共享对象。

$HOME 变量应该有两个不同的值，导致使用不同的点文件配置。比较那些。

答案2

请注意，服务器发送 SYN-ACK 后，就轮到客户端发送 ACK...这就是实际发生的情况，但是随后客户端显然还发送了 RST-ACK。

您确定客户端没有 IP 地址冲突吗？也就是说，您的 Fedora 客户端 192.168.8.198 发起连接，服务器响应，但当您的客户端使用 ACK 完成 TCP 三向握手时，也许其他一些系统或虚拟机还配置了 IP 192.168.8.198 会产生 RST 响应吗？

在这么早的时候，这不可能是 SSH 协议协商问题，因为任一方向尚未交换数据。

您应该比较第一个转储中的 ACK 和 RST-ACK 数据包的 MAC 地址。如果它们不同，则您的客户端系统显然存在 IP 地址冲突。如果它们相同，则可能仍然是客户端内某种虚拟机/容器网络配置错误。

相关内容