オープナーとプロキシを介したSSHの「ssh_exchange_identification」エラー

オープナーとプロキシを介したSSHの「ssh_exchange_identification」エラー

数日前までは、次の構成で会社のプロキシを介して接続をトンネリングするために、コルクネジを使用してリモートSSHサーバーに接続できました。

ssh -v [email protected] -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 VMをインストールしてみました(私のIPは固定されており、PCホスト名を介してdhcpから割り当てられました)。

新しいVMでは、私の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

auth.logファイルに示すように、この接続はsshサーバーに到達しますが、応答は次のとおりです。

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.

この場合、myserver はポート 443 に Apache があり、Apache がポート 1443 の接続を SSH サーバーにリダイレクトすると、そのポートはプロキシで許可されます。私は追い出された。

ベストアンサー1

解決策と考えられる原因を見つけました。

プロキシ側には、ポート443で一種のディープパケットチェック(DPI)が有効になっていると疑われます。したがって、プロキシは「実際の」https要求のみを受け入れることができ、他のすべての要求は接続をリセットします。

解決策は、次の関数を使用することです。トンネルSSLコンテナでhttpsリクエストをラップする機能で、プロキシ側は通常のhttpsリクエスト(httpsサイト検索など)と変わりません。

Stunnelはサーバー側とクライアント側の両方にインストールする必要があり、プロキシサーバーを使用して要求するように設定できます。

インストールと設定方法に関する多くのチュートリアルがインターネットにあります。

おすすめ記事