DNS または /etc/hosts ファイルに表示されないノードへの ssh、scp、または sftp は、初期接続の確立に時間がかかります。接続が確立された後、速度は期待どおりです。考慮すべき 2 つのケースがあります。以下を参照してください。ほとんどの環境では、IP が /etc/hosts または DNS にあるため、この問題は発生しないことに注意してください。
この時間は、ターゲット/ソース ホスト名の IP アドレスを解決するか、ターゲット/ソース IP アドレスのホスト名を検索するか、まったく同じデータに基づいて認証を実行するために費やされます。 -vvv を使用すると、2 つの異なる詳細な症状が発生します ssh は 2 つの異なるケースを構成します。
ケース 1
# ssh -vvv 10.10.10.205 ... ... debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 10.10.10.205. debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found
CentOS/RHEL システムでは、SSH デーモンは Generic Security Services Application Program Interface (GSSAPI) を使用するように構成されています デフォルトで認証。デフォルトでは、GSSAPI は (DNS または /etc/resolv.conf に基づくその他の手段を介して) 要求された IP を検索します。 IP アドレスを使用した場合でも検索が行われることに注意してください。これは、安全で信頼できる認証に必要です。
SSH 構成のマンページを確認する場合:
# man ssh_config
...
GSSAPIAuthentication
Specifies whether user authentication based on GSSAPI is allowed. The default is no
... IP / ホストが /etc/hosts または DNS データベースに表示されない場合、ルックアップ クエリは再試行中にタイムアウトになり、最終的にあきらめて接続を開き続けます。パスワード プロンプトが表示されるまで、ルックアップ中に時間 (50 秒以上) が費やされます。このストールは、DNS または /etc/hosts ファイルではなく、ローカル LAN 上にあるホストでのみ発生します。認証方法が GSSAPI であることに注意してください。
ケース 2
# ssh -vvv 10.10.10.12 . . . debug1: Offering public key: /root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply --stalls for 8 seconds--
ここでは、リモート ホストがクライアント ノード IP で DNS ルックアップを実行しようとしています。 /etc/hosts または DNS で更新されていない新しい物理マシンまたは仮想マシンのインストールである可能性があるため、DNS クエリがタイムアウトするまで停止します。ここでも、DNS / ホスト ルックアップが行われます (クライアント / サーバーの /etc/resolv.conf に基づきます)。
解決策
この問題に対するサポートされている適切な解決策は、ホスト名/IP ルックアップを成功させることです。そのためには、次のことができます:
- 名前解決と DNS サーバーの構成については、/etc/resolv.conf の構成を確認してください。
- 定義されていない場合は、新しく導入されたホスト / IP を DNS サーバーに含めるように定義します
- DNS 定義を行うことが問題である、または行うに値しない場合 (ほとんどの場合、割り当ては一時的なものです。つまり、テスト システム、一時的な仮想マシンなど)、ホスト名と IP アドレスのペアがソースとターゲットに含まれていることを確認してください。環境の /etc/hosts ファイル (これはより実用的です)
回避策
適切な DNS / ホスト (または /etc/resolv.conf 構成) がないと、SSH 接続は最初は遅くなります。それがOELで期待される方法です。または、設定を変更することで待機状況を回避できる場合もあります。
ケース 1 の場合 GSSAPIAuthentication が無効になっている可能性があります。それは可能ですが、GSSAPI の使用は SSH が提供する基本的なセキュリティ機能の 1 つであるため、強くお勧めしません。 SSH は、通信内容をセキュアにするだけでなく、そのターゲットが意図したものであることを確認できます。これは、OEL で GSSAPIAuthentication が yes に設定されているためです (man ページではデフォルトで「いいえ」と記載されていますが、これはコア ssh パッケージのデフォルトであり、特定のディストリビューションではありません)。それでも、閉鎖されたネットワーク上にいることが完全に確実であり、自分が何をしているのかを知っている場合は、無効にすることができます:
一時的なセットアップ – コマンド ラインで動作するかどうかを確認するためだけに:
# ssh -o "GSSAPIAuthentication no" 10.10.10.205
ケース 1 の場合は、パスワード プロンプトがすぐに表示されます。これを永続的に設定するには (別の推奨事項にもかかわらず)、クライアントで次のいずれかの方法で GSSAPIAuthentication を no に変更できます:
1. 以下の行をユーザーのホーム ディレクトリの ssh 構成ファイル (~/.ssh/config) に追加します。 ):
GSSAPIAuthentication no
2. クライアントのシステム SSH 構成ファイルに追加します。すなわち – /etc/ssh/ssh_config そしてサーバー側。サーバー側 (つまり、接続しているシステム、この場合は 10.10.10.205) 構成ファイルを編集します – /etc/ssh/sshd_config および sshd を再起動します:
# service sshd restart
これは、すでに SSH 接続が確立されているときに実行できます。
ケース 2 の場合、DNS 構成または /etc/hosts ファイルを変更できない、または変更したくない場合 (その他の推奨事項にもかかわらず)、SSH プロトコルに対して行われる DNS ルックアップを無効にすることで状況を回避できます。設定することでできます
UseDNS no
サーバーの SSH 構成ファイル – /etc/ssh/sshd_config
サーバーでsshdを再起動します
# service sshd restart
これは、接続がアクティブなときに実行できます。