2010-07-22 07:02:00 +0000 2010-07-22 07:02:00 +0000
103
103
Advertisement

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

Advertisement

我看到SSH登录时有延迟。具体来说,有两个地方我看到了从瞬时到多秒的延迟。

1.在发出ssh命令和得到登录提示之间, 2.在输入口令和让shell加载之间

现在,我在这里特别只看ssh细节。很明显,网络延迟、硬件和操作系统的速度、复杂的登录脚本等都会造成延迟。作为背景,我通过ssh连接到大量的linux发行版和一些Solaris主机,主要使用Ubuntu、CentOS和MacOS X作为我的客户端系统。几乎所有的时候,ssh服务器的配置都没有改变操作系统的默认设置。

我应该关注哪些ssh服务器配置?是否有操作系统/内核参数可以调整?登录shell的技巧?等等等等?

Advertisement

答案 (22)

130
130
130
2010-07-22 08:38:59 +0000

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

39
39
39
2010-09-22 17:42:34 +0000

当我在一台性能同样很慢的服务器上运行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,然后重启服务即可。

21
Advertisement
21
21
2015-08-14 00:50:20 +0000

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

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

ssh -4 me@myserver.com

16
16
16
2015-05-21 09:41:03 +0000

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

systemctl restart systemd-logind

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

9
Advertisement
9
9
2010-07-22 08:28:05 +0000

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

$ ssh -v you@host

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

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

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

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

7
7
7
2012-06-29 07:41:22 +0000

关于第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&。

4
Advertisement
4
4
2017-06-08 07:57:20 +0000

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

有时候会很有帮助。

2
2
2
2010-07-22 14:24:59 +0000

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

1
Advertisement
1
1
2013-05-02 23:01:07 +0000

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

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

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

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

1
1
1
2015-10-13 01:19:43 +0000

这可能只针对 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/*

1
Advertisement
1
1
2018-11-20 19:15:56 +0000

注:这开始是一个 “如何调试 "的教程,但最后是在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-sysinfo99-esm是造成我麻烦的原因。50-landscape-sysinfo的执行时间约为5秒,99-esm约为3秒。其余的文件总共花了2秒左右。

50-landscape-sysinfo99-esm都不是关键。50-landscape-sysinfo可以打印出有趣的系统统计信息(也可以在你空间不足的时候打印!),99-esm可以打印出与Ubuntu Extended Security Maintenance相关的信息

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

1
1
1
2017-07-22 08:21:56 +0000

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

首先我运行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

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

1
Advertisement
1
1
2012-04-25 13:37:42 +0000

工作正常。

# 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” 如果你的服务器不能解析的话

1
1
1
2017-03-04 22:38:38 +0000

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已经给出了这个问题的答案,不过缺少调试信息。希望对大家有所帮助

1
Advertisement
1
1
2017-07-09 09:12:53 +0000

我们可能会发现,首选的名称解析方法不是主机文件,然后是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
1
1
2018-01-03 15:02:47 +0000

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

希望能帮到其他一些人。

1
Advertisement
1
1
2016-12-06 09:24:08 +0000

要完成所有显示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
```。
1
1
1
2016-10-24 21:49:02 +0000

最近我发现了另一个导致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地址?

1
Advertisement
1
1
2016-07-13 22:35:37 +0000

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

0
0
0
2015-05-21 13:01:07 +0000

对我来说,我的本地/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.
0
Advertisement
0
0
2014-08-28 11:41:40 +0000

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

options single-request-reopen

0
0
0
2016-12-13 17:07:11 +0000

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

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

Advertisement