Подключение к SSH серверу за NAT

У меня есть ситуация, где целевая машина находится за стандартным домашним маршрутизатором/брандмауэром/NAT (назовем ее target), и машина с известным публичным IP-адресом (назовем ее server).

С server я хочу подключиться по SSH к target, для чего у меня есть учетные данные. Однако пользователь на target не имеет учетных данных для server. Таким образом, нет возможности для пользователя на target настроить перенаправление порта SSH на server. Если бы это было возможно, они могли бы использовать стандартный метод удаленного перенаправления порта с ssh -R. Хотя у меня есть учетные данные для target, я не имею контроля над его маршрутизатором/брандмауэром/NAT, и я должен действовать, исходя из предположения, что порт 22 не перенаправляется на NAT-адрес target.

У меня появилось три идеи:

Идея 1: Временные пользователи (я ненавижу это)

Одно из решений — создать нового пользователя на server, передать учетные данные кому-то на target, кто затем сможет настроить удаленный порт SSH на server, который я могу использовать для входа на target. Как только я сделаю все необходимое, я смогу полностью удалить этого пользователя с server.

Идея 2: Какой-то прокси (я не знаю, как это сделать)

Я пока не могу до конца это осмыслить, но, используя все хитрости SSH, такие как перенаправление портов, прокси, nc и т. д., кажется, я должен быть способен сделать что-то, где я скажу target подключиться к порту на server и как-то превратить это в туннель, через который я могу войти на target. Эта идея в лучшем случае полусырна. Единственный способ, который я могу представить без наличия у кого-то на target учетных данных для server, это открыть порт на server, подключить target к этому порту с помощью nc, и как-то использовать это, чтобы пойти в обратном направлении и подключиться к target с server через SSH.

Идея 3: Wireguard (нужно передать публичный ключ от target к server)

Просто подключив их к одной VPN, задача была бы выполнена. Wireguard был бы легким, пока у меня есть разумный способ обмена публичными ключами между target и server. Это легко в одном направлении (распространение публичного ключа server на target), но из-за природы устройства target и его пользователей получение ключа от них возможно, но не очень удобно для пользователя.

Итак, конкретно, меня интересуют мысли по идее 2. Я могу сделать 1 или 3, но кажется, я упускаю что-то, что сделало бы возможным просто подключиться по SSH к target с server. Какие мысли? Спасибо!

Для вашей второй идеи, я полагаю, вам нужно SSH обратное перенаправление порта. Есть вопрос здесь, который спрашивает об установке этого – и ответ постера охватывает по крайней мере одно требование к конфигурации.

С использованием этой идеи, вы можете создать обратную связь двумя способами – во-первых, вы можете сделать так, чтобы SSH заходил на server для перенаправления на target, или вы можете сделать так, чтобы SSH заходил на localhost на вашей внешней системе и перенаправлялся на target. Лично я бы рекомендовал последнее, особенно учитывая, что вы явно указываете, что не контролируете правила брандмауэра server.

Имейте в виду, что если соединение от target к server или вашему внешнему хосту прервется, этот туннель станет недоступным. У меня нет хорошего решения для этой проблемы, кроме как написать скрипт, который контролирует (начальное) исходящее SSH-соединение от target и перезапускает его, если оно завершается.

Также, я считаю необходимым добавить, что если target и/или server являются рабочими машинами, это может рассматриваться как намеренное нарушение процедур безопасности, что может иметь весьма негативные последствия для вас. Однако вы лучше знаете ваше окружение, чем я, поэтому должны определить, применим ли этот последний пункт, и насколько это важно, если он применим.

(немного сбивает с толку, что вы решили назвать клиента “server”, а сервер “target” в вашем описании)

Что касается варианта с VPN… если невозможно использовать UDP (UDP с NAT может быть сложным), то это может быть плохим вариантом. Запуск TCP-соединений через TCP-VPN вроде бы работает, но возникают проблемы, когда начинают действовать алгоритмы управления перегрузками.

Использование SSH для перенаправления портов фактически является VPN – хотя и такой, где нужно запускать процесс для каждого порта. В сущности, “прокси” решение также представляет собой то же исправление без явной реализации шифрования.

Вариант 2 будет тривиален в настройке и (согласно вашим комментариям) может быть выполнен с помощью netcat – но это открывает еще одну открытую службу на хосте, обозначенном как “server”, без какой-либо аутентификации. Мне кажется, это в корне неправильно. Вы могли бы использовать механизм стука в порт, чтобы уменьшить экспозицию (в Интернете много примеров, это можно сделать всего несколькими командами iptables). В качестве альтернативы вы можете использовать туннель HTTP[s] с (например) squid на “server” и corkscrew на “target”. Это поддерживает аутентификацию для канала.

Вы не сказали, почему ненавидите SSH решение, и почему хотите быстро удалить пользователя. Учитывая, что, вероятно, не нужно устанавливать дополнительное программное обеспечение или применять настройки на “target”, это кажется наиболее подходящим решением.