kex_exchange_identification: 読み取り: ピアによって接続がリセットされました。接続は他の NIC/サブネットでは機能します

kex_exchange_identification: 読み取り: ピアによって接続がリセットされました。接続は他の NIC/サブネットでは機能します

VM (CentOS7) を再インストールしたら、このエラーが発生しています。VM には、異なるサブネットにある 2 つのアダプタがあります。
面白いことに1つのサブネットでsshが正常に動作しました予想される MITM 警告を修正した後。

ssh -v は次のように表示します:

OpenSSH_8.0p1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "foreman" port yy
debug2: ssh_connect_direct
debug1: Connecting to foreman [xxx.xxx.xxx.xxx] port yy.
debug1: Connection established.
debug1: identity file /home/sam/.ssh/id_rsa type 0
debug1: identity file /home/sam/.ssh/id_rsa-cert type -1
debug1: identity file /home/sam/.ssh/id_dsa type -1
debug1: identity file /home/sam/.ssh/id_dsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ecdsa type -1
debug1: identity file /home/sam/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ed25519 type -1
debug1: identity file /home/sam/.ssh/id_ed25519-cert type -1
debug1: identity file /home/sam/.ssh/id_xmss type -1
debug1: identity file /home/sam/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
kex_exchange_identification: read: Connection reset by peer

私はもう試した

  • 再起動中
  • known_hosts ファイルを削除する
  • クライアントの /etc/ssh/ssh_config を確認しました (メンテナのバージョンからの逸脱はありません)
  • サーバーの /etc/ssh/sshd_config を確認しました (メンテナーのバージョンからの逸脱はありません)
  • ファイアウォールを停止する
  • .ssh/ と authorized_keys の権限を確認しました
  • ブラックリストとホワイトリストをチェックしました(何もなく、コメントのみ)(hosts.deny|hosts.allow)

関係があるかどうかは分かりませんが、クライアントはArch Linuxを実行しています

もう一度明確にすると、
サーバーには172.xxxと192.xxxの2つのIPアドレスがあり、sshは172.xxxでは機能しますが、192.xxxでは機能しません。

答え1

私には、これはルーティングの問題かネットマスクの問題のように思えます。似たような構成で、ネットワークスタックが送信パケットに間違ったインターフェースを使用しようとしたケースを見たことがあります。つまり、両方サブネットは、初めサブネット。

最初にテストするのは、別のマシンにpingできるかどうかです。それぞれサブネットのサーバ、逆もまた同様です。テストプロセスでエラーが発生しにくくするには、他の使用するマシン(クライアント)1つIPアドレス(そうしないと、IPアドレスの設定が間違っているためにテストが失敗する可能性があります)他の機械によるもので、誤解を招く恐れがあります。

次に、route -nサーバーとクライアントの出力を詳しく調べます。おそらく、これで問題の原因がすでに判明しているでしょう。その出力を公開していただけますか?

さらに、 の出力はifconfig -a(サーバーとクライアントの両方で) 役に立ちます - 最終的には、ネットマスクを理解したいと考えています。

これらの出力を公開する場合、IP アドレスがプライベート範囲のものであれば、難読化する必要はないと思います。難読化自体がエラーの原因となり、分析が不可能になる可能性があります。

これらの出力を公開することに決めた場合 (出力が長くなる可能性があるため、コメントを使用するのではなく、それに応じて質問を編集してください)、私はそれを確認して、何が起こっているのかを調べようとします。

答え2

私は少し異なる状況でこのエラーを経験しました。私の場合は、ssh サーバーがそもそもインストールされていなかったので、インストールしてサービスを開始するだけで問題は解決しました。

重要なのは、インストールまたは構成のいずれの理由であっても、ポート/IP/インターフェースで SSH が提供されていない場合に、このようなエラーが発生するということです。

関連情報