排查Ubuntu系统auth.log中大量kex_exchange_identification错误的方法

嘿，碰到这种满屏的错误日志确实让人头大！我来给你分享几个实用的排查步骤，帮你精准定位到底哪个进程在搞事情：

• 先锁定错误的上下文信息
  先实时追踪auth.log的相关日志，看看有没有额外线索：

  tail -f /var/log/auth.log | grep "kex_exchange_identification"
  

  这能帮你看到错误发生时的时间戳、关联IP，甚至其他附带的日志信息，缩小排查范围。

• 排查网络连接与SSH相关进程

  • 先用工具查看当前系统中与SSH相关的进程和连接状态，推荐用更高效的ss命令：

    sudo ss -tulpn | grep ssh
    

    这里能看到进程的PID、监听端口等信息，留意有没有陌生的进程或者异常的连接。
  • 如果怀疑是外部发起的异常连接，用tcpdump抓包分析SSH端口的流量：

    sudo tcpdump -i any port 22 -v
    

    通过抓包能看到客户端发送的数据包内容，判断是不是非法请求或者异常客户端导致的错误。

• 追踪本地可疑进程

  • 列出所有与SSH相关的本地进程，检查有没有异常：

    ps aux | grep ssh
    

    重点看进程的命令行参数和所属用户，陌生的进程就是重点排查对象。
  • 找到可疑PID后，用strace追踪它的系统调用，看是不是在频繁发起SSH连接：

    sudo strace -p [可疑PID]
    

    从输出里能清晰看到进程的行为，确认它是不是错误的源头。

• 检查SSH服务配置与日志级别

  • 检查sshd_config里的Banner配置，有时候Banner文件包含特殊字符会触发这个错误：

    cat /etc/ssh/sshd_config | grep Banner
    

    如果配置了Banner，去查看对应文件的内容，确认没有无效字符。
  • 临时提高SSH日志级别获取更详细信息：编辑/etc/ssh/sshd_config，把LogLevel改成DEBUG3，然后重启服务：

    sudo systemctl restart sshd
    

    之后再查看auth.log，就能得到更细致的错误细节，帮你快速定位问题。排查完成后记得把日志级别改回默认的INFO，避免日志爆炸。

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