Удаленный доступ к компьютеру за NAT'ом через SSH-туннель

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

    Фактически это описание бэкдора, поэтому убедитесь, что вы не нанесете вреда чужой сети и что локальные администраторы в курсе ваших манипуляций.

    Задача: разместить линуксовый компьютер в сети за NATом, и иметь к нему доступ из внешнего мира. Например, вы траблшутите или поддерживаете что-то у клиента, и чтобы не сидеть у него в офисе, нужно быстро соорудить удаленный доступ. Или, например в 3G-сетях клиенты как правило получают приватные адреса, а нам нужен доступ к компьютеру, где другой связи нет.



    1. Нужен линуксовый сервер с глобальным IP-адресом. Дешевый VPS в минимальной конфигурации подойдет лучше всего. Заводим новую DNS-запись для нашего сервиса, тем самым отвязав сервис от конкретного сервера. Далее в качестве примера используется имя «callhome.example.net».

    2. Активируем keepalives на сервере и разрешаем GatewayPorts в /etc/ssh/sshd_config:
    ClientAliveInterval 5
    ClientAliveCountMax 3
    GatewayPorts yes
    


    3. Создаем юзера comehome на сервере:
    useradd -r -m -k /dev/null comehome
    cd /home/comehome/
    mkdir .ssh
    chown comehome:comehome .ssh/
    chmod 700 .ssh/
    


    4. Удаленный компьютер — в принципе, любое устройство под линуксом. Назовем его agent01. Если у рута ещё нет SSH-ключей, создаем пару ключей командой ssh-keygen. Затем создаем скрипт /root/ssh_tunnel.sh:
    #!/bin/sh
    
    SSHCMD="ssh -Tq -o ServerAliveInterval=5 \
        -o UserKnownHostsFile=/dev/null \
        -o StrictHostKeyChecking=no \
        comehome@callhome.example.net"
    
    while true; do
        PORT=`$SSHCMD`
        if test 0${PORT} -gt 0; then
          $SSHCMD -NC -R "*:${PORT}:127.0.0.1:22"
        fi
        sleep 5
    done
    


    в оригинальной статье есть также скрипт для /etc/init.d для автоматического запуска нашего туннеля.

    5. Добавляем публичный ключ рута с agent01 в список авторизованных ключей на сервере, при этом не разрешаем агенту выполнять никаких команд. Также сообщяем агенту адрес порта, по которому он будет доступен (всё в одну строку):
    cat >>.ssh/authorized_keys <<EOT
    command="/bin/echo 2101",no-user-rc,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3N/skipped/ root@agent01
    EOT
    


    Собственно, всё. Остается только протестировать. После запуска туннеля, SSH-соединение на порт 2101 должно приземляться на порту 22 удаленного компьютера.

    Если агент — ноутбук под убунтой, начиная с убунты 12.04 невозможно отключить засыпание от закрытия крышки глобально (по крайней мере, мне не удавалось когда я последний раз тестировал).

    Не забывайте сделать бэкап скриптов.

    Убедитесь в том, что никто кроме вас не получит доступа к агенту, а также что на агенте четко написаны координаты владельца — вы же не хотите подставить чужую сеть под опасность.

    В скрипте очень важны ServerAliveInterval (в случае разрыва соединения и клиент и сервер должны оборвать предыдущий туннель), а также sleep (без него при отсутсвии маршрута до сервера ssh возвращается мгновенно, так что лучше притормозить перед следующим запуском). StrictHostKeyChecking отключен на тот случай, если сервис callhome переедет на другую машину, а агент вне нашей физической досягаемости.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 38

      +1
      Убедитесь в том, что никто кроме вас не получит доступа к агенту, а также что на агенте четко написаны координаты владельца — вы же не хотите подставить чужую сеть под опасность.

      Вот этого не понял. Для какой сети появляется опасность — в которой находится агент или сервер? И в чём эта опасность заключается? И вообще что значит «доступ к агенту» в данном контексте?

      Вот есть у меня сервер у хетцнера и потенциальный агент дома за провайдерским НАТом. В чём я должен убедиться и какую опасность для чьей сети (хетцнеровской? провайдерской?) представляет реализация такой схемы?
        0
        опасность — это если вы ставите этого агента в чужую локальную сеть, а потом кто-то третий получил доступ к агенту. Получается, что вы прорубили дырку в корпоративной секьюрити, и если что, проблемы будут у вас, а не у злоумышленника
          0
          Может это проблема «корпоративной секьюрити», что она не может обеспечить свою безопасность? Что принципиально может сделать третье лицо, чего не могу сделать я, имея полный физический и «логический» доступ к своей машине?
            0
            ну всё же предполагается, что вы — не злоумышленник и поставили агента для рабочих надобностей с ведома местного IT :)

            к сожалению, в 100% сетей где я проверял, исходящий ssh открыт. Только в одной сети была регистрация всех MAC'ов и автоматический шатдаун портов на свиче, если подсоединился кто-то чужой.
              0
              В моём договоре с провайдером нет требований извещать его о каких либо действиях на своём компе, запрета на проброс портов тоже нет. А блокировку исходящего ssh я бы счёл нарушением сетевой нейтральности и поискал бы другого провайдера. Но регистрация MACов есть у него, да, собственно с незарегистрированным маком ни один байт не отправить и не получить дальше модема.
                0
                вообще-то в посте речь о корпоративных сетях в основном :)
                  0
                  Задача: разместить линуксовый компьютер в сети за NATом, и иметь к нему доступ из внешнего мира. Например, вы траблшутите или поддерживаете что-то у клиента, и чтобы не сидеть у него в офисе, нужно быстро соорудить удаленный доступ. Или, например в 3G-сетях клиенты как правило получают приватные адреса, а нам нужен доступ к компьютеру, где другой связи нет.

                  Ни одного намёка на это не увидел :( Сорри. А задача в точности моя.
                    0
                    я имел в виду, что такого агента приходится ставить как правило в чьей-то корпоративной сети. Конечно же, никто не мешает ставить его где угодно. Просто в корпоративных сетях требования к безопасности выше, ну и последствия от её нарушения тоже выше.
        +10
        Может проще openvpn поднять?
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Согласен, единожды разобраться с openvpn — и все компьютеры за натом доступны — как в локалке.
            Воспользуюсь случаем и спрошу — кто как поборол такие неприятные особенности openvpn (при промышленной эксплуатации к этим проблемам нужно отнестись серьёзно):
            1. Чтобы запретить доступ клиенту (например сотрудник уволился, но сделал копии user1.crt и user1.key) нужно явно прописать сертификат пользователя в список отозванных.
            Т.е. доступ разрешен всем имеющим сертификат (кому явно не запрещен). Нет уверенности, что кто-то не сделал себе «запасной» сертификат.
            2. Не ограничивается повторное подключение с одним и тем же сертификатом.
            3. Нет привязки сертификат — IP-адрес.
              0
              Не будет ли забиванием гвоздей микроскопом использование vpn для задачи «получить свободный доступ к одному сервису(порту) на хосте за натом, над которым нет контроля, с произвольного хоста вне его»?

              Даже по вашим вопросам видно, что разбираться много с чем нужно и некоторые вещи (ограничение доступа) явно для этой задачи не актуальны.
                0
                п.1 — есть альтернативный вариант, использовать настройку ccd-exclusive, которая требует обязательного наличия файла настроек клиента. В этих настройках можно зашить ip-адрес клиента, тем самым ограничив кол-во одновременных подключений (п.3 и п.2)
                  0
                  Не дописал п.1 — с этой настройкой поумолчанию клиент для которого нет файла настроек подключиться не сможет.
                  0
                  Насчет повторного подключения не знаю, не сталкивался, но дополнительно ограничить доступ (помимо отзывных сертификатов) и привязать IP к сертификату можно с помощью client-config-dir.
                0
                А в чём принципиальные плюсы? Не нужен хост с глобальным адресом? Не нужно инициировать соединение изнутри НАТа? Или, может, меньше ресурсов потребляет чем ssh?
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    всё зависит от задач, в моем случае ssh достаточен для всего. я в другой ветке дал пару примеров
                      0
                      В моем представлении в пробросе единичного порта, доступ к которому нужно получать с любых других хостов и без аутентификации (средствами проброса, аутентификация, если вообще нужна, осуществляется средствами приложения порт слушающего) очень мало общего с VPN. Мне нужно чтобы мой хост (вернее хост: порт) стал частью не частной сети, а публичной, частью всего Интернета. Просто способ не покупать глобальный IP у провайдера, а более экономно (прежде всего) и безопасно (практически без снижения удобства) решить проблему доступа к домашнему компу извне и не только для себя.
                        0
                        ну если это ваша домашняя сеть, то dynamic DNS и статический port forwarding решают проблему легко
                          0
                          У меня статический внутренний IP и статический внешний у шлюза (NAT) провайдера. По-моему способ в посте оптимально подходит для того, чтобы, например, получить доступ по ssh к локальной ФС c произвольной машины, или, скажем, показывать по http заказчикам поднятый локально сайт перед помещением на production. Собственно внешний IP нужен только для этих целей.
                            0
                            ну если у вас уже есть VPS в глобальной сети, то и демоверсию сайта проще запустить там, а не у себя дома :)
                              0
                              Там только то, что закомиченно, а надо показать клиенту чтоб получить «добро» на коммит, грубо говоря. Чтоб не было коммитов «чуть-чуть синее», «немного жирнее», «малость правее», «перебор» и т. п :)
                                0
                                А синхронизировать локальный каталог и удаленный неудобно на каждый чих.
                    +1
                    в моем случае не нужна связь между всеми компьютерами, а нужен быстрый способ поставить линуксовый ящик, где можно запускать tcpdump, snmpwalk, а то и скриптец какой (например, в лабе для тестирования IPTV я сделал скрипт, который присоединяется последовательно к нескольким мультикастным потокам)

                    openvpn требует больше усилий по настройке, но в целом вы правы, в некоторых случаях он удобнее. В моем случае удобнее ssh
                    0
                    >> Если агент — ноутбук под убунтой, начиная с убунты 12.04 невозможно отключить засыпание от закрытия крышки…

                    i45.tinypic.com/308h4kl.png
                      0
                      ага, это работает для текущего юзера. Если никто не залогинен, ноутбук уходит в спячку при закрытии крышки. В одиннадцатой установки были глобальными
                      +1
                      То есть съездить к клиенту и установить у него оборудование, инициирующее соединение изнутри — это называется «быстро» и «бэкдор»?
                        0
                        Не оборудование, а софт установить и настроить.
                          0
                          можно и по почте ноутбук выслать (в наших краях доходит на следующий день). Как правило, для моих задач это самый быстрый способ, а бэкдор — это побочный эффект :)
                            0
                            это однозначно быстрее, чем просить клиента поднять линукс и дать к нему доступ
                            0
                            Вот и нашлось применение для picotux
                              0
                              за те же деньги можно купить Alix с pcengines.ch — там всё же полноценный компьютер с достаточным количеством памяти, чтобы запустить нормальный дебиан
                                0
                                Да и RaspberryPI подходит.

                                Я о том, вообще, что из подобных мини-РС можно делать конечные устройства, бэк-доры, и продавать их на каждом углу.
                                Некий бэг-дор по-быстрому в блистерной упаковке.

                                  0
                                  хм, а зачем? И кто конечный покупатель?
                                    0
                                    Покупатель — молодое быдло. Потому продавать надо рядом с сухариками, в супермаркетах.

                                    Удобно же: принес куда-нибудь, воткнул тихонечко, из дома зашел и вуаля, все внутренние ресурсы на ладони.

                                      0
                                      на таких придумали switchport port-security либо dot1x (для сильных духом админов)
                                        0
                                        Домашние-то сети так не защищают.

                                        Применение устройства — тырить фотки с домашних машин одноклассников :-)

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое