Пожалуйста, помогите: я хочу подключиться к моему ssh серверу дома
Однако я за корпоративным брандмауэром (CORP),
который блокирует почти все порты (443, 22, 23 и т. д.).
Но вроде 80 не заблокировано,
потому что я могу просматривать веб-страницы после входа в систему
(т.е. IE устанавливает прокси-сервер CORP, и
запустите IE -> отображается портал интрасети CORP -> введите google.com ->
всплывает диалоговое окно для идентификатора пользователя + pwd ->
вход прошел успешно, и серфинг без ограничений)
Мой ssh-сервер слушает 443.
У меня вопрос:
Есть ли способ подключиться из
компьютер за брандмауэром CORP
на ssh-сервер
через порт 80, с сервером ssh
все еще слушаете порт 443?
Изменение ssh-сервера для прослушивания порта 80
это не вариант, потому что
мой домашний интернет-провайдер блокирует 80.
Могу ли я использовать публичный прокси, который слушает на 80?
После некоторых исследований в Google
Я обнаружил, что есть что-то, что называется «подключиться к SSH через HTTP-прокси» с помощью программного обеспечения Cockscrew.
Это полезно?
Или есть другой способ решить проблему?
PuTTY поддерживает туннелирование SSH через HTTP-прокси. Видеть это руководство
Да, штопор пригодится. Видеть этот учебник.
Вы вряд ли найдете какое-либо общедоступное решение, хотя вы можете довольно легко настроить его для себя, если не возражаете платить несколько долларов в месяц. Получите самый дешевый VPS, который вы можете найти (этот является самым дешевым предложением на первой странице рекламной области VPS WHT, вы можете найти дешевле, если будете искать глубже и готовы платить ежеквартально или ежегодно), убедитесь, что никакие веб-серверы не установлены, не установлен rinetd и что он указан на порту 80, перенаправляя соединения на порт SSH вашего домашнего сервера. Для этого не требуется нового программного обеспечения ни на стороне клиента, ни на стороне сервера, но требуется новая внешняя машина с небольшими затратами.
Ваш корпоративный брандмауэр может делать больше, чем просто блокировать порты - если они используют проверку пакетов, он может блокировать ваши попытки SSH, поскольку он может идентифицировать соединения как не HTTP.
В зависимости от того, что вы хотите делать со своим SSH-соединением, вы можете установить что-то вроде этот сценарий на вашем веб-сервере. Очевидно, это не позволит переадресации портов и тому подобное, но это будет хорошо для многих целей. Трафик, проходящий через ваш корпоративный брандмауэр, будет обычным HTTP (S) -соединением, поэтому он должен проходить, даже если используется проверка пакетов или другие методы ограничения протокола, хотя если вы используете HTTP, а не HTTPS, ваш трафик не защищен шифрованием, поэтому ваши корпоративные повелители смогут записывать сеансы SSH, если захотят. Кроме того, убедитесь, что вы осведомлены о соответствующих вопросах безопасности, правильно настройте любой такой скрипт - вы не хотите открывать маршрут для того, чтобы кто-либо проник на ваш сервер без аутентификации ...
Прежде чем рассматривать что-либо из вышеперечисленного, внимательно примите во внимание тот факт, что, как отмечали другие, обход мер безопасности, вероятно, будет достаточно серьезным вопросом для вашего работодателя, и ваша работа окажется под угрозой, если ваши действия будут замечены.
Есть еще один вариант, с которым я добился определенного успеха. Возможно туннелирование SSH через DNS. Видеть http://www.dnstunnel.de/ на сколько. После этого вы можете использовать свой SSH-сервер в качестве прокси-сервера socks, а затем туннелировать через него все остальное.
Как указано выше другими, хотя может показаться, что 443 и 80 не мешают вам, вы действительно не можете быть полностью уверены в том, что это так.
и, как всегда, будьте осторожны, чтобы не раздражать сисадмина :)
Вы можете настроить прокси-сервер SOCKS, работающий на вашем сервере. Это туннелирует любое TCP-соединение через HTTP. Однако ваш корпоративный брандмауэр может искать такие вещи.
@hop Я не думаю, что вы понимаете. Вы настраиваете прокси-сервер ВНЕШНЕЙ корпоративной сети и подключаетесь к нему через брандмауэр через порт 80 или 443. Этот прокси находится вне корпоративной сети, поэтому соединения, проходящие через этот прокси-сервер, не защищены брандмауэром.