web-dev-qa-db-ja.com

CentOS7でログインするときの長い遅延

CentOS 7システムを使用していて、PuTTYまたはsshでログインすると、パスワードプロンプトが表示されるまでに長い遅延があります。私はssh -vを実行しましたが、次のようになることがわかりました。

debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

その後、1〜2分間そのままになり、次の出力が爆発します。

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug1: Next authentication method: password

そして、パスワードプロンプトが出てきます。これは、ログインしているユーザーに関係なく発生します。これは、1つのシステムでのみ発生します。私はそれが遅れることなく進んでいる他に5人います。

ログにディスクやメモリなどのエラーはありません。

このような遅延の原因は何ですか？

更新：

GSSAPIAuthenticationをnoに設定してみましたが、問題は解決しませんでした。

私はもう一度sshを実行しましたが、今回は-vvvを使用しました。この出力が出てハングアップしました：

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/motor/.ssh/id_rsa ((nil)),
debug2: key: /home/motor/.ssh/id_dsa ((nil)),
debug2: key: /home/motor/.ssh/id_ecdsa ((nil)),
debug2: key: /home/motor/.ssh/id_ed25519 ((nil)),

1〜2分後にこれが出てきました：

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug3: no such identity: /home/motor/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug3: no such identity: /home/motor/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug3: no such identity: /home/motor/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug3: no such identity: /home/motor/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

そして、パスワードプロンプト。

sshcentos7
15
Larry Martell

あなたの/etc/ssh/sshd_configリモートサーバーでは、オプションGSSAPIAuthenticationをnoに変更する必要があります。 sshdを再起動してください。

編集：GSSAPI（汎用セキュリティサービスアプリケーションプログラミングインターフェイス）は、基本的にKerberosライブラリを利用して強力なネットワーク暗号化を提供するAPIです。 GSSAPIを有効にする必要がある特別な理由がない限り、この方法で問題を解決できます。

edit2：明確にするために、逆DNSチェックがタイムアウトしている可能性もあります（特に、接続しているホストのPTRレコードをチェックしています）。 SSHは、接続しているホストを検証するためのセキュリティ手段として機能するため、当然このチェックを行います。

とはいえ、実際にはとにかくPTRを持たないホストのかなりの割合が存在するため、このプロセスは実際のセキュリティの点でそれほど追加されません。この問題を修正するには3つの方法があります。

1）。 sshd_configファイルを使用してUseDNS noパラメータ。これにより、逆DNSルックアップが停止します。安全です。

2）。接続が遅いホストの適切なDNSシステムにPTRレコードを追加します。

3）。 OS hostsファイルに、関連するエントリを含む手動エントリを追加します。

お役に立てば幸いです。

16
Brett Levene

これはDNSの問題のように聞こえます。ログイン試行中に、DNSの逆ルックアップが実行され、認証ログにリモートホスト名が提供されます。

サーバーの/etc/resolv.confファイルに応答しないリゾルバーがないことを確認してください。

4
Admin