使用带有obfuscated handshake的ssh



连不上ssh有一段时间了,因要出去玩,也就没在意它,回来后发现还是如此,看来是哪里出问题了。

服务器地址说明,多了个混淆SSH端口,是443和2222,一开始没在意混淆的概念,以为就是端口地址变了,就在命令上指定了“-p 443”,但还是连接不上。

再细注意,发现还有个混淆加密密钥,而man ssh居然没有这个obfuscated。才感觉需要探究一下这混淆是啥意思呢?

DZF上有一篇Obfuscated ssh的安装说明,而在obfuscated-openssh介绍到Handshake obfuscation,握手混淆,通过混淆加密key来加强了初始的SSH握手。越来越复杂了。

obfuscated-openssh在openssh客户端上增加了obfuscated handshake协议,客户端会多两个-z,-Z的参数。不管那么多,按提示先装一个:

$ wget -o ofcssh.zip https://github.com/brl/obfuscated-openssh/archive/master.zip
$ unzip ofcssh.zip
$ cd obfuscated-openssh-master
$ ./configure
</pre> 结果不幸出现错误如下: <pre>
checking OpenSSL header version… 90812f (OpenSSL 0.9.8r 8 Feb 2011)
checking OpenSSL library version… 90818f (OpenSSL 0.9.8x 10 May 2012)
checking whether OpenSSL’s headers match the library… no
configure: error: Your OpenSSL headers do not match your
library. Check config.log for details.
</pre> 又是这该死的openssl,之前记得用brew装过openssl: $ brew list openssl 果然,还是1.0.1e版,重新配置: <pre>
$ ./configure –with-ssl-dir=/usr/local/Cellar/openssl/1.0.1e/
$ make
</pre> 又出错了: <pre>
Undefined symbols for architecture x86_64:
“_res_9_dn_expand”, referenced from:
_getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o)
_parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o)
“_res_9_getlong”, referenced from:
_parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o)
“_res_9_getshort”, referenced from:
_getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o)
_parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o)
“_res_9_init”, referenced from:
_getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o)
“_res_9_query”, referenced from:
_getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o)
ld: symbol(s) not found for architecture x86_64

需要修改Makefile,在LDFLAGS后增加lresolv,总算编译成功。

$ make install

如果涉及权限问题,自行加上sudo。安装后的程序在/usr/local/bin,使用带有obfuscated handshake功能的ssh:

$ /usr/local/bin/ssh -NT -f -D 1080 -p 443 -Z obfascatedkey username@sshhost

大功告成,亲个嘴吧。

有需要购买ssh的话,点击我的推广链接

在MAC翻墙遇到的问题

原先有ssh的账号,在mac上翻墙倒也不麻烦,下了个secret socks,略微配置一下连上usassh。

直接勾选“Update network settings”,提示输入root口令后,就会直接修改网络中的设置以sock方式访问。这时打开safari就可以翻墙了。
不过这种方式的缺陷还是所有的站点访问都会走ssh,国内很多站点的访问速度会有影响。还是想能改成智能点的,只有自己需要的站点访问就好了。
采用PAC的方案,我把原先chrome中的proxy switchy设置的列表导出成一个pac文件,然后在网络中设置代理方式为“自动代理配置”,同时提供配置文件。
google的结果来看都说很简单,这样就ok了,可是俺死活没搞通。瞎折腾了半天,要么都访问不了,要么就是走的ssh通道。
奇了个怪了!
后来忽然想是否我的pac文件不对,于是自己写了个最简单的pac文件:
function FindProxyForURL(url, host)
{
        return “SOCKS 127.0.0.1:1080”;
}
换了个思路,也就找到了问题的根源。才发现是犯了两毛病:
1. 我最开始在代理配置文件中的URL提供的是“file://”形式的地址,采用了“选取文件”的按钮,貌似lion不支持“file://”形式。嗯,这个就启用网络共享,提供http的访问形式。
2. 从chrome导出的pac文件采用的sock地址形式都是”SOCKS5 127.0.0.1:1080”,而不是SOCKS。规格的说法应该是提供SOCKS。一字之差害死人啊。
终于在晚上睡觉前搞定了,可以安心睡觉了。

SSH代理帐号

之前一直用免费的SSH帐号,cjb不稳定了,dailiav的没有了,shellmix也是时好时坏,太折腾人了。想想还是买一个算了,刚好那天听维靖的推荐,在usassh上注册买了一个。年付70,打6折,也就是42元一年,直接用支付宝付款,还是挺方便的。速度感觉也不错。
推荐一下吧。有需要的可以点我的邀请链接,还有个优惠码是xbin999,可以打7者。不过貌似我采用的“11月末促销优惠码:201011”,还是6折的。

BTW. 开始写这篇文章的时候没能连上ssh,看服务器状态是忙,写完之后发现已经恢复。