我们有一个客户端服务器设置,客户端build立一个SSH隧道并使用端口转发向服务器发送数据:
ssh -N -L 5000:localhost:5500 user@serveraddress
在服务器上正常的SSH连接数是150,而一切正常,服务器软件处理传入连接相当快(最多几秒钟)。
但是,最近我们已经注意到SSH连接的数量上升到了900+。 此时,服务器软件将连接到它并接受这些连接,但是没有数据进入。
有没有人用SSH看过这样的症状? 任何想法可能是什么问题?
Server OS: Red Hat Linux 5.5 Firewall: Disabled Key Exchange: Tested
编辑 :从服务器端的/ var / log / secure中添加部分日志数据
在日志文件中似乎有很多以下内容。
Apr 10 00:07:33 myserver sshd[15038]: fatal: Write failed: Connection timed out Apr 10 00:12:01 myserver sshd[5259]: fatal: Read from socket failed: Connection reset by peer Apr 10 00:44:48 myserver sshd[17026]: fatal: Write failed: No route to host Apr 10 02:09:16 myserver sshd[10398]: fatal: Read from socket failed: Connection reset by peer Apr 10 02:22:47 myserver sshd[24581]: fatal: Read from socket failed: Connection reset by peer Apr 10 03:05:57 myserver sshd[12003]: fatal: Read from socket failed: Connection reset by peer Apr 10 03:23:19 myserver sshd[22421]: fatal: Write failed: Connection timed out Apr 10 08:13:43 myserver sshd[31993]: fatal: Read from socket failed: Connection reset by peer Apr 10 08:36:39 myserver sshd[7759]: fatal: Read from socket failed: Connection reset by peer Apr 10 09:02:32 myserver sshd[12470]: fatal: Write failed: Broken pipe Apr 10 12:08:05 myserver sshd[728]: fatal: Write failed: Connection reset by peer Apr 10 12:35:53 myserver sshd[6184]: fatal: Read from socket failed: Connection reset by peer Apr 10 12:43:14 myserver sshd[2663]: fatal: Write failed: Connection timed out
说明 :900+连接大概10-15分钟后,系统会自行恢复 – 连接数将下降到正常范围,服务器将重新开始获取数据。 这听起来像一个DOS / DDOS,但这是在一个内部networking。
附录 :根据@ kranteg的问题检查连接状态。 我们又有一次中断,这些都是基于我为所有传入的SSH连接写的脚本的结果:
=== Tue Apr 15 12:22:07 EDT 2014 -> Total SSH connections: 996 === 0 SYN_SENT 1 SYN_RECV 0 FIN_WAIT1 0 FIN_WAIT2 15 TIME_WAIT 0 CLOSED 760 CLOSE_WAIT 143 ESTABLISHED 77 LAST_ACK 0 LISTEN 0 CLOSING 0 UNKNOWN === === Tue Apr 15 12:22:17 EDT 2014 -> Total SSH connections: 977 === 0 SYN_SENT 2 SYN_RECV 1 FIN_WAIT1 0 FIN_WAIT2 15 TIME_WAIT 0 CLOSED 756 CLOSE_WAIT 127 ESTABLISHED 76 LAST_ACK 0 LISTEN 0 CLOSING 0 UNKNOWN === === Tue Apr 15 12:22:26 EDT 2014 -> Total SSH connections: 979 === 0 SYN_SENT 2 SYN_RECV 1 FIN_WAIT1 0 FIN_WAIT2 12 TIME_WAIT 0 CLOSED 739 CLOSE_WAIT 148 ESTABLISHED 77 LAST_ACK 0 LISTEN 0 CLOSING 0 UNKNOWN ===
看起来CLOSE_WAIT的连接数量有所增加。 在“正常”操作期间, CLOSE_WAIT的数字为0或非常接近。
我不知道这是否是正确的解决scheme,但它为我们工作。 希望至less可以将其他人指向正确的方向,即使它没有完全解决。
我们注意到,每当我们中断,处理器使用率接近100%。 这反过来又是因为另一个应用程序批处理某些文件,并占用了大部分CPU。 我们把这个过程关掉了,到目前为止还没有停机。 我真的不知道这是否是根本原因,但它对我们有所帮助。 从那以后没有一次中断。
这听起来像你的客户端应用程序启动隧道可能没有正确closures连接完成写操作后。