☰

リモート サーバーへの ssh はハングしますが、ローカルでは動作します (putty / cygwin / Windows 10 から Linux)

tag-icon • tag-icon networking ssh cygwin putty
リモート サーバーへの ssh はハングしますが、ローカルでは動作します (putty / cygwin / Windows 10 から Linux)

私は OpenSSH を実行している Linux サーバーを持っています。ローカル LAN からもリモートからも接続できます。ただし、ローカルでしか接続できないクライアントが 1 つあります (Windows 10 ラップトップ)。リモートで接続しようとすると、認証は受け入れられますが、ラップトップの SSH クライアントがハングし、Process Explorer で強制終了する必要があります。問題は次の可能性があると考えました。

  1. Windows ファイアウォール - いいえ。無効にしましたが、同じ動作になりました。
  2. ssh クライアント (cygwin) - いいえ。putty でも同じ動作になりました。
  3. Windows 10 - いいえ。別の Win10 マシンからリモートで正常に接続できます。

Cygwin と Putty の両方を新規インストールしてみました。

いくつかの -v オプションを付けて ssh を実行し、接続可能な他の Win10 マシンの出力と比較してみました。出力は、ある程度まで同一でした。

Authenticated to <<IP REMOVED>>.
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

>>>  "bad" machine hangs here

debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to Linux Mint 17.3 Rosa (GNU/Linux 3.19.0-32-generic x86_64)

Welcome to Linux Mint

まれに、さらに進むことがあり (1、2 回は Welcome メッセージまで表示されました)、入力に対して接続が応答しないことがあります。

サーバー上で sshd -d を手動で実行し、「不良」リモート セッションと別のクライアントからの「良好」なセッションの出力を比較してみました。出力は同じです。

要約すると、Windows ファイアウォール、クライアント ソフトウェア、Win10、サーバーへのポート転送、DNS、サーバー自体の問題ではないようです。問題は、この 1 台のクライアント マシンのみで、ローカル LAN の外部から接続する場合のみです。認証は正常に行われています。また、クライアント マシンは、問題が発生していない別のマシンと同じ OS/ssh クライアントを実行しており、ログにもそれを区別するものは何も見つかりません。

編集: また、他のリモート サーバーへの SSH 接続はすべてのマシンから正常に機能することも言及する必要があります。これは、このサーバー/クライアント ペアのみであり、リモートで接続する場合のみのようです。

更新: 詳細については、すぐ下のコメントを参照してください。問題はローカル ネットに固有のようです。

デバッグするにはさらにどのような手順を実行すればよいでしょうか?

答え1

ハングした時点で、サーバーからの TCP パケットがクライアントに到達しなくなるように見えます。そう考える理由は、ハングするポイントが時々異なるため、またネットワーク構成の変更によって問題が変化するためです。たとえば、ポート転送、NAT、ファイアウォール間の望ましくない相互作用が考えられます。しかし、問題は、なぜこれが 1 つのクライアントで発生し、別のクライアントでは発生しないのかを診断する方法です。考えられるアプローチは 2 つあります。

  • 試してみるといいパケット監視サーバーとクライアント上、およびルート上の各ポイントで、パケットが実際に失われているかどうか、またどのポイントで失われているかを確認します。

  • さまざまなクライアントでネットワーク設定と問題の有無の関係を見つけるために実験してみることもできます。正常に動作しているクライアントと動作していないクライアントの間で、すべてまたは一部のネットワーク設定と IP アドレスを交換して、問題が交換されるかどうかを確認します。

関連情報