SSH Proxy

Предположим:

host1       192.168.0.1   # internal host1
host2       192.168.0.2   # internal host2
example.com 93.184.216.34 # public accessible host

Далее у клиента в .ssh/config:

Host host*
    User happyhacker
    ProxyCommand ssh -e none example.com exec nc -w 5 %h %p

И далее на клиенте:

slogin host1

slogin host2

Пользователь конечно должен иметь акаунт на example.com.

PS: netcat потому что два раза шифровать и так шифрованный траффик нет смысла.

Дать контейнерам IPv6 не вариант?

перекинуть авторизацию

Насколько я понимаю, в ssh-протоколе СНАЧАЛА идет обмен ключами с сервером, и только потом авторизация. Так что именно перекинуть авторизацию у тебя не получится, тебе придется внутри установленного соединения заставлять пользователей вводить пароль. А значит, они не смогут заливать собственные публичные ssh-ключи на сервер

Ваш вариант тоже не подоит мне - нужно создавать учетки на NAT-сервере.

PS: разве ProxyCommand, не ForceCommand?

Если бы IPv6 был у всех, а так (пока) не вариант.

Это может быть и один аккаунт на всех, в котором разрешён только netcat.

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

обоснуй. Почему самый простой и надежный вариант тебе вдруг не подходит?

Присоединяюсь к вопросу. Сам такой вариант использую (плюс короткие имена для контейнеров в ~/.ssh/config что-бы не запоминать порты). Костыль конечно, но за то просто.

P.S. Ещё можно VPNиться в виртуальную подсеть контейнеров.

Готовых нормальных решений нет, но приходилось решать подобную задачу. В моем случае к шлюзу подключаются пользователи, а затем их проксируют под захардкоженной учеткой на определенный openvz-контейнер. Решалось это с помощью написание своего ssh-сервера. Пользователи логининятся по специальному имени (типа имяпользователя-имямашины@адресшлюза), после авторизации на шлюзе с логина выкусывается имя машины и устанавливается коннект к ней. Минус этой схемы в том что на самом шлюзе данные не зашифрованы это раз, а два - нагрузка шифровать/дешифровать трафик приходится 2 раза.

Если поискать, то можно найти похожие решения, например вот: https://github.com/tg123/sshpiper

Хотелось бы иметь красивый вариант. Да и если у меня будет 65000 машин, то возникает проблема с портами. А форвардинг на основе логинов помог бы во многом.

Вариант по ссылке вполне не плох после некоторой доработки напильником. Туда дописать поддержку стораджа ключей к контейнерам и ГУЙ для менеджмента этих самых ключей. От двойной нагрузки шифрования/расшифровки на самом шлюзе никак не избавишься - как писали выше авторизация происходит по зашифрованному каналу. Свой вариант показать не могу ибо NDA, но идея в целом похожа, только реализован удобный менеджмент пользователей, ключей и адресов контейнеров. Ну и не на Go (хотя никаких хейтерских/фанбойевских чуств к нему не испытываю)

Вот еще один POC на питоне https://github.com/saironiq/mitmproxy (правда не готовое решение, но идею реализации можно подсмотреть)

пусть они логинятся на сервак с белым айпи (там же их авторизуй), а пользователям пропиши вместо шелла - команду (скрипт), которая будет логинить их в нужный контейнер. чото типа docker exec -it ... bash только для своих контейнеров.

А как быть если один пользователь может логиниться в несколько контейнеров? ТС, тогда запили еще и диалог выбора контейнера.

У каждого пользователя свой уникальный на всю систему логин (дальше sudo в помощь), а этот логин связан с контейнером.

2Komintern очень глупо рулить на основании клиентского IP.