最初のSSH MUX接続を試みると、Jumphostが突然リセットされます。

最初のSSH MUX接続を試みると、Jumphostが突然リセットされます。

私はしばらくDebian 9 SSH Jumpboxホストを使用してスクリプト/アンシブルプレイブックを実行してきました。 Jumbox は主に Debian 9 および一部の Debian 8 サーバーと通信します。ほとんどのサーバーは、VMWare Enterprise 5.5で実行されている仮想マシンです。

JumboxのSSHクライアントは、SSH MUXを実行し、RSA証明書ファイルを介して認証するように構成されています。

SSHは長年にわたってうまくいきましたが、突然SSH接続でssh_exchange_identification: read: Connection reset by peer最初の試みで1日に数回エラーが発生し始めました。

しかし、最初の試みの後はしばらく元気でした。サーバーの誤った動作は最初はランダムに見えますが、いくつかのパターン/タイムアウトがあります。たとえば、予想されるスクリプト/プレイブックの前にコマンドを実行するなど、すべてのサーバーにコマンドを送信すると、一部のサーバーは失敗しますが、次のスクリプトはすべてのサーバーで実行されます。

最近のセキュリティアップデートに加えて、サーバーに大きな変更はありません。 Debian 9 への移行はしばらく進んだ。

MTU(間違った)構成または複数のサーバーに一度適用され、失敗し忘れた他の構成が見つかりましたが、これは本当ではありません。また、クライアント側とサーバー側のControlPersist両方が時間を1時間に短縮しましClientAliveIntervalたが、状況は改善されませんでした。

だから、現在のところ、なぜこれが起こるのかわかりません。しかし、私はこれがネットワークの問題ではなく、レイヤ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 を使用する 2 台以上のサーバーでこのエラーを確認しました。

tcpdump以下は、ファイアウォールがない同じネットワークに2台のコンピュータがある場合、サーバーが奇妙に動作する状況です。さらに、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

ターゲットのVMでコンソールを開き、「奇妙な」ことを発見しました。 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

チェックサムエラーのため、仮想マシンのNICのTCP / UDPチェックサムオフロードを無効にしましたが、状況は改善されませんでした。

$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

GSSAPIAuthenticationJumpboxのSSHクライアントでは無効になっています。テストされ、Enable Compression yes変更はありません。

アップデート8

テスト用パッドチェックサムiptables

/sbin/iptables -A POSTROUTING -t mangle -p tcp -j CHECKSUM --checksum-fill

これは状況を改善できませんでした。

アップデート9:

限られたパスワードの興味深いテストを見つけたので、試してみてください。 MTUの問題は原因ではないようです。場合によっては、同じネットワーク上のサーバーとクライアントの両方に問題があったためです。

現在、クライアントで「ssh -c aes256-ctr」をテストしていますが、症状は改善されません。

SSHクライアントが破損した不思議なケース(「ピアによる接続のリセット」)

アップデート10

に追加してください/etc/ssh/ssh_config。変更はありません。

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

SSHの問題:ソケットの読み取りに失敗しました:ピアによる接続のリセット

アップデート11

SSHサービスはポート22とポート2222で定義されていますが、何の効果もありません。

アップデート12

私はこれがOpenSSH 7.4に存在し、OpenSSH 7.5で修正された回帰のバグだと思います。

OpenSSH 7.5 リリースノート

  • sshd(8): SHA2 RSA 署名方式が正しく広告されていない server-sig-algs 拡張に対する OpenSSH 7.4 サポートの回帰問題を修正しました。 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

~からSSHでtcp-keepaliveはどのように機能しますか?

TCPKeepAlive は TCP 層で実行されます。 [SSH サーバからクライアント - Rui へ] 空の TCP ACK パケットを送信します。これらのパケットを無視するようにファイアウォールを構成できるため、アイドル接続を破棄するファイアウォールを通過すると、これらのパケットが接続をアクティブに保つことができない可能性があります。

私の考えでは、TCPKeepAliveが下のスタックのいくつかの層で最適化/無視されたパケットを送信するようにサーバーを構成しています。 ;したがって、最初の試みでTCPがリセットされます。

したがって、一部の人々はClientAliveIntervalを使用するとTCPKeepAliveを無効にできると言っていますが、ClientAliveIntervalを使用するときはTCPKeepAliveを無効にする方が適切です。

  • 明らかに、このオプションは説明にとってほとんど推測されているので、時間があればその内容/ソースを再確認する必要があります。

TCPKeepAliveにもなりすましの問題があるように見えるので、オフにすることをお勧めします。

それでも問題があります。

ベストアンサー1

TCP最適化を試みるファームウェアやデバイスを使用していますか?ネットワークでも同じ経験をしていて、わかるとTCPに最適化されたデバイスでした。

おすすめ記事