SSH через штопор и прокси получают ошибку «ssh_exchange_identification»

пока несколько дней назад я не смог подключиться к удаленному серверу 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 исправлен и назначен из 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 работать снова?

EDIT: попробовал несколько методов, 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 есть apache на 443-порту, и это принято из прокси-сервера, когда apache перенаправляет соединение на порт 1443 на ssh-сервер. Меня выгоняют.

  • Как работает туннелирование SSH
  • Как использовать туннель SSH для подключения к удаленному серверу MySQL?
  • Как настроить Linux для повторного открытия моих туннелей SSH после восстановления соединения?
  • ssh для private-ip
  • Автоматическая настройка туннеля SSH
  • Доступ к URL-адресу офиса через внешний браузер
  • Обратное подключение к серверу SSH
  • удаленный рабочий стол на хосте
  • One Solution collect form web for “SSH через штопор и прокси получают ошибку «ssh_exchange_identification»”

    Нашел решение и, вероятно, причину.

    Я подозреваю, что на стороне прокси-сервера была включена некоторая глубокая проверка пакетов (DPI) на 443-порту, поэтому только «реальные» https-запросы могут быть приняты прокси-сервером, а все остальные запросы получают сброс соединения.

    Решение заключается в использовании программы Stunnel, которая способна обертывать https-запрос в SSL-контейнере, поэтому сторона прокси-сервера неотличима от обычного https-запроса (например, просматривая сайт https)

    Stunnel должен быть установлен на стороне сервера и клиента и может быть сконфигурирован для использования прокси-сервера для выполнения запросов.

    В Интернете есть много руководств по установке и настройке.

    Interesting Posts

    Синхронизируйте уровни громкости двух выходов на Pulseaudio

    Запуск Repl / CLI в фоновых и фидных командах

    Как получить Cuda 7, работающий над технологией Optimus в Linux.

    Как запустить приложения GUI с правами root с помощью pkexec?

    Как получить Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01) беспроводная карта, работающая на Debian Wheezy

    Уничтожение всего процесса команды, кроме первого процесса

    Как вам заставить fsck при перезагрузке на FreeBSD10?

    Портативный зашифрованный контейнер

    Обработка вывода sqlite db в массив ksh с пробелами

    Тестирование подключения удаленного хоста с помощью telnet

    bash / sh для замены текста между некоторыми тегами / строками в текстовом файле

    резервное копирование: какие исправления для резервного копирования перед обновлением / переустановкой

    Cu оставляет символы призраков в командной строке в xterm

    не удалось установить пакеты rpm в gnome3 (openSUSE 12.1)

    Как печатать определенные столбцы по имени?

    Linux и Unix - лучшая ОС в мире.