SSH间歇性长时间连接延迟的排查及服务器端日志查询咨询

这种间歇性的SSH连接延迟确实挺折腾人的，结合你给出的debug日志，卡在debug1: pledge: filesystem到debug3: receive packet: type 80之间的阶段，确实大概率是服务器端在处理初始连接请求时出现了阻塞，我给你梳理几个常见的排查方向和查看服务器端日志的方法：

一、先排查最常见的服务器端配置问题 #

这些都是我碰到过很多次的“坑”，可以先快速验证：

• DNS反向解析超时：SSH服务器默认会尝试反向解析客户端的IP地址来获取主机名，要是服务器的DNS配置有问题、或者DNS服务器偶尔不可用，就会出现这种间歇性延迟。你可以登录到Linux工作站，修改/etc/ssh/sshd_config文件，找到UseDNS选项（如果没有就添加一行），改成：

  UseDNS no
  

  然后重启sshd服务：sudo systemctl restart sshd（如果是老系统可能用sudo service ssh restart），之后再观察连接情况。
• GSSAPI认证超时：如果服务器开启了GSSAPI认证，但你的Mac客户端没对应配置，也可能触发超时。同样在sshd_config里找到GSSAPIAuthentication，改成no，重启服务试试。
• PAM模块阻塞：SSH依赖PAM做用户认证，某些PAM模块（比如pam_systemd、涉及用户目录挂载的模块）如果遇到资源问题（比如NFS挂载的home目录响应慢），也会卡住连接请求。你可以临时简化PAM的sshd配置（比如备份/etc/pam.d/sshd后，注释掉非必要的模块），测试是否还会延迟。
• 服务器资源瓶颈：延迟发生时，在工作站上用top、vmstat、iostat看看CPU、内存、磁盘IO是不是突然占满了——有时候后台进程突发占用资源，会导致sshd无法及时处理连接。

二、查看服务器端的SSH日志，定位具体问题 #

要搞清楚服务器端到底在卡什么，看日志是最直接的方法：

• 默认日志位置：
  • Debian/Ubuntu系：日志存在/var/log/auth.log，可以用tail -f /var/log/auth.log实时跟踪，然后发起SSH连接，看延迟期间有没有报错或者超时的日志条目。
  • RHEL/CentOS系：日志在/var/log/secure，同样用tail -f实时查看。
• 开启详细日志：如果默认日志不够详细，修改sshd_config里的LogLevel选项，改成DEBUG或者VERBOSE：

  LogLevel DEBUG
  

  重启sshd后，日志会记录连接处理的每一步，能帮你精准定位到卡在哪一步（比如DNS解析、PAM认证阶段）。注意调试完成后改回默认的INFO，避免日志占用过多磁盘空间。
• Systemd日志系统：如果你的工作站用systemd管理服务，可以用journalctl直接跟踪sshd的日志：

  journalctl -u sshd -f
  

  这个命令会实时输出sshd的所有日志，包括一些可能没写到传统日志文件里的细节。

先从修改UseDNS开始试吧，这个是最常见的间歇性SSH延迟原因，很多时候改完就解决问题了。

备注：内容来源于stack exchange，提问作者jacobsa