![Fedora SSH 客户端在 3 次握手后发送 RST](https://linux22.com/image/228491/Fedora%20SSH%20%E5%AE%A2%E6%88%B7%E7%AB%AF%E5%9C%A8%203%20%E6%AC%A1%E6%8F%A1%E6%89%8B%E5%90%8E%E5%8F%91%E9%80%81%20RST.png)
我有一个运行 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
您有两个环境:{损坏,工作}
$ 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 地址冲突。如果它们相同,则可能仍然是客户端内某种虚拟机/容器网络配置错误。