登录时等待时间过长
当我登录我的服务器时，我得到了这个：
No mail. Last login: Fri Nov 5 14:22:45 2010... 然后我必须等待5秒然后准备好……
wolfy@ubuntu-server:~$
这个等待时间是正常还是我应该做些什么来“修复”这个？
这通常是pam_motd重新生成/etc/motd文件的结果。 您可以检查/etc/update-motd.d的各个脚本以查看某些内容是否特别慢。
我对10.04（LTS）也有同样的问题。
当我用-vvv运行我的ssh时，它会死于：
debug1: Entering interactive session.
扩展这个答案。
我设法远程重启服务器并启用了DEBUG登录。 也利用这个机会保持登录并观察其他登录尝试。 这是发生了什么。 客户端连接并被授权并挂起以上消息。
在服务器上，进程列表显示：
root 835 0.0 0.1 11476 3348 ? Ss 13:39 0:00 sshd: till [priv] root 840 0.0 0.0 4804 1124 ? S 13:39 0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d root 841 0.0 0.0 4728 1108 ? S 13:39 0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d root 854 0.0 0.0 4804 1144 ? S 13:39 0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo root 861 0.2 0.5 15388 9248 ? S 13:39 0:00 /usr/bin/python /usr/bin/landscape-sysinfo root 863 0.0 0.0 0 0 ? Z 13:39 0:00 [who]
我可以在登录时执行/usr/bin/python /usr/bin/landscape-sysinfo ，但出于某种原因，我无法弄清楚为什么它会停止登录过程。 当我终止进程时，登录会继续提示并成功 。
这似乎不是一个ssh（d）问题，它与update-motd和landscape更相关。 我卸载了update-motd软件包，但似乎/etc/update-motd目录仍然存在且脚本仍然执行 – 导致进程挂起。
进一步解决这个问题：
原来/etc/update-motd.d/目录并不真正属于包update-motd ，它似乎是通过sshd的pam身份validation触发的。
我好像已经钉了它！
已禁用以下文件中的pam_motd：
- 上将/etc/pam.d/sshd
- /etc/pam.d/login文件
多一个：
apt-get purge landscape-client landscape-common
这似乎在一定程度上有所帮助。 虽然， 它只删除了/etc/update-motd.d/中的违规脚本，既没有删除该目录中的所有脚本，也没有删除pam_motd 。
一般来说，我发现没有办法完全禁用pam_motd因为无论它做什么，它都会使登录过程减慢到一定程度。 它不会像landscape-common的脚本一样阻塞，但速度较慢。
有关此问题的错误报告：
解决方法来自那里：
你是对的，登录的能力比提出一个motd更重要。 如果此行为对您来说是个问题，有几种方法可以禁用它：
- 如果您不想显示motd，请在
/etc/pam.d/sshd注释掉’pam_motd’行。- 删除
/etc/update-motd.d目录的内容。- chmod -x你不想运行的
/etc/update-motd.d中的脚本。
最后找到解决方案：
-
sudo apt-get remove landscape-client landscape-common - 注释行
session optional pam_motd.so在/etc/pam.d/login和/etc/pam.d/sshd
现在登录即时！
根据您的描述，这听起来更像是一个网络问题。 诊断：
- 使用-v参数运行ssh是详细的。
- 尝试对您要连接的SSH服务器运行ping，并查看它是否同时挂起。
- 尝试其他类型的传输到同一台服务器。 例如，wget使用–limit-rate参数通过HTTP获取文件，并且需要足够长的时间才能触发“挂起”行为。
- 看看它是否只在空闲时挂起，或者即使你现在正在做某事。 如果它在空闲时挂起，-v诊断程序可能会告诉你，在这种情况下使用keepalive的建议可能有所帮助（ssh -o“TCPKeepAlive yes”）
如果你可以用Windows和PuTTY连接OK，那么它可能不是服务器端的问题。
我想当你登录时，ubuntu会执行以下一个或多个文件：
/etc/bash.bashrc ~/.bash_profile ~/.bashrc
你可以看到它们里面有什么，甚至可以尝试执行它们，看看它们花了这么长时间。
在我有限的经验中，当putty工作时，但Linux，Ubuntu在这种情况下不会，它通常会保持活力。 网络或服务器问题会影响客户端操作系统。
您可以在命令行上使用上面的keep alive选项，但输入有点繁琐。
更容易编辑一些配置文件。
如果您具有root access ，并希望为所有用户自动启用它，请编辑/etc/ssh/ssh_config ，添加
KeepAlive yes ServerAliveInterval 120
如果您没有root访问权限，或者为单个用户启用它，请编辑~/.ssh/config并添加相同的两行。
如果同时启用了PermitEmptyPassword和UsePAM ，则OpenSSH服务器始终使用空密码尝试身份validation，这表示不需要对相关帐户进行身份validation。 一旦身份validation过程开始，它就会在两个协议中执行此操作，而不会响应来自客户端的任何“真实”身份validation请求。 如果设置了sshd_config标志PermitEmptyPassword OpenSSH将仅允许此类访问; 不幸的是，编写代码的方式，它在任何情况下都执行密码测试，因此显示为失败的PAM。
所以：禁用PermitEmptyPassword或UsePAM ，但请记住： 没有PAM，你将无法在没有密钥的情况下登录。
参考： https ： //groups.google.com/forum/？fromgroups =＃！topic / comp.security.ssh / wExY8lWlG-c
检查/ var / log中的系统日志，您可能会发现一条带有相关错误/超时的消息。
如果你还有一段时间等待
编辑/etc/sshd_config
并设置（或添加）
UseDNS no
或者在/etc/hosts添加你的ip，如果它是静态本地的
您可能希望在从已登录的连接（或其他控制台）登录服务器时尝试监视正在运行的进程。 有可能发现哪些进程最活跃或当时使用的CPU最多。
以下是一种可能的方法：
- 尝试登录其他控制台。
- 在那里跑
top看看会发生什么。 - 登录第一个控制台。
请注意，如果延迟不是由一些CPU密集型计算引起的，那么您将不会发现任何不合适的地方。 这种情况下问题可能是I / O绑定（等待某些磁盘读/写或网络响应）。