我已经使用 Debian 9 SSH Jumpbox 主机来运行我的脚本/ansible playbook 一段时间了。 Jumbox 主要与 Debian 9 和一些 Debian 8 服务器通信。大多数服务器是在 VMWare Enterprise 5.5 下运行的虚拟机。
Jumbox 中的 SSH 客户端配置为执行 SSH MUX，并且通过 RSA 证书文件完成身份验证。
SSH 多年来一直运行良好，但是突然 SSH 连接ssh_exchange_identification: read: Connection reset by peer在第一次尝试时就开始给出错误，一天好几次，这显然对我的脚本和我们开发团队的脚本造成了严重破坏。
然而，第一次尝试后，他们在一段时间内还可以。服务器的错误行为起初似乎是随机的，但有一些模式/超时。如果我确实向所有服务器发送命令，例如，在预期脚本/剧本之前运行命令，则一些服务器会失败，但下一个脚本将在所有服务器中运行。
除了安全更新外，服务器最近没有发生重大变化。 Debian 9 的过渡已经有一段时间了。
我已经发现 MTU（错误）配置或其他配置曾经应用于发生故障的多台服务器并被遗忘，但事实并非如此。我还将客户端和服务器端的ControlPersist时间都减少ClientAliveInterval到 1 小时，但这并没有改善情况。
所以目前，我不知道为什么会发生这种情况。不过，我更倾向于认为这是第 7 层问题，而不是网络问题。
Debian 9客户端的 SSH 配置/etc/ssh_config是：
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r
ControlPersist 1h
Compression no
UseRoaming no
在多个 Debian 服务器的服务器端的 SSH 上：
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin forced-commands-only
StrictModes yes
PubkeyAuthentication yes
IgnoreRhosts yes
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server -l INFO
UsePAM yes
ClientAliveInterval 3600
ClientAliveCountMax 0
AddressFamily inet
SSH 版本：
客户 -
$ssh -V
OpenSSH_7.4p1 Debian-10+deb9u1, OpenSSL 1.0.2l 25 May 2017
服务器
SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u1 (Debian 9)
SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 (Debian 8)
我至少在两台具有 4.9.0-0.bpo.1-amd64 版本的服务器的情况下看到过该错误。
下面是tcpdump服务器行为异常的情况，两台机器位于同一网络中，中间没有任何防火墙。我还监控 MAC 地址，并且在过去几年中没有记录具有相同 MAC 地址的新机器/MAC。
#tcpdump port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:42:25.462896 IP jumbox.40270 > server.ssh: Flags [S], seq 3882361678, win 23200, options [mss 1160,sackOK,TS val 354223428 ecr 0,nop,wscale 7], length 0
19:42:25.463289 IP server.ssh > jumbox.40270: Flags [S.], seq 405921081, ack 3882361679, win 23200, options [mss 1160,nop,nop,sackOK,nop,wscale 7], length 0
19:42:25.463306 IP jumbox.40270 > server.ssh: Flags [.], ack 1, win 182, length 0
19:42:25.481470 IP server.ssh > jumbox.40270: Flags [S.], seq 4195986320, ack 3882361679, win 23200, options [mss 1160,nop,nop,sackOK,nop,wscale 7], length 0
19:42:25.481477 IP jumbox.40270 > server.ssh: Flags [.], ack 504902058, win 182, length 0
19:42:25.481490 IP server.ssh > jumbox.40270: Flags [R], seq 405921082, win 0, length 0
19:42:25.481494 IP server.ssh > jumbox.40270: Flags [P.], seq 504902058:504902097, ack 1, win 182, length 39
19:42:26.491536 IP server.ssh > jumbox.40270: Flags [S.], seq 4195986320, ack 3882361679, win 23200, options [mss 1160,nop,nop,sackOK,nop,wscale 7], length 0
19:42:26.491551 IP jumbox.40270 > server.ssh: Flags [R], seq 3882361679, win 0, length 0
19:42:28.507528 IP server.ssh > jumbox.40270: Flags [S.], seq 4195986320, ack 3882361679, win 23200, options [mss 1160,nop,nop,sackOK,nop,wscale 7], length 0
19:42:28.507552 IP jumbox.40270 > server.ssh: Flags [R], seq 3882361679, win 0, length 0
19:42:32.699540 IP server.ssh > jumbox.40270: Flags [S.], seq 4195986320, ack 3882361679, win 23200, options [mss 1160,nop,nop,sackOK,nop,wscale 7], length 0
19:42:32.699556 IP jumbox.40270 > server.ssh: Flags [R], seq 3882361679, win 0, length 0
19:42:40.891490 IP server.ssh > jumbox.40270: Flags [S.], seq 4195986320, ack 3882361679, win 23200, options [mss 1160,nop,nop,sackOK,nop,wscale 7], length 0
19:42:40.891514 IP jumbox.40270 > server.ssh: Flags [R], seq 3882361679, win 0, length 0
19:42:57.019511 IP server.ssh > jumbox.40270: Flags [S.], seq 4195986320, ack 3882361679, win 23200, options [mss 1160,nop,nop,sackOK,nop,wscale 7], length 0
19:42:57.019534 IP jumbox.40270 > server.ssh: Flags [R], seq 3882361679, win 0, length 0
ssh -v server连接失败的日志，带有重置错误：
OpenSSH_7.4p1 Debian-10+deb9u1, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: /etc/ssh/ssh_config line 59: Deprecated option "useroaming"
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/ssh_mux_fenix-storage_22_rui" does not exist
debug1: Connecting to fenix-storage [10.10.32.156] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
write: Connection reset by peer
ssh -v server连接成功的情况：
OpenSSH_7.4p1 Debian-10+deb9u1, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: /etc/ssh/ssh_config line 59: Deprecated option "useroaming"
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/ssh_mux_sql01_22_rui" does not exist
debug1: Connecting to sql01 [10.20.10.88] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rui/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u1
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to sql01:22 as 'rui'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:6aJ+ipXRZJfbei5YbYtvqKXB01t1YO34O2ChdT/vk/4
debug1: Host 'sql01' is known and matches the RSA host key.
debug1: Found key in /home/rui/.ssh/known_hosts:315
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/rui/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
Authenticated to sql01 ([10.20.10.88]:22).
debug1: setting up multiplex master socket
debug1: channel 0: new [/tmp/ssh_mux_sql01_22_rui]
debug1: control_persist_detach: backgrounding master process
debug1: forking to background
debug1: Entering interactive session.
debug1: pledge: id
debug1: multiplexing control connection
debug1: channel 1: new [mux-control]
debug1: channel 2: new [client-session]
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.utf8
debug1: Sending env LANG = en_US.UTF-8
debug1: mux_client_request_session: master session id: 2
有趣的是，可以使用 telnet 命令重现该行为：
$ telnet remote-server 22
Trying x.x.x.x...
Connected to remote-server
Escape character is '^]'.
Connection closed by foreign host.
$ telnet remote-server 22
Trying x.x.x.x...
Connected to remote-server
Escape character is '^]'.
SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u1
Protocol mismatch.
Connection closed by foreign host.
更新：
强制在跳转盒中的客户端配置Protocol 2中。/etc/ssh_client不用找了。
更新2：
将使用 DES-EDE3-CBC 加密的旧密钥更改为使用 AES-128-CBC 加密的新密钥。再次没有明显的变化。
更新3：
有趣的是，当多路复用器处于活动状态时，这种情况不会自行出现。
更新4：
我还在 serverfault 上发现了类似的问题，但没有选择答案：https://serverfault.com/questions/445045/ssh-connection-error-ssh-exchange-identification-read-connection-reset-by-pe
sshd: ALL尝试重新生成 ssh 主机密钥，但没有成功的建议。
更新5
在目标上的虚拟机上打开控制台并看到一些“奇怪”的东西。 tcpdump 而 1.1.1.1 是跳转盒。
# tcpdump -n -vvv "host 1.1.1.1"
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:47:45.808273 IP (tos 0x0, ttl 64, id 38171, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.1.37924 > 1.1.1.2.22: Flags [S], cksum 0xfc1f (correct), seq 3260568985, win 29200, options [mss 1460,sackOK,TS val 407355522 ecr 0,nop,wscale 7], length 0
11:47:45.808318 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
1.1.1.2.22 > 1.1.1.1.37924: Flags [S.], cksum 0x5508 (incorrect -> 0x68a8), seq 2881609759, ack 3260568986, win 28960, options [mss 1460,sackOK,TS val 561702650 ecr 407355522,nop,wscale 7], length 0
11:47:45.808525 IP (tos 0x0, ttl 64, id 38172, offset 0, flags [DF], proto TCP (6), length 52)
1.1.1.1.37924 > 1.1.1.2.22: Flags [.], cksum 0x07b0 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 407355522 ecr 561702650], length 0
11:47:45.808917 IP (tos 0x0, ttl 64, id 38173, offset 0, flags [DF], proto TCP (6), length 92)
1.1.1.1.37924 > 1.1.1.2.22: Flags [P.], cksum 0x6de0 (correct), seq 1:41, ack 1, win 229, options [nop,nop,TS val 407355522 ecr 561702650], length 40
11:47:45.808930 IP (tos 0x0, ttl 64, id 1754, offset 0, flags [DF], proto TCP (6), length 52)
1.1.1.2.22 > 1.1.1.1.37924: Flags [.], cksum 0x5500 (incorrect -> 0x0789), seq 1, ack 41, win 227, options [nop,nop,TS val 561702651 ecr 407355522], length 0
11:47:45.822178 IP (tos 0x0, ttl 64, id 1755, offset 0, flags [DF], proto TCP (6), length 91)
1.1.1.2.22 > 1.1.1.1.37924: Flags [P.], cksum 0x5527 (incorrect -> 0x70c1), seq 1:40, ack 41, win 227, options [nop,nop,TS val 561702654 ecr 407355522], length 39
11:47:45.822645 IP (tos 0x0, ttl 64, id 21666, offset 0, flags [DF], proto TCP (6), length 40)
1.1.1.1.37924 > 1.1.1.2.22: Flags [R], cksum 0xaeb1 (correct), seq 3260569026, win 0, length 0
11:47:50.919752 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.1.1.2 tell 1.1.1.1, length 46
11:47:50.919773 ARP, Ethernet (len 6), IPv4 (len 4), Reply 1.1.1.2 is-at 00:50:56:b9:3d:2b, length 28
11:47:50.948732 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.1.1.1 tell 1.1.1.2, length 28
11:47:50.948916 ARP, Ethernet (len 6), IPv4 (len 4), Reply 1.1.1.1 is-at 00:50:56:80:57:1a, length 46
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel
更新6
由于校验错误，我禁用了将 TCP/UDP 校验和卸载到虚拟机中的 NIC，但这并没有改善情况。
$sudo ethtool -K eth0 rx off
$sudo ethtool -K eth0 tx off
iface eth0 inet static
address 1.1.1.2
netmask 255.255.255.0
network 1.1.1.0
broadcast 1.11.1.255
gateway 1.1.1.254
post-up /sbin/ethtool -K $IFACE rx off
post-up /sbin/ethtool -K $IFACE tx off
了解 VMware 环境中的 TCP 校验和卸载 (TCO) (2052904)
更新7
GSSAPIAuthentication在 Jumpbox 的 ssh 客户端中禁用。测试过Enable Compression yes没有变化。
更新8
测试用 填充校验和iptables。
/sbin/iptables -A POSTROUTING -t mangle -p tcp -j CHECKSUM --checksum-fill
这并没有改善情况。
更新9：
发现一个关于限制密码的有趣测试，将尝试一下。 MTU 问题似乎不是罪魁祸首，因为在某些情况下我在同一网络中的服务器和客户端上遇到问题。
目前在客户端测试“ssh -c aes256-ctr”，症状没有改善。
更新10
将其添加到/etc/ssh/ssh_config.没有变化。
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
更新11
在22端口和2222端口定义了ssh服务，没有作用。
更新12
我怀疑这是 OpenSSH 7.4 中存在的回归错误，已在 OpenSSH 7.5 中得到纠正
OpenSSH 7.5 的发行说明
- sshd(8)：修复 OpenSSH 7.4 对 server-sig-algs 扩展的支持中的回归，其中 SHA2 RSA 签名方法未正确公布。 bz#2680
为了在 Debian 9/Stretch 中使用 openSSH 7.5，我安装了openssh-clientDebian openssh-servertesting/Buster。
情况没有任何改善。
更新13
定义
密码 aes256-ctr MAC hmac-sha1
在客户端和服务器端。没有任何改进。
更新14
设置
UseDNS no
GSSAPIAuthentication no
GSSAPIKeyExchange no
不用找了。
更新15
/etc/ssh/sshd_config
将其更改为 /etc/ssh/sshd_config：
TCPKeepAlive no
TCPKeepAlive 运行在 TCP 层。它发送一个空的 TCP ACK 数据包 [从 SSH 服务器到客户端 - Rui]。防火墙可以配置为忽略这些数据包，因此，如果您通过丢弃空闲连接的防火墙，这些数据包可能无法保持连接处于活动状态。
我的猜测是 TCPKeepAlive 正在配置服务器发送一个数据包，该数据包在下面的堆栈中的某个层中被优化/忽略，并且远程 SSH 服务器认为它仍然连接到 TCP mux 客户端，而实际上会话已经被撕毁；因此，第一次尝试时 TCP 会重置。
因此，虽然有人说如果您使用 ClientAliveInterval，则可以禁用 TCPKeepAlive，但似乎更应该在使用 ClientAliveInterval 时禁用 TCPKeepAlive。
- 显然是这个选项；至于解释，它们主要是猜测，如果我有时间的话，我必须仔细检查它们/来源。
TCPKeepAlive 显然也存在欺骗问题，因此建议将其关闭。
尽管如此，仍然存在问题。
答案1
您是否正在尝试尝试 TCP 优化的任何固件或设备？我在网络上也有过同样的经历，结果发现这是一个进行 TCP 优化的设备。
答案2
最后发现这是由于使用的 Cisco 6059 FWSM 核心路由器和 ASA 防火墙的错误造成的。
Linux 内核 v3 和 v4 不能很好地处理 TCP 序列随机化，并在传输大文件时出现“随机”问题，或在许多连接中出现其他类型的模糊问题，其中 SSH 更为明显。不幸的是，Windows、Mac 和 FreeBSD 都运行良好，因此它在某种程度上可以被称为 Linux 错误。
这是一个非常糟糕的情况，因为我们抱怨人们无法从我们的网站下载随机文件。
每个 TCP 连接都有两个 ISN：一个由客户端生成，一个由服务器生成。 ASA 随机化在入站和出站方向传递的 TCP SYN 的 ISN。
随机化受保护主机的 ISN 可防止攻击者预测新连接的下一个 ISN 并可能劫持新会话。
如有必要，您可以禁用 TCP 初始序列号随机化，例如，因为数据变得混乱。例如：
如果另一个内联防火墙也随机化初始序列号，则两个防火墙都不需要执行此操作，即使此操作不会影响流量。
我最初在内部核心路由器中禁用了思科随机化，但这还不够。在边界防火墙和核心思科路由器/交换机中禁用思科随机化后，问题不再发生。
为了禁用它，它类似于：
policy-map global_policy
class preserve-sq-no
set connection random-sequence-number disable
请参阅思科说明禁用 TCP 序列随机化
我还在用于 NAT 优化的 FWSM 上发现了一个不相关的 XLATE 错误，默认情况下启用该错误，这会导致虚假通信问题，并且由于核心路由器不负责 NAT，因此将其禁用：
xlate-bypass
启用 xlate-bypass 在上面的两个示例中，xlate 都是使用 Ii 标志创建的。这些标志表明 xlate 是源自高安全性 (i) 接口的身份转换 (I)。默认情况下，FWSM 将为任何与显式 NAT/PAT 规则不匹配的流量构建这些 xlate。为了禁用此行为，可以在 FWSM 3.2(1) 及更高版本中启用 xlate-bypass 命令：
FWSM(config)# xlate-bypass
请注意，这些是默认配置，我们花了几个月的时间在内部调查中追踪这一点，而我在这里不会提及的几个相关供应商无法查明这些配置是罪魁祸首。
答案3
您的症状听起来与网络上有一台计算机使用与 SSH 服务器相同的 IP 地址一致。检查RST报文的MAC地址。
答案4
发现一些系统带有
net.ipv4.tcp_timestamps = 0
在 /etc/sysctl.conf 中；有问题的服务器都启用了该功能。
我最终从受影响的系统中获取了这一行并在所有系统中运行：
sudo sysctl -w net.ipv4.tcp_timestamps=1
等待进一步的测试。