Uptime-Kuma监控SSH端口时产生密钥交换错误日志的分析

问题背景

在使用Uptime-Kuma的TCP端口监控功能对SSH服务(22端口)进行监控时，被监控服务器会记录大量"key_exchange_identification"错误日志。虽然服务状态显示正常，但这些错误日志可能会干扰正常的日志分析工作。

技术原理分析

Uptime-Kuma的TCP端口监控功能底层使用了tcp-ping库实现。该库的工作机制是：当TCP连接被接受后立即断开连接，然后立即进行新的测量。这种设计初衷是为了快速检测端口是否开放，而不是进行完整的协议交互。

与SSH服务的交互过程

当Uptime-Kuma监控SSH端口时，会发生以下交互：

1. 客户端(Uptime-Kuma)向服务器22端口发起TCP连接
2. 服务器接受连接并开始SSH协议握手
3. 在密钥交换阶段，客户端突然断开连接
4. 服务器记录"error: kex_exchange_identification: Connection closed by remote host"错误

与专业端口扫描工具的区别

专业端口扫描工具(如NMAP)在仅检测端口开放状态时有两种工作模式：

1. 仅发送SYN包，检测是否收到SYN-ACK响应(半开放扫描)
2. 完成TCP三次握手后立即发送FIN包终止连接

这两种方式都不会触发SSH协议层的错误日志，因为它们不会进入SSH协议握手阶段。

解决方案建议

对于需要监控SSH端口的用户，可以考虑以下方案：

1. 使用ICMP Ping监控替代：如果只需要确认主机在线状态，可以使用ICMP Ping监控而非TCP端口监控

2. 调整SSH服务日志级别：修改sshd_config中的日志级别，过滤掉这类预期内的连接中断

3. 使用专用SSH监控插件：如果需要完整监控SSH服务可用性，建议开发专门的SSH监控插件，正确处理协议交互

总结

Uptime-Kuma的TCP端口监控功能设计初衷是快速检测端口开放状态，而非完整协议交互。对于SSH等需要复杂握手的服务，这种监控方式会产生预期内的错误日志。用户应根据实际需求选择合适的监控方式，或在服务器端调整日志记录策略。