☰

SSH接続タイムアウトの問題を診断する方法は？

tag-icon • tag-icon debian ssh openssh troubleshooting
SSH接続タイムアウトの問題を診断する方法は？

Debian 7を実行しているVPSがあり、WindowsシステムでPuTTYを使用して接続します。ほとんどの場合、PuTTYがうまく接続され、正常にログインします。ただし、PuTTYは時々この状態を報告しますConnection Timeout。

前回これが起こったときにSSHを実行しているポートにTelnetを試しましたが、接続できませんでした。その後、サービスが実行されていることを知っているVPSの他のポートにTelnetを試しましたが、接続は大丈夫でした。

「再生」が始まったら、5～10回接続しようとすると正常に接続できます。システムログを確認しましたが、この問題を解決するのに役立つ興味深いコンテンツが見つかりませんでした。価値がある場合、サーバーが「実行中」の間にサーバーに接続すると速度が遅くなるようです（コマンドを入力すると、SSHウィンドウに表示されるまで1〜2秒かかります）。

ほとんどの場合、ファイアウォールが機能するため、ファイアウォールの問題ではないようですが、時にはそうでない場合があります。ホストがメンテナンスをしているのではないでしょうか？

編集：TCPKeepAliveが有効になっています。もう一度登場し、SSHポートにTelnetを試してみると、実際に接続できます。奇妙な。

答え1

診断するには、まずputty.exeの詳細モードを使用する必要があります。

cmdを開き、次を使用します。

putty.exe -v -ssh user@]host

-v はより多くの情報を表示します。

緊密な接続を防ぐために、設定を確認してください。

PuTTY(Win): セッションのプロパティ>接続に移動し、空のパケットを送信してセッションを維持します。下の接続保持間隔（0はオフ）を300（5分）に設定します。

Linux（ssh）の場合： システム全体で接続の維持を有効にするには:

  • すべてのユーザーの場合：/etc/ssh/ssh_configを編集します。
  • あなたに合った方法：代わりに〜/ .ssh / configを編集してください。

以下を挿入してください。

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 2

/etc/ssh/sshd_configに以下を追加して、OpenSSHサーバーがクライアントへのすべての接続を維持することを有効にすることもできます。

KeepAlive yes
ClientAliveInterval 300
ClientAliveCountMax 2

これらの設定により、SSHクライアントまたはサーバーは300秒（5分）ごとに相手に空のパケットを送信し、2回試行しても応答が受信されないと、接続が切断される可能性が最も高いポイントで放棄されます。とにかく廃棄されました。

ssh_configのマニュアルページから：

サーバーの最大アクティビティ数ssh（1）がサーバーからメッセージを再受信できない場合に送信できるサーバーアクティブメッセージの数（以下を参照）を設定します。サーバー活動メッセージの送信中にこのしきい値に達すると、sshはサーバーとの接続を切断してセッションを終了します。サーバーアクティビティメッセージの使用はTCPKeepAlive（下）とは大きく異なることに注意することが重要です。サーバーアクティビティメッセージは、偽装できないように暗号化されたチャネルを介して送信されます。 TCPKeepAliveアクティブなTCP keepaliveオプションはなりすまし可能です。サーバーの活動メカニズムは、クライアントまたはサーバーが接続を無効にするタイミングを知る必要がある場合に役立ちます。

デフォルトは 3 です。たとえば、ServerAliveInterval（以下を参照）が15に設定され、ServerAliveCountMaxがデフォルトのままである場合、サーバーが応答しない場合、約45秒後にsshの接続が切断されます。このオプションはプロトコルバージョン2にのみ適用されます。プロトコル バージョン 1 にはサーバー活動メッセージに応答するようサーバーに要求するメカニズムがないため、切断するのは TCP スタックの責任です。

サーバー活動間隔サーバーからデータが受信されない場合、ssh（1）は暗号化されたチャネルを介してメッセージを送信してサーバーに応答を要求するタイムアウト間隔（秒単位）を設定します。デフォルト値は 0 です。これは、BatchModeオプションが設定されている場合、これらのメッセージがサーバーに送信されないことを意味し、デフォルトは300です。このオプションはプロトコルバージョン2でのみ利用可能です。 ProtocolKeepAlivesとSetupTimeOutは、このオプションのDebian専用の互換性エイリアスです。

答え2

より広いネットワーク問題を排除したいように聞こえ、そうすることはおそらく正しいでしょう。

ping（私はいつもとを見ながらネットワーク待ち時間の測定を測定することを検討しています。ローカルインターネット接続に関連する可能性がある非常に広範な問題があるかどうかを確認するのにtraceroute時間がかかりすぎないからです。）ping

VPSを使用するときに知っておくべき2つの一般的な問題があると思います。

  1. 小さすぎるVPSであまりにも多くのコンテンツを実行しようとしている場合。あまりにも多くのメモリを使用し、ディスクの内外でデータ/コードを継続的に交換できます。これでディスク使用量が非常に多く、すべてが遅くなります。たとえば、SSHをロードするのに時間がかかります。

    診断：メモリ使用量を監視します。

    上これは、メモリ使用量やその他のパフォーマンス情報の非常におおよそのログを生成する便利な方法です。atop運用コストはRAM（32ビットおよび64ビット）の約5/10Mです。これはXenまたはKVMベースのVPSで動作します。 OpenVZ（または他のコンテナベースのVPS）でどれだけうまく機能するのかわかりません。

  2. 「騒々しい隣人」の問題。時には、以前の問題を経験している他の人が原因で発生することがあります。 :) 仮想マシンでは、他の多くの人とハードウェアを共有します。誰かが「予想」よりも多くのディスクIO（またはより多くのメモリ）を使用している場合、同じハードウェア上の他のVPSが影響を受けます。

    モニタリングはこれを診断するのにも役立ちます。しかし、これはもっと難しくて専門的な質問かもしれません。

サービスの実際の応答時間に近い測定と監視が可能なもの（ログ/チャート）に集中することをお勧めします。これは、あなたのVPSが主にパブリックWebサーバーであり、これを実行できる無料の試用版/制限付きサービスがある場合の一般的な要件です。

良いホストは、両方の監視タイプについて基本的なアドバイスやツールを提供すると結論付けることができますが、これが実際にどれくらい一般的なのかわかりません。

あなたのVPSプロバイダはこの種の問題を知っています。診断方法の1つは、その機関に連絡して発生した問題を説明することです。 :-).

答え3

なぜこれが起こるのかわかりません（私たちが見たように、ソース、ターゲット、およびネットワークコンポーネントに影響を与える多くの要因があることが一般的な合意のようです）。

scpただし、実際の作業を実行する前に小さなダミーファイルをコピーすると、ssh複数のLinuxおよびAIX環境でこの問題がほとんど解決されることがわかりました。

echo Copying small dummy file to $DESTINATION_IP
scp -o StrictHostKeyChecking=no -o PasswordAuthentication=no dummy.tmp testuser@$DESTINATION_IP:/tmp/. 
echo Testing ssh again
ssh -n -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=no testuser@DESTINATION_IP

関連情報