丝杠与代理的ssh_exchange_identification误差

Question

直到几天前，我还能够连接到我的远程ssh服务器，通过这个简单的配置使用瓶塞钻隧道连接通过公司代理：

ssh -v root@xxx.xxx.xxx.xxx -p 443 -o "ProxyCommand corkscrew corp-proxy 8080 xxx.xxx.xxx.xxx 443"

由于公司代理的限制，我已经将ssh服务器端口设置为443。现在，代理端发生了一些变化，我收到了以下错误：

OpenSSH_6.2p2 Ubuntu-6ubuntu0.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Executing proxy command: exec corkscrew corp-proxy 8080 xxx.xxx.xxx.xxx 443 
debug1: identity file /home/pe/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.4
debug1: permanently_drop_suid: 1000
ssh_exchange_identification: Connection closed by remote host

我还试图安装一台新的debian虚拟机，因为我的怀疑是我在某种程度上被列入了黑名单(我的ip是由pc主机名从dhcp修复和分配的)。

在新虚拟机上，我的ip由dhcp随机分配，如果我试图连接，就会得到一个不同的响应：

OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec corkscrew corp-proxy 8080 xxx.xxx.xxx.xxx 443
debug1: permanently_drop_suid: 1000
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug3: put_host_port: [xxx.xxx.xxx.xxx]:443
debug1: SSH2_MSG_KEXINIT sent
Connection closed by UNKNOWN

这个连接到达ssh服务器，正如我在auth.log文件中看到的那样，但这是响应：

Did not receive identification string from xxx.xxx.xxx.xxx

会不会是新的代理设置挡住了我？关于如何使ssh再次工作，有什么建议吗？

编辑:尝试了几种方法，openvpn，apache重定向。毫无办法。Apache重定向也会产生相同的错误：

    telnet corp-proxy 8080
Trying xxx.xxx.xxx.xxx...
Connected to corp-proxy.
Escape character is '^]'.
CONNECT myserver:443 HTTP/1.0

HTTP/1.0 200 Connection Established
Date: Wed, 29 Oct 2014 16:12:06 GMT
Via: 1.1 corp-proxy

CONNECT myserver:1443 HTTP/1.0
Connection closed by foreign host.

在本例中，我的服务器在443端口上有apache，当apache将端口1443上的连接重定向到ssh服务器时，这是从代理接受的。我被赶出去了。

Answer 1

找到了解决办法，可能是原因。

我怀疑代理端已经在443端口上启用了某种深度数据包检查(DPI)，因此只有“真正的”https请求才能被代理所接受，所有其他请求都会得到连接重置。

解决方案是使用一个名为Stunnel的程序，它能够将https请求包装在SSL容器中，因此代理端与普通https请求(例如浏览https站点)是无法区分的。

Stunnel必须安装服务器和客户端，并且可以配置为使用代理服务器进行请求。

互联网上有很多关于如何安装和配置它的教程。