理论上来说，每次安装服务器时SSH密钥（SSH Host Key）都是自动生成的，而生成出相同密钥的概率接近于0，这样避免了中间攻击等情况。但是，就是存在以下情况使得两台SSH密钥相同：
当然还有其他更加坑爹的情况，比如Kaijia碰到的VPS云服务器重装系统复制完模板数据后不重新生成SSH密钥的（某国内主流云提供商……），于是整个云平台所有的VPS都跑着相同的SSH密钥，如果要实现中间攻击只需要新建一台云就能获得私钥了。正是因为碰到了这种云主机，Kaijia研究了一下如何重新生成SSH服务器端密钥。
在Hyper-V的虚拟机里面运行Linux网络性能果真要比KVM差一些，当然此间原因很多：驱动、NAT转换效率等等。这次Kaijia遇到的大量“open failed: connect failed: Connection timed out”问题，最后看来也是连接性能原因。
Kaijia用SSH转Socket连接到不同地区的IP，然后进行检测和数据采集，同时所有连接同时有流量传输，一开始一切正常，但是Socket运行时间久后就会慢慢出现“open failed: connect failed: Connection timed out”错误提示。于是Kaijia开启调试模式分析了一下错误信息，看到了很多类似以下的信息：
debugx: channel x: open confirm rwindow ?? rmax ??
channel x: open failed: connect failed: Connection timed out
debugx: channel x: free: direct-tcpip: listening port xxxxx for xxx.xxx.xxx.xxx port 80, connect from 172.16.1.xxx port xxxxx to 172.16.1.xxx port xxxxx, nchannels x
debugx: channel x: zombie
debugx: channel x: garbage collecting
debugx: channel x: read failed
debugx: channel x: close_read
debugx: channel x: input open -> drain
debugx: channel x: ibuf empty
debugx: channel x: send eof
debugx: channel x: input drain -> closed
结合错误提示，网上搜了一些，很好理解即连接在允许的时间内没有收到任何信息，于是发送了EOF结束，返回了连接超时错误，因此可以说是连接的性能问题。根本上解决问题是比较困难的，涉及到很多方面因素，比较现实的解决方法便是延长等待时间，避免连接超时（Timeout）以增加收到数据包的概率。
- 已经载入全部文章 -
近期评论