ssh из дома на машину за брандмауэром

Создайте туннель от работы до дома и сделайте туннель, который позволит вам подключаться из дома.

A на работе, B дома. Вы хотите подключиться от B к A, но брандмауэр блокирует это. Вместо этого подключитесь от A к B, создав туннель обратно к серверу. Предполагается, что у вас дома работает ssh-сервер и на вашем маршрутизаторе открыт порт 22. Если ваш домашний компьютер - Mac или Linux, вероятно, он у вас уже работает; если окна, установите cygwin и настроить sshd (ссылка).

На работе поместите это в свой файл .ssh / config:

host home
 hostname B      # replace with your FQDN or IP
 user homeuser   # user at home
 LocalForward 2222 localhost:22

Теперь, когда вы запускаете ssh home, порт 2222 будет туннелем к ssh-серверу вашей локальной машины. Я обнаружил, что если вы просто оставите это сидеть в приглашении в каком-то окне, соединение может иногда зависать, или файловый экран может закрыть его через некоторое время. Я предпочитаю использовать такую ​​команду, как

while true; do ssh -n home sleep 600; sleep 3000; done &

Это запустит туннель, который длится десять минут, затем закроется, а через час запустит новый. Если есть туннелированные соединения, по окончании сна команда ssh ожидает их завершения.
(Sleep 3000 не требуется; вы можете держать его открытым все время, просто некоторым предприятиям не нравится видеть частые или долгоживущие постоянные подключения к внешним машинам)

Теперь на домашней стороне поместите это в свой файл .ssh / config:

host worktunnel
 hostname localhost
 user     workuser
 port     2222
 UserKnownHostsFile ~/.ssh/known_hosts.worktunnel

Сохраните его, а затем, когда туннель заработает на вашем домашнем компьютере, вы можете просто ввести

ssh worktunnel

и ты внутри.

Строка UserKnownHostsFile необязательна, но она предотвращает появление предупреждений при использовании нескольких туннелей с разными портами для разных хостов, поэтому запись localhost в файле known_hosts по умолчанию не будет соответствовать всем этим хостам.

Вы можете добавить несколько строк LocalForward в файл конфигурации на A; например LocalForward 2223 server2: 22 # другой сервер с ssh LocalForward 5900 qa: 5900 # vnc LocalForward 3389 exchange: 3389 # удаленный рабочий стол LocalForward 3128 internalProxy: 3128 # для просмотра внутренних хостов # и т. Д.

(Для туннелирования X-соединений используйте ssh -X, а не LocalForward.)

Здесь не требуется изменять номера портов ssh-сервера.

Обратите внимание, что такой удаленный доступ может противоречить политике вашей компании. Некоторые места сканируют или проверяют такие соединения и могут выдать вам предупреждение об этом. Вы можете запустить команду tunnel в течение пяти минут, спать 55; или иметь сценарий на домашней машине, который немедленно завершает работу, когда туннель вам не нужен. Logmein - еще одно бесплатное решение, которое отлично работает, обеспечивая удаленный доступ к рабочим столам (windows, mac) за брандмауэрами.

Если дыра в брандмауэре находится на TCP / 22, то что-то должен быть на TCP / 22, чтобы прослушивать соединения. Это может быть ваш sshd-процесс или что-то еще. Хотя, если вы хотите подключиться к нему по ssh без необходимости сначала стучать в дверь, вы в значительной степени застряли с тем, чтобы ssd слушал TCP / 22.

Другой вариант - использовать какой-нибудь скрипт дверного молотка. Я не использовал их раньше, просто знаю, что они есть. Пусть служба прослушивает TCP / 22. Когда он получает нужную магическую строку, он выгружается и запускает SSHD на TCP / 22 на X минут. Когда процесс SSH закрывается, прослушиватель дверей возрождается на TCP / 22 и ждет следующего стука в дверь.

Но, в конце концов, безопасности SSH должно хватить. Положитесь на открытый ключ и отключите аутентификацию по паролю, и все, что может сделать scriptkiddiez, - это заполнить ваши файлы журналов. Шумный, но безобидный.

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

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

Другие ответы охватывают это довольно хорошо, но я хотел бы упомянуть, что вы можете использовать запретить на машине А, чтобы уменьшить воздействие бота. denyhosts регистрирует попытки ssh-запросов, и если внешний компьютер терпит неудачу слишком много раз, он блокирует этот IP-адрес vi /etc/hosts.deny. Так, например, бот, который пытается подключиться по ssh 100 раз в качестве пользователя, будет навсегда заблокирован после пятой неудачной попытки (все эти параметры настраиваются).

Вам также следует придерживаться хороших практик безопасности ssh-сервера, которые, я уверен, подробно описаны в других ответах serverfault. Отключить логины для root. Отключите вход для всех, кроме очень небольшого числа других авторизованных пользователей. Отключите вход по паролю и разрешите только ssh-соединения с открытым ключом.