SSH 2026: ProxyJump vs bastion host vs VPN — что выбрать и как не потерять аудит

Почему в 2026 вопрос «как ходить по SSH» снова важный

Раньше часто хватало пары ключей в authorized_keys и закрытого порта. Сейчас к доступу почти всегда добавляются требования: централизованный аудит, быстрый отзыв прав, минимум постоянных секретов на ноутбуках, соблюдение внутренних политик, а ещё предсказуемый онбординг (чтобы новый админ за час начал работать, а не «искал правильный ключ»).

Самые распространённые подходы к доступу в приватные сегменты и «закрытые» хосты:

• SSH ProxyJump (прыжок через промежуточный сервер);
• bastion host / jump host как отдельная точка входа (часто с контролем и аудитом);
• VPN как сетевой туннель.

Важно: это не взаимоисключающие варианты. В реальных инфраструктурах часто работает комбинация (например, VPN для сотрудников, bastion для привилегированного доступа, ProxyJump как удобный клиентский «шорткат»).

Термины: ProxyJump, bastion host и jump host — это одно и то же?

ProxyJump — функция SSH-клиента (OpenSSH), которая позволяет подключаться к целевому хосту через один или несколько промежуточных узлов без ручных туннелей. В конфиге это ProxyJump, в командной строке — ssh -J.

Jump host — любой сервер, через который вы «прыгаете» в закрытый сегмент (это может быть обычный Linux без сложной обвязки).

Bastion host — обычно «усиленный» jump host: с ограничениями, MFA/2FA (если принято), строгими политиками, логированием, иногда с записью сессий. В живых инфраструктурах термины часто смешивают, поэтому дальше будем считать: jump/bastion — это роль сервера в архитектуре, а ProxyJump — механизм подключения.

ProxyJump (ssh proxyjump): быстрый выигрыш в удобстве

Как это работает

Клиент OpenSSH устанавливает соединение к промежуточному узлу и через него проксирует подключение к целевому хосту. При этом вы не обязаны интерактивно логиниться на jump-хост: вы делаете «прямой SSH до цели сквозь него».

Пример в ~/.ssh/config:

Host bastion
  HostName bastion.example
  User ops
  IdentityFile ~/.ssh/id_ed25519

Host app-*
  User deploy
  ProxyJump bastion
  ServerAliveInterval 30
  ServerAliveCountMax 3

Команда в одну строку:

ssh -J ops@bastion.example deploy@app-01.internal

Плюсы ProxyJump

• Минимальная сложность: не нужен отдельный VPN-клиент и маршрутизация «как для сети».
• Работает почти везде, где доступен OpenSSH.
• Удобно для точечного доступа: один маршрут через bastion, без лишних зависимостей.
• Хорошо ложится на модель “zero trust per connection”: каждое подключение — отдельная проверка.

Минусы и типовые риски

• Аудит легко становится «дырявым», если вы логируете только на цели или только на bastion. Частая проблема: на bastion видно лишь факт TCP-сессии, а на целевых хостах события разрознены и плохо связываются.
• Слабое место — ключи/агенты на клиенте. Если ключи долгоживущие и утекли с ноутбука, ProxyJump не спасает.
• Agent forwarding часто включают «чтобы заработало» и забывают. Практический совет прежний: не включать agent forwarding без чёткого понимания угроз и необходимости.
• Нет “сетевой” связности: ProxyJump не заменяет VPN, когда нужно много сервисов/портов/протоколов (внутренние панели, базы, API, метрики).

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Bastion host / Jump host: контроль и аудит как продукт, а не случайность

Если ProxyJump отвечает на вопрос «как подключиться», то bastion отвечает на вопрос «где мы централизуем вход, контроль и журналирование». Типовые требования к bastion в 2026:

• единая точка входа в приватные сегменты;
• минимальный набор сервисов и регулярное обновление;
• жёсткие политики доступа (кто, куда, когда, откуда);
• audit ssh: журналирование входов и ключевых событий;
• session recording: запись интерактивных сессий (TTY recording);
• sudo logging: фиксация повышений привилегий и действий с привязкой к человеку.

Базовый bastion без «зоопарка»: на что обратить внимание

Даже если вы не внедряете тяжёлые IGA/PAM-платформы, bastion должен быть предсказуемым и повторяемым (и в деплое, и в эксплуатации).

• Отдельные учётки (никаких общих пользователей вроде ops на всю команду).
• Ограничение входа через AllowUsers, AllowGroups, Match в sshd_config плюс сетевые ACL.
• Разные ключи/политики для bastion и для внутренних хостов (в том числе разные principals/роли, если вы на сертификатах).
• Централизованные логи (минимум — пересылка journald/rsyslog в единое хранилище).

Если вам важно быстро «подружить» аудит между bastion и целевыми хостами, пригодится подход с единым форматом событий и корреляцией. Практические варианты разбирал в статье про логирование bastion и цепочек ProxyJump.

Session recording и sudo logging: что реально логировать

Логируйте не «всё подряд», а то, что позволяет ответить на три вопроса после инцидента: кто вошёл, куда и что делал.

• Факт входа: пользователь, источник, время, метод (ключ, сертификат, MFA), целевой хост.
• Интерактив: запись терминальной сессии помогает расследованиям, но требует политики хранения и доступа.
• Команды: выбор между записью всей сессии и логированием команд зависит от комплаенса и модели угроз.
• sudo logging: фиксируйте повышения привилегий и команды, добавляйте контекст (TTY, рабочая директория), если это возможно в вашей схеме.

Если у вас уже есть session recording, он часто закрывает вопрос «какие команды выполнялись». Но структурированные sudo-события всё равно удобны для поиска, алертов и отчётности.

SSH certificates (OpenSSH CA): как уходят от «вечных ключей»

Один из самых практичных шагов к управляемому доступу — перейти с долгоживущих ключей на SSH-сертификаты OpenSSH, подписанные вашей CA. Суть простая:

• у пользователя есть ключ, но сам по себе он не даёт доступ;
• доступ выдаёт сертификат с TTL (например, 8 часов), подписанный CA;
• на серверах вы доверяете CA через TrustedUserCAKeys;
• отзыв/снижение риска достигается коротким TTL, KRL и политиками выдачи.

Упрощённый пример подписи (как иллюстрация процесса):

ssh-keygen -s /etc/ssh/ca_user_key -I user-alice -n alice -V +8h alice.pub

Где -V +8h задаёт срок действия, а -n — principals (какие логины разрешены). Если хотите углубиться в TTL, KRL и практику отзыва, см. материал про OpenSSH CA, TTL и отзыв сертификатов.

VPN: когда нужен доступ «как из офиса»

VPN остаётся лучшим ответом на задачу «дать сетевую связность». Когда нужно работать не только с SSH, но и с внутренними веб-панелями, метриками, БД, кластерами и API, причём из разных инструментов (IDE, браузер, CLI-клиенты БД), VPN часто снижает трение для команды.

Плюсы VPN

• Прозрачность: после подключения сервисы доступны как в локальной сети.
• Меньше рутины для разработчиков: не нужно помнить цепочки прыжков и наборы портов.
• Единый контроль на уровне сети: маршруты, сегментация, политики, централизованная аутентификация.

Минусы VPN, о которых чаще всего забывают

• Расширение периметра: устройство пользователя становится «частью сети». Ошибки split-tunnel/full-tunnel и маршрутов могут открыть лишние сегменты.
• Аудит действий сложнее: VPN хорошо отвечает на «кто подключился», но плохо — на «что делали на сервере». А значит, audit SSH и логи на хостах всё равно нужны.
• Зависимость от клиентской среды: DNS, конфликты подсетей, обновления клиента, корпоративные агенты.
• Риск “вечных” сессий: если не настроены короткие TTL и принудительные переподключения, доступ «висит» слишком долго.

Как выбрать: матрица решений (ProxyJump vs bastion vs VPN)

Когда достаточно ProxyJump

• небольшая инфраструктура или несколько сегментов;
• доступ в основном по SSH;
• вы понимаете, где и как делаете аудит (на bastion и/или на целях);
• готовы дисциплинированно управлять ключами или сертификатами.

Когда нужен bastion/jump host как отдельный слой

• несколько команд/подрядчиков, разные права;
• обязательны session recording и sudo logging;
• нужен единый вход и быстрый offboarding;
• вы хотите уйти от «ключи везде» к SSH-сертификатам и коротким TTL.

Когда VPN объективно проще

• много внутренних сервисов и протоколов, не только SSH;
• нужен доступ «как из офиса» и минимум ручной настройки;
• есть зрелая сегментация сети и политика устройств (endpoint management).

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Комбинированные схемы, которые реально работают

Схема 1: VPN для сотрудников + bastion для privileged access

Пользователь подключается по VPN, но доступ к прод-серверам всё равно идёт через bastion с записью сессий и политиками. Так вы уменьшаете «шум» от повседневной внутренней работы и сохраняете строгий контроль там, где он критичен.

Схема 2: Bastion как единственный вход + ProxyJump для удобства

Это «правильный ProxyJump»: вход всегда через bastion, а ProxyJump используется как клиентская оптимизация. Ключевое условие — bastion не просто «маршрутизатор», а точка контроля (аутентификация, политики, аудит).

Схема 3: SSH-сертификаты + короткий TTL + минимум постоянных секретов

Ключ пользователя не даёт доступ сам по себе, а сертификат выдаётся на ограниченное время. Даже если ноутбук потерян, окно риска сокращается до TTL, а не до момента, когда кто-то вспомнит отозвать ключи на десятках серверов.

Практические настройки и «грабли»

1) Не путайте ProxyJump и agent forwarding

ProxyJump не требует agent forwarding. Если где-то «вдруг понадобилось», остановитесь и разберите цепочку: возможно, вы пытаетесь с bastion ходить на внутренние хосты как с отдельной машины, а не проксировать соединение с клиента.

2) Логируйте на bastion и на целях — но согласованно

Типичная боль аудита: на bastion один набор идентификаторов, на целях другой, и связать события тяжело. Решение чаще организационное: единые имена пользователей/principals, единая схема ролей, понятные правила «кто под кем» заходит, и централизованный сбор логов.

3) Ограничивайте, куда можно «прыгать»

Jump/bastion без ограничений по целям быстро превращается в «универсальный пропуск». Минимум — сетевые ACL. Следующий уровень — ограничения в SSH на bastion по группам и правилам Match, плюс явная сегментация сети.

4) Думайте про инвентарь и жизненный цикл доступов

Какая бы схема ни была выбрана, она должна отвечать на вопросы:

• как добавить пользователя за 10 минут и выдать только нужные доступы;
• как отозвать доступ «прямо сейчас»;
• где хранятся логи, кто имеет к ним доступ и сколько они живут;
• что происходит в аварии: bastion недоступен, VPN недоступен, CA недоступна.

Мини-чеклист выбора для команды

1. Только SSH и мало серверов — начните с ProxyJump и аккуратно настроенного jump host.
2. Нужны audit ssh, session recording, sudo logging — проектируйте bastion host как продукт (политики, журналы, хранение), а ProxyJump используйте как удобную обёртку.
3. Нужна полноценная внутренняя сеть — добавляйте VPN, но не заменяйте им аудит действий на серверах.
4. Хотите убрать «вечные ключи» — внедряйте SSH-сертификаты и короткие TTL: это улучшение работает с любым из трёх подходов.

Итог

В 2026 спор «ProxyJump vs bastion vs VPN» правильнее превращать в вопрос: какой уровень контроля и аудита вам нужен и на каком слое вы хотите решать доступ. ProxyJump быстро повышает удобство, VPN даёт сетевую связность, а bastion/jump host становится центром управления рисками: там проще внедрить audit ssh, session recording, sudo logging и перейти на SSH-сертификаты с коротким TTL.

Если выбирать «один вариант навсегда» — обычно проигрыш. Выбирайте основу (часто это bastion) и добавляйте инструменты по мере роста инфраструктуры, не ломая привычный путь админов к серверам.

Если размещаете bastion/шлюз в облаке, держите его на отдельной изолированной машине и с понятными правилами доступа. Для таких задач обычно удобнее VDS, чем смешивать роль bastion с приложениями.