SSH без публичного IP: зачем нужен шлюз доступа к виртуальным машинам

Подключение по SSH — базовая операция для любой ВМ. От того, как оно устроено, зависят и площадь атаки, и то, переживёт ли удалённый доступ переезд сервера между хостами.

В архитектуре eBPF-сети microsrv SSH-шлюз — одна из входных точек наряду с HTTPS-шлюзом. Дальше — зачем убирать публичный порт 22 с виртуальных машин, чем шлюз отличается от классического бастиона и почему адрес подключения должен оставаться стабильным на прерываемых ресурсах.

Коротко: SSH-шлюз — единая аутентифицированная точка входа к виртуальной машине в приватной сети, без публичного IP на самой машине. Адрес <vm>@msrv.space не меняется после миграции.

1. Почему открытый SSH в интернет — плохая идея по умолчанию

Каждой ВМ выдали публичный IP и открыли 22-й порт наружу. Дальше начинается привычный сценарий:

инстанс постоянно сканируют боты, подбирая ключи и пароли;
площадь атаки растёт вместе с числом машин, а не с числом инженеров;
группы безопасности (security groups) и защита от перебора паролей (например, fail2ban) требуют ручного обслуживания каждого узла;
публичный адрес сильнее привязывает машину к сетевой конфигурации хоста и усложняет миграцию.

Внутренним сервисам, базам и CI-раннерам входящий SSH из всего интернета практически никогда не нужен. Нужен контролируемый канал для команды и автоматических пайплайнов.

2. Бастион: привычный компромисс

Классическая схема — один бастион (или несколько) в DMZ:

ssh -J user@bastion.example.com user@10.42.0.5

Плюсы понятны: частные ВМ не выставлены напрямую в публичный интернет, а ключи и списки контроля доступа (ACL) управляются централизованно на бастионе.

Минусы системные:

бастион сам становится критическим узлом: его нужно обновлять, мониторить и резервировать;
с ростом команды усложняется разграничение прав и контроль за неактивными ключами;
адрес 10.42.0.5 или внутреннее имя машины всё равно может измениться после пересоздания или аварийного переключения, если сетевой слой привязан к вычислительному;
при непосредственном использовании прерываемых ресурсов отключение хоста целевой ВМ обрывает SSH-сеанс, даже если сам бастион жив и здоров.

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

3. SSH-шлюз: единая точка входа без публичного IP на ВМ

Модель шлюза устроена иначе, чем «ещё один сервер, на который все заходят»:

клиент всегда подключается к одному внешнему имени;
шлюз проверяет пользователя по SSH-ключу и перенаправляет сеанс к нужной ВМ внутри VPC;
на гостевой ВМ порт 22 не опубликован в интернет;
у ВМ нет прямого публичного IP для админского доступа.

В microsrv это выглядит так:

ssh -A <vm>@msrv.space

Флаг -A включает перенаправление SSH-агента, когда ключи нужны дальше по цепочке (для Git или соседних хостов). Сам доступ при этом не требует открывать гостевой SSH наружу.

С точки зрения виртуального слоя eBPF (data plane) SSH-адрес — свойство самой виртуальной машины, а не атрибут физической сетевой карты на текущем хосте.

4. Стабильный адрес после миграции

Если SSH-адрес привязан к публичному IP конкретного прерываемого инстанса, каждая миграция или холодный перезапуск превращается в квест: найти новый адрес, обновить known_hosts, поправить CI.

Когда доступ идёт через шлюз с постоянным именем <vm>@msrv.space:

инженерам и конвейерам CI/CD не нужно переписывать инвентарные списки после переезда сервера;
живая миграция сохраняет и процессы, и привычный способ администрирования;
даже холодный перезапуск из реплицированного тома возвращает ту же точку входа, как только ВМ снова доступна.

На демо-стенде это кажется мелочью. В реальной эксплуатации это критичное свойство: правило «как зайти на машину» не должно зависеть от того, какой физический сервер (Host-NN) сейчас выполняет вычисления.

5. Практические правила доступа

Не открывайте порт 22 на всех ВМ «на всякий случай».
Разделяйте административный доступ и публикацию приложений: наружу для HTTP/TCP — HTTPS-шлюз, для администрирования — SSH-шлюз.
Храните ключи централизованно и ротируйте их. Не раскладывайте один ключ на десятки хостов без учёта.
Проверьте, что инвентарные списки, регламенты и автоматизация ссылаются на стабильные имена, а не на временные публичные IP.
В microsrv связка VPC + NAT без входящего IP + SSH-шлюз даёт безопасный контур по умолчанию при экономии около 25% относительно тарифов крупных облаков.

6. Итог

SSH без публичного IP меняет модель удалённого доступа. Вместо «каждая ВМ — отдельный вход из интернета» появляется единый аутентифицированный шлюз к машинам в частной сети. В сочетании с живой миграцией и eBPF это сохраняет и безопасность периметра, и предсказуемость повседневной работы с инфраструктурой.

Источники и что почитать дальше

OpenSSH — ssh -J (ProxyJump) vs бастион и -A forwarding агента
NIST — Guide to General Server Security, SP 800-123 — рекомендации по защите SSH и поверхности атаки порта 22
eBPF-сеть microsrv — место шлюза в data plane (§3) и живая миграция (§4 стабильный адрес)

Из практики: порт 22 гостевой ВМ не публикуется. Шлюз терминирует клиентский SSH, проверяет ключ и проксирует в VPC. Имя <vm>@msrv.space — идентичность ВМ, а не IP хоста, поэтому переживает и миграцию, и холодный перезапуск.

FAQ

Бастион vs шлюз? Бастион — джамп-хост, который вы администрируете; шлюз — точка входа платформы без публичного IP у гостя и со стабильным именем между хостами.

Нужен ли forwarding агента? Только для Git/переходов дальше; для прямого шелла в ВМ -A не обязателен.