为什么我的SSH登录速度很慢？

试着将UseDNS中的no或/etc/sshd_config设置为/etc/ssh/sshd_config。

当我在一台性能同样很慢的服务器上运行ssh -vvv时，我看到这里挂了。

debug1: Next authentication method: gssapi-with-mic

通过编辑/etc/ssh/ssh_config并注释掉那个验证方法 我让登录性能恢复到了正常水平。下面是我在服务器上的/etc/ssh/ssh_config中的内容。

GSSAPIAuthentication no

你可以在服务器上全局设置这个，所以它不接受GSSAPI来验证。只要在服务器上的GSSAPIAuthentication no中加入/etc/ssh/sshd_config，然后重启服务即可。

对我来说，罪魁祸首是IPv6解析，它是定时的。(我猜，我的主机提供商的DNS设置不好。)我通过做ssh -v发现了这个问题，它显示了哪一步被挂起。

解决方法是用ssh选项进行-4。

ssh -4 me@myserver.com

使用systemd，在升级后，登录时可能会在与logind的dbus通信中挂起，然后你需要重启logind

systemctl restart systemd-logind

在debian 8、arch linx和suse列表中看到过这种情况。

你可以随时用ssh选项启动-v，它可以显示当前正在做的事情。

$ ssh -v you@host

根据你提供的信息，我只能建议一些客户端的配置。

-由于你写道你是手动输入密码，我建议你尽可能使用公钥认证。这样可以消除你这个速度瓶颈。

• 你也可以用-x禁用X转发，用-a禁用验证转发（这些可能已经被默认禁用了）。特别是如果你的客户端需要为ssh命令启动X服务器，禁用X转发可以给你带来很大的速度提升（例如在OS X下）。

其他一切真的取决于你在何时何地遇到什么样的延迟。

关于第2点，这里有一个不需要修改服务器也不需要root/administrative权限的答案。

你需要编辑你的 “用户ssh/_config "文件，它是：

vi $HOME/.ssh/config

(注意：如果$HOME/.ssh不存在，你必须创建这个目录)

添加：

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

如果需要的话，你可以在每个主机上这样做：) 例如：

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

确保IP地址与你的服务器IP一致。一个很酷的好处是，现在ssh将为这个服务器提供自动编译功能，所以你可以键入ssh lin +1& 0x1&

确保IP地址与服务器IP一致。所以你可以输入Tab+ssh linux-srv，它应该会自动完成0x6&。

检查服务器上的/etc/resolv.conf，确保这个文件中列出的DNS服务器工作正常，并删除所有不工作的DNS。

有时候会很有帮助。

除了已经提到的DNS问题之外，如果你ssh'ing进入一个有很多NFS挂载的服务器，那么在密码和提示之间可能会有延迟，因为quota命令会检查你在所有没有用noquota挂载的文件系统上的使用量/配额。在Solaris系统中，你可以在默认的/etc/profile中看到这一点，并通过运行touch $HOME/.hushlogin跳过它。

如果以上答案都不行，而你又面临着dns反向查询的问题，你也可以检查nscd（名称服务缓存守护进程）是否安装并运行。

如果是这个问题，那是因为你没有dns缓存，每次查询主机文件上没有的主机名时，你都会把问题发送给你的名称服务器，而不是在你的缓存中查找

我尝试了以上所有的选项，唯一有效的改变是启动nscd。

你还应该验证一下在/etc/nsswitch.conf中进行dns查询解析的顺序，先使用hosts文件。

这可能只针对 Debian/Ubuntu OpenSSH，它包含了由 Debian 软件包维护者编写的 user-group-modes.patch。这个补丁允许 ~/.ssh 文件的组可写位设置 (g+w)，如果只有一个用户和文件的 gid 相同的话。这个补丁的secure/_permissions()函数会进行这个检查。其中一个阶段是使用getpwent()来检查每一个passwd条目，并比较该条目的gid和文件的gid。

在一个有很多条目和/或慢速NIS/LDAP认证的系统中，这个检查会很慢。nscd不缓存getpwent()调用，所以如果服务器不是本地的，每个passwd条目都会通过网络读取。在我发现的系统中，每次调用ssh或登录系统都会增加4秒左右的时间。

修复方法是将~/.ssh中所有文件的可写位去掉，方法是做chmod g-w ~/.ssh/*。

注：这开始是一个 “如何调试 "的教程，但最后是在Ubuntu 16.04 LTS服务器上帮助我的解决方案。

TLDR 。运行landscape-sysinfo，检查该命令是否需要很长时间才能完成，这是新的SSH登录时的系统信息打印输出。注意，这个命令并不是在所有系统上都可用，landscape-common包会安装它。("但是，等等，还有……”)

• *

在出现问题的机器上的另一个端口上启动第二个ssh服务器，在调试模式下进行，这样不会使其分叉，并且会打印出调试信息。

sudo /usr/sbin/sshd -ddd -p 44321

在另一台机器上以verbose模式连接到那个服务器上:

ssh -vvv -p 44321 username@server

我的客户机在开始睡眠前输出了以下几行：

debug1: Entering interactive session.
debug1: pledge: network

Googling并没有什么帮助，但服务器的日志比较好。

debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051

我注意到当我把UsePAM yes改为UsePAM no时 这个问题就解决了。

与UseDNS或其他设置无关，只有UsePAM影响我系统的这个问题。

我不知道为什么，我也没有把UsePAM留在no，因为我不知道副作用是哪些，但这让我继续调查。

所以请不要认为这是一个答案，而是开始查找问题的第一步。

于是我继续调查，用sshd运行strace (sudo strace /usr/sbin/sshd -ddd -p 44321)。这得到了以下结果。

sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385

这一行/etc/update-motd.d让我产生了怀疑，显然这个进程在等待/etc/update-motd.d

中的东西的结果，于是我cd进入/etc/update-motd.d，并运行了一个sudo chmod -x *，以抑制PAM运行所有产生这个动态Message Of The Day的文件，其中包括系统加载和是否需要升级包，这就解决了问题。

这是一台基于 “节能 "的N3150 CPU的服务器，它有很多工作要24小时不间断地进行，所以我认为收集所有这些motdata对它来说实在是太多了。

我可能会开始有选择地启用该文件夹中的脚本，看看哪些危害较小，但专门调用landscape-sysinfo非常慢，而且50-landscape-sysinfo确实会调用该命令。我想这是造成最大延迟的一个问题。

在重新启用大部分文件后，我得出的结论是50-landscape-sysinfo和99-esm是造成我麻烦的原因。50-landscape-sysinfo的执行时间约为5秒，99-esm约为3秒。其余的文件总共花了2秒左右。

50-landscape-sysinfo和99-esm都不是关键。50-landscape-sysinfo可以打印出有趣的系统统计信息（也可以在你空间不足的时候打印！），99-esm可以打印出与Ubuntu Extended Security Maintenance相关的信息

最后你可以用echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh创建一个脚本，并在请求时获得该打印结果。

我尝试了所有的答案，但都没有用。最后我发现了我的问题：

首先我运行sudo tail -f /var/log/auth.log所以我可以看到ssh的日志，然后在另一个会话中运行ssh 172.16.111.166并注意到等待

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

经过搜索，我找到了/etc/ssd/ssh/_config中的这行

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

我注释了它，延迟消失了。

工作正常。

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS no 不能和OpenIndiana一起工作 !!!

阅读 “man sshd_config” 查看所有的选项

“LookupClientHostnames no” 如果你的服务器不能解析的话

ssh -vvv连接真的很好，直到它挂在系统上试图获得终端至少20秒。

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
... waiting ... waiting ... waiting

在服务器上做了systemctl restart systemd-logind **后，我又有了即时连接！

这是在debian8上进行的! 所以systemd是这里的问题!

注：Bastien Durel已经给出了这个问题的答案，不过缺少调试信息。希望对大家有所帮助。

我们可能会发现，首选的名称解析方法不是主机文件，然后是DNS。

例如，这将是通常的配置。

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts: db files nisplus nis dns
hosts: files dns myhostname

首先是主机文件(选项: files)，然后是DNS(选项: dns)，但是我们会发现又增加了一个没有运行的名字解析系统，导致我们在进行反向解析时速度很慢。

如果名称解析顺序不正确，可以在以下位置更改。/etc/nsswitch.conf

摘自： http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html。

这个帖子已经提供了一堆解决方案，但我的解决方案没有在这里给出=）。) 所以这里是。我的问题（花了大约1分钟ssh登录到我的raspberry pi），是由于一个损坏的.bash\history文件。由于该文件在登录时被读取，所以导致了登录延迟。一旦我删除了这个文件，登录时间就恢复了正常，就像瞬时一样。

希望能帮到其他一些人。

要完成所有显示DNS解析会减慢你的ssh登录速度的答案，有时候，缺少一个防火墙规则。例如，如果你默认DROP所有INPUT paquets

iptables -t filter -P INPUT DROP

，那么你就必须接受SSH端口的INPUT和DNS请求

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
```。

最近我发现了另一个导致ssh登录慢的原因。

即使你在UseDNS no里有/etc/sshd_config，如果/etc/hosts.deny里有类似的条目，sshd仍然可能会执行反向DNS查找。

nnn-nnn-nnn-nnn.rev.some.domain.com

如果你的系统中安装了DenyHosts，这种情况就会发生。

如果有人知道如何让DenyHosts避免在/etc/hosts.deny中加入这种条目，那就太好了。

这里有一个链接，指向 DenyHosts FAQ ，关于如何删除/etc/hosts.deny中的条目 - 请看 如何删除一个被DenyHosts封锁的IP地址？ 。

我发现重新启动systemd-logind.service只能解决几个小时的问题。将sshd/config中的UsePAM从 “是 "改成 "否"，虽然不再显示motd，但还是实现了快速登录。关于安全问题的评论？

对我来说，我的本地/etc/hosts文件有问题。所以ssh尝试了两个不同的IP(一个是错的)，花了很长时间才超时。

使用ssh -v解决了这个问题。

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.

对我来说，我需要GSSAPI，而且我不想关闭反向DNS查询。这似乎不是一个好主意，所以我检查了resolv.conf的主页面，发现我和我SSH连接的服务器之间的防火墙干扰了DNS请求。结果发现，我和我SSHing到的服务器之间的防火墙干扰了DNS请求，因为它们不是防火墙所期望的形式。最后，我只需要在SSHing到的服务器上的resolv.conf中添加这一行。

options single-request-reopen

值得注意的是，在CentOS 7上对bind进行的一次包更新破坏了named，现在在日志中说明/etc/named.conf有权限问题。几个月来，它一直用0640工作得很好，现在却要0644。现在它想要0644。这是有道理的，因为 named 守护进程是属于'named'用户的。

随着named的宕机，一切都很慢，从ssh登录到本地web服务器的页面服务，迟钝的LAMP应用程序等，很可能是因为每个请求都会在死掉的本地服务器上超时，然后再查找到配置的外部二级DNS。