Building the Coming Soon

关于

HFLS aka the Akademia 12′, then NJUST 16′, now HKU.

SSH

重新生成SSH服务器端密钥方法

09/20/2015

理论上来说,每次安装服务器时SSH密钥(SSH Host Key)都是自动生成的,而生成出相同密钥的概率接近于0,这样避免了中间攻击等情况。但是,就是存在以下情况使得两台SSH密钥相同:

  • 在虚拟化技术中克隆了一台虚拟机;
  • 将原来的虚拟硬盘复制后新建虚拟机运行。

当然还有其他更加坑爹的情况,比如Kaijia碰到的VPS云服务器重装系统复制完模板数据后不重新生成SSH密钥的(某国内主流云提供商……),于是整个云平台所有的VPS都跑着相同的SSH密钥,如果要实现中间攻击只需要新建一台云就能获得私钥了。正是因为碰到了这种云主机,Kaijia研究了一下如何重新生成SSH服务器端密钥。

阅读更多

SSH Channel“open failed: connect failed: Connection timed out”问题解决

09/07/2015

在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)以增加收到数据包的概率。

阅读更多

解决Rsync使用非默认端口SSH问题

10/01/2012

Kaijia使用Rsync将这个博客的图片、视频等文件同步到另外一台下载服务器上。Rsync通过SSH传输,出于安全性考虑SSH不应使用默认的22端口,但是Rsync没有提供更换端口的选项,所以Kaijia一开始只能将文件服务器的SSH设为默认端口。今天通过Google终于解决了这个问题。

阅读更多

... 载入更多文章 ...

- 已经载入全部文章 -