Linuxホストにログインしようとすると、ssh
ローカルコンピュータにsshコマンドを入力してから約15秒後にターミナルプロンプトが表示されます。その後の接続には2〜3秒かかります。ただし、しばらく待ってからリモートホストとの接続を切断して再接続すると、かかるssh
時間は最初と同じです。
- オペレーティングシステムはAmazon Linux 2です。
- CPUおよびネットワーク図には、前後に異常はありません。
UseDNS
コメントアウトされました/etc/ssh/sshd_config
。
可能な場所を見てみましょう。
答え1
「Amazon Linux 2」と言われましたが、これはクラウドホストですか?
その場合、現在のホストがクラウド上のどこにあるかを正確に把握し、適切なNATマッピングを作成してSSH接続をそこにルーティングするのに時間がかかることがあります。ただし、既存の接続がある場合、マッピングはすでに適用されており、2番目とそれ以降の接続はより速く確立されます。
クラウドホストで実行中の特定のエントリがない場合、クラウドプロバイダはホストが完全にアイドル状態であり、電力を節約するためのネットワーク接続がないことを検出すると、ホストを自動的に中断する可能性があります。あるいは、仮想ホストをデータセンターの他のハードウェアデバイスに移動して負荷を最適化することもできます。最初の着信SSH接続は、CPUリソースとネットワーク接続の再最適化のみをトリガし、仮想マシンが異なるハードウェアデバイスです。
デフォルトでは、これはホスティングプロバイダに連絡する必要があります。
答え2
説明では、遅延が発生する場所は明確ではありません。コマンドラインで「Enter」を押した後の手順を検討してください。
コンピュータはSSH設定を確認します。質問したので、オーバーヘッドは大きくないようですが、非常に複雑な構成でも一般的に迅速に処理できます。
コンピュータは(最初の)SSHエンドポイントにDNS要求を送信し、応答を待つ必要があります。応答がないと、約30秒のタイムアウトが発生します。アクセスの設定方法によっては、複数のホップがある場合があります。
コンピュータがエンドポイントとTCPハンドシェイクを開始します。 TelcoMが述べたように、賢明なルーティングおよび/またはファイアウォールが進行している場合は時間がかかる可能性があります。接続を制限してDOSを軽減することはまれではありません。
サーバーは公開鍵を提供し、それをコンピューターで確認します。
サーバーはシェルの実行を開始し、すべての起動ファイルを実行します。これは、キャッシュに必ずしも存在しない多くのファイルが用意されていることを意味します。これには、バナーメッセージ、設定パス、およびプロンプト表示が含まれます。
(オプション)ジャンプホストの場合、サーバーはネクストホップのクライアントになり、手順2〜5を実行します。
リモートシステムからメッセージを受け取ります。
ssh は接続を多重化するので、2 番目の接続を行うと、手順 5 から始まります。
ssh -v
(またはより良い方法)を使用すると、ssh -vvv
これらのステップにかかる時間に関する洞察を得ることができます。
答え3
潜在的な原因が多すぎるため、すべてを一覧表示することはできません。みんな、ランダムに思い浮かぶアイデアを試すのに時間がかかることがあります。
(遅い応答、誤って設定されたLDAP呼び出しによる適切なインデックス付けの欠如によって速度が遅くなるのを見ました。あります。)
代わりに、ログインしてお金をどこに書いているかを調べることをお勧めします。
私は次のように始めます:
script -fc 'ssh -v server' -t /dev/null
これにより、ssh
多くのステップが記録され、script
行間に経過した時間が(stderrから)放出されます。
より簡単な例を見てみましょう。
script -fc 'echo a; sleep 1; echo b; sleep 1; echo c' -t /dev/null
Script started, output log file is '/dev/null', timing file is '/dev/stderr'.
a
0.000733 3
b
1.000921 3
c
1.001222 3
Script done.
ここでは、ライン「a」と「b」の間に約1秒かかり、ライン「b」と「c」の間に約1秒かかったことがわかります(script
タイミング情報をエクスポートします)。後ろにワイヤー)。
ssh -v
script
冗長なので、スクリプトセッションでコマンド自体を実行したい場合があります。 :)
これにより、速度の低下がクライアントとサーバー間で発生するのか、主にサーバーで発生するのかについての手がかりを得ることができます。
また、サーバー自体から接続を試みて、クライアントとサーバー間の遅延を排除することもできます。
速度の低下が主にサーバーで発生する場合は、SSHサーバーとPAM( `journalctl -u ssh -ef)のログを調べて、接続時に上部を確認することをお勧めします。