Как подключаться к домашнему компу по ssh — в основном все знают. Если домашний комп работает под управлением Windows, то прокинуть порт на роутере RDP тоже сложностей не вызывает.
Надо отметить, что кучу портов держать открытыми — это небезопасно, т.к. у каждого сервиса могут быть свои уязвимости. Чем больше открыто портов, тем больше вероятность, что вас взломают. Не говоря о том, что информация в большинстве случаев идет по незашифрованному каналу.
Речь, однако, пойдет не о Windows и RDP, а об OS X. Хотя какие-то подходы схожи. Ниже показана распространенная конфигурация сети (стрелками показан наш предполагаемый путь):
В указанной схеме предполагается, что в сети есть некий сервер с круглосуточным доступом по ssh. Это может быть сам роутер или отдельный комп. В моем случае такой узел есть в роли небольшого файлового сервера.
Выход в Интернет с рабочей машины зачастую перекрыт прокси-сервером. Однако, сразу хочу заметить, что в такой системе бывают дыры в виде прямого доступа в Интернет по TCP портам 995/993 и/или 110/143. Иногда админы их открывают для доступа к внешним почтовым ящикам по протоколам POP3 и IMAP. Если в вашем случае это так, то можно на домашнем роутере пробросить один из таких портов на ssh порт локальной машины (по умолчанию, ssh-сервер слушает порт 22). Это, с одной стороны, позволит не заморачиваться с прокси, а с другой — у вас будет открыт популярный для сканирования порт. Как тут лучше поступить — решать вам.
Мне не повезло и мне приходится ходить домой через прокси как показано на схеме. Дома на роутере настроено перенаправление входящих соединений с порта 61016 на адрес 192.168.0.10 и порт 22.
С другой стороны, на работе, имеем прокси-сервер с адресом 10.0.0.1:3128 и рабочий комп с Ubuntu. Там нужно поставить пакет corkscrew, который позволит ходить по ssh через прокси:
sudo apt-get install corkscrewВ файле ~/.corkscrew-auth прописываем данные аутентификации для доступа к прокси-серверу, если требуется. Проще говоря логин и пароль через пробел. После этого нужно научить ssh использовать corkscrew. Для этого создаем файл ~/.ssh/config и в него добавляем следующую строку:
ProxyCommand /usr/bin/corkscrew PROXY_IP PROXY_PORT %h %p PATH_TO_.corkscrew-authВместо PROXY_IP, PROXY_PORT и PATH_TO_ необходимо вставить актуальные для вас значения.
Далее будет шаг, который не нужен, если целевой компьютер гарантировано включен. В моем случае это не так (MacBook Pro любит спать). С работы подключаемся по адресу myhome.homelinux.com указывая порт (-p 61016) и будим ноутбук следующей командой:
wakeonlan MAC_ADDRESSгде вместо MAC_ADDRESS надо ввести адрес вашего ноутбука. Таким образом ноутбук будет разбужен и к нему можно подключаться из той же сессии по второму ssh, уже внутри сети (с 192.168.0.10 на 192.168.0.100). Это нам нужно, чтобы включить доступ по VNC, если он еще не разрешен. На моем ноуте он не разрешен на постоянной основе дабы не провоцировать злоумышленников в общественных сетях. В консоли ноута (куда мы подключены по ssh) вводим следующую команду:
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -clientopts -setvnclegacy -vnclegacy yes -clientopts -setvncpw -vncpw MYPASSWD -restart -agent -privs -allгде вместо MYPASSWD нужно ввести свою любимый пароль.
Теперь доступ открыт и можно подключаться.
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -configure -access -offСобственно, само подключение можно делать создав туннель до ноутбука. Для этого на рабочем компьютере в консоли вводим:
ssh -L 8080:MACBOOK_IP_ADDRESS:5900 REMOTE_ROUTER_IP_ADDRESS -p SSH_PORT_ON_ROUTERТут MACBOOK_IP_ADDRESS заменяем на адрес ноутбука (если смотреть схему, то это 192.168.0.100), вместо REMOTE_ROUTER_IP_ADDRESS нужно вписать интернет-адрес домашнего роутера, ну и SSH_PORT_ON_ROUTER надо заменить на номер внешнего порта (61016 на схеме).
Далее запускаем свой любимый VCN-клиент и подключаемся к localhost на порт 8080.
На этом все. Вместо таких нетривиальных шагов можно дома оставлять включенный TeamViewer с разрешенными входящими соединениями, но такой способ небезопасен. Во-первых, данные идут через сервера TeamViewer, а во-вторых оне не шифруются так надежно как хотелось бы.