使用 CentOS7 登录时延迟较长

Question

我有一个 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

然后是密码提示。

Answer 1

在/etc/ssh/sshd_config远程服务器上，您应该将选项更改GSSAPIAuthentication为 no。重新启动 sshd，您应该一切顺利。

编辑：GSSAPI（通用安全服务应用程序编程接口）本质上是一个 API，它利用 Kerberos 库提供强大的网络加密。除非有特殊原因需要启用 GSSAPI，否则此方法应该可以解决您遇到的问题。

edit2：为清楚起见，也有可能是反向 DNS 检查超时（特别是检查连接主机的 PTR 记录）。SSH 理所当然地执行此检查，因为它充当验证连接主机的安全措施。

也就是说，这个过程在真正的安全性方面并没有增加太多，因为实际上有很大一部分主机无论如何都没有 PTR。有三种方法可以解决此问题：

1）。您可以修改sshd_config文件以使用该UseDNS no参数。这将停止反向 DNS 查找。这样做是安全的。

2）。在适当的 DNS 系统中为连接缓慢的主机添加 PTR 记录。

3）。将手动条目添加到hosts具有相关条目的 OS文件中。

希望有帮助！

Answer 2

这听起来像是 DNS 问题 - 在尝试登录期间，执行反向 DNS 查找以在身份验证日志中提供远程主机名。

检查以确保服务器文件中没有无响应的解析器/etc/resolv.conf。