Я за корпоративной сетью с HTTP прокси. У меня также есть SSH-сервер для доступа на порт 22. У меня нет никакого контроля над этим сервером: я не root, и даже если бы я был, мне не разрешали устанавливать программное обеспечение или изменять конфигурацию. Сервер прослушивает порт 22, там должен быть достигнут доступ, и это никогда не может быть изменено.

Если я настраиваю XShell (но то же самое должно применяться к любому другому клиенту) для использования корпоративного прокси-сервера, я не могу подключиться. Опровержение показывает, что метод CONNECT отклоняется прокси, потому что «это не стандартный порт SSL».

Я считаю, что прокси блокирует трафик на порты, отличные от 80 и 443. Не делая глубокую проверку пакетов или другие эзотерические уловки.

Я связал статью о настройке HTTP-прокси для SSH «когда прокси-фильтр фильтрует протокол SSH», но проблема в том, что он работает для Linux, и у меня есть другая проблема (он не обнаруживает сетевую карту, уже задаваемый здесь). .).

Вопрос в том, как обойти прокси без установки программного обеспечения или изменения конфигурации на целевом компьютере.

Я также хотел бы понять

  1. Поскольку прокси-сервер блокирует порт 22 вместо протокола SSH путем глубокой проверки пакетов, работает ли связанное руководство, когда сервер прослушивает порт 22, и не может быть изменено каким-либо образом?
  2. Есть ли способ заставить его работать на Windows?
|источник

2 ответа2

2

Для любой проблемы корпоративного прокси я предлагаю proxytunnel (через штопор), потому что он делает трафик полностью неотличимым от реального HTTPS-трафика, даже если должен использоваться полный перехват пакетов.

Это решение требует наличия https-сервера под вашим контролем (возможно, на той же машине, на которой работает ssh-сервер), с которой общается корпоративный прокси.

Ответ на ваш первый вопрос: proxytunnel будет обходить блокировку вашего корпоративного прокси, за исключением маловероятного случая, когда они обычно блокируют ваш https-сервер. Дальнейшие документы находятся здесь.

Я использую это с большим успехом на машине Linux. Там, кажется, есть документы и двоичные файлы для окон вокруг (2-й вопрос):

http://proxytunnel.sourceforge.net/download.php

http://egret.psychol.cam.ac.uk/techniques/firewall.html

Если вам повезет в вашей ситуации, простое решение также может помочь. Вместе с штопором просто установите промежуточный ssh-сервер, который перенаправит порт с благословением вашего корпоративного прокси на порт 22 вашего целевого ssh-сервера.

|источник
-1

Некоторое время назад у меня была эта проблема в местной библиотеке. Единственная разница: я администрирую сервер, к которому я хотел подключиться, чтобы я мог изменить настройку ssh на другом порту.

Дело в том, что я не хотел и не должен был.

Мое решение было:

~$ torify ssh admin@server.tld

Это работало некоторое время. Теперь локальная библиотека блокирует порты. Единственный способ обойти это с помощью этого метода - настроить схему tor, установленную torify, на использование моста.

Это не идеальные решения, но они просты, эффективны, безопасны, если ваш ssh-сервер настроен правильно, и они не требуют особых настроек на сервере или настройки какого-либо конкретного сервера для этой цели.

Недостатком является то, что ваш серверный брандмауэр будет видеть более частые атаки, чем раньше, и ваши журналы ssh будут показывать соединения, скажем, из Беларуси или Украины или любого другого выходного узла, от которого в конечном итоге будет получен трафик. Это может немного расстраивать, если у вас нет проблем с документированием удаленного доступа и сопоставлением его с журналами.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .