web-dev-qa-db-ja.com

SSH over NAT error：ssh_exchange_identification：read：Connection reset by peer

サーバーがルーター（NAT）を介してインターネットに接続しています。すでにポート転送を設定しています。

SSHはLAN IPで接続すると正常に動作しますが、WAN IP経由で接続すると動作しません。

私が試したこと

  • サービス/コンピューターを再起動する
  • ポートの変更（ルーターとsshポートの両方）
  • sshキーをリセットします（これらは/etc/ssh）
  • チェック済み/etc/hosts.allowおよび/etc/hosts.deny
  • 追加 sshd: ALLからhosts.allow
  • 小切手 iptables -L（何もない）
  • ProxyCommand nc %h %pここの答えから

サーバー側のログ（注：xxx.xxx.xxx.xxxは私のパブリックIPです）

debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private Host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private Host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private Host key: #2 type 3 ECDSA
debug1: private Host key: #3 type 4 ED25519
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 222 on 0.0.0.0.
Server listening on 0.0.0.0 port 222.
debug1: Bind to port 222 on ::.
Server listening on :: port 222.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx.xxx.xxx.xxx port 58644 on 192.168.0.101 port 222

クライアント側のログ

ssh -vvv -C -A -X -p 2222 [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "xxx.xxx.xxx.xxx" port 2222
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 2222.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/yan/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
ssh_exchange_identification: read: Connection reset by peer

何かアドバイスをいただければ幸いです。ありがとう！

ubuntusshconnection
1
yan

ssh_exchange_identification: read: Connection reset by peer

多くの苦労の後、次のコマンドを実行するだけで拒否されたssh接続を修正しました。

Sudo dhclient
1
Naseer-shaik

ログを提供していただきありがとうございます。つまり、サーバー上のsshdは接続が着信したことを確認できますが、そうではありません。

私の最初の推測はあなたのNATルーターについてです。多分それはうまくいきません。説明の一部が明確ではありません。サーバーからNATルーターのインターネット側に接続していて、これが機能しない場合は、インターネットから接続しようとする可能性があります。

Webサーバーなど、知っている他のサービスを試し、NATルーターを調整してアクセス可能にすることもできます。うまくいくかどうか。

TcpdumpやWiresharkなどのスニッフィングツールを使用して収集できる非常に正確な情報。理想的には、接続の両側で使用します。次に、パケットがどのようにNAT処理されるかを確認します。

SshクライアントがIP 1.1.1.1上にあり、サーバーのインターネット接続が3.3.3.3上にあるとします。したがって、ssh 3.3.3.3 ENTERと入力すると、TCPパケットを1.1.1.1からランダムポート（たとえば55555から3.3.3.3）に送信します。 sniffe4rを使用して、このパケットがネットワークインターフェースに表示されるはずです。このパケットはインターネットを経由して3.3.3.3のNATルーターに到達し、そこで192.168.1.11などのLAN IPにNAT変換されます。サーバーのスニファーは、1.1.1.1から192.168.1.11ポート22へのtcp synパケットを見るはずです。

Sshdが接続を受け入れると、ローカルスニファに応答パケットが表示されます。192.168.1.11ポート22から1.1.1.1ポート55555へのtcp ack/synパケットです。これはNATルータを通過し、 「3.3.3.3ポート22から1.1.1.1ポート55555へ」に変更されます。この時点ではスニッフィングできないため、通常は発信パケットを見ることができません。しかし、ここまですべてが正しければ、クライアント側に移動し、スニファーがそれをキャッチできます。この時点で、クライアントは接続が確立されていることを確認し、接続の確立を確認するために、TCP ACKパケットで1.1.1.1ポート55555から3.3.3.3ポート22へのパケットで応答します。このパケットは移動してNAT処理され、サーバーにも双方向ハンドシェイクの完了が表示されます。

しかし、「ピアによる接続のリセット」が表示されているように、おそらくこの問題が発生する前に問題が発生します。

tcpdumpingのヒント：クライアントマシン（インターネット上のルートサーバーである可能性があります）にsshしてtcpdumを開始すると、パケットの終わりのストリームが9つ表示されることがあります。tcpdumpを転送するパケットがtcpdumpされます。出力。これは、tcpdumpで再度取得されます。これを簡単に管理するには、sshサーバーのポート（または少なくともルーターのNAT構成）を別のポート（2222など）に変更します。

次に、sshコマンドはssh 3.3.3.3 -p 2222となり、次のようにtcpdumpをフィルタリングできます。

tcpdump port 2222

または、クライアントへの動作中のssh接続以外のすべてを表示したい場合：

tcpdump not port 22

tcpdumpingを楽しんでインターネットトラフィックを監視し、多くのことを学んでください。

トムトムトム

0
TomTomTom