SSH через bastion: подключаемся к внутреннему серверу с ProxyJump

Внутренний сервер не имеет публичного адреса. До него можно добраться только с bastion, и первая идея — положить туда приватный ключ, войти, затем запустить второй SSH. Получается лишняя копия секрета и два отдельных ручных сеанса. OpenSSH умеет построить такой путь с клиентской машины через ProxyJump.

Опишите два узла отдельно

Host bastion-lab
    HostName bastion.example
    User operator
    IdentityFile ~/.ssh/id_ed25519_bastion
    IdentitiesOnly yes

Host app-lab
    HostName 10.20.0.15
    User deploy
    ProxyJump bastion-lab
    IdentityFile ~/.ssh/id_ed25519_app
    IdentitiesOnly yes

Сохраните блоки в пользовательском SSH-конфиге учебного окружения. Затем команда ssh app-lab сначала аутентифицируется на bastion, создаёт через него транспорт до внутреннего узла и выполняет SSH-аутентификацию с целевым сервером. Приватный ключ приложения остаётся на клиентской машине.

У каждого узла свой пользователь и ключ. Настройки целевого Host не следует считать настройками bastion: для него нужен собственный блок. Это особенно важно при нестандартном порте, отдельном IdentityFile или иных правилах подключения.

Проверьте каждый этап

ssh -G app-lab
ssh -v app-lab

Первый вызов выводит рассчитанную конфигурацию без подключения. Проверьте hostname, user и proxyjump. Второй показывает фактические этапы соединения. Если ошибка возникает при аутентификации на bastion, изменение ключа внутреннего сервера не поможет. Если bastion принят, но канал к 10.20.0.15:22 не открывается, проверяйте его доступ к внутренней сети и разрешение перенаправлений.

Например, сообщение об административном запрете открытия канала указывает на политику SSH-сервера промежуточного узла. Таймаут открытия канала больше соответствует недоступному назначению. В обоих случаях запрос ещё не дошёл до проверки пользователя deploy на конечной машине. Сохраните участок журнала, на котором меняется этап.

Сохраните проверку конечного узла

Ключ хоста внутреннего сервера клиент проверяет отдельно. При первом подключении подтвердите его fingerprint по доверенному каналу. Сам факт прохождения через известный bastion не доказывает подлинность машины за ним. Если ключ неожиданно изменился, выясните причину до продолжения работы.

Для ProxyJump не требуется включать agent forwarding. Проброс агента решает другую задачу и добавляет промежуточному узлу возможность обращаться к агенту в рамках сеанса. Когда достаточно локальной аутентификации через построенный канал, дополнительный проброс не нужен.

После успешного входа проверьте, что вы оказались на нужном сервере, затем используйте тот же псевдоним для SFTP. Общий конфиг уменьшает риск отправить файл на bastion вместо приложения. Изменение адреса внутреннего узла останется в одном месте.

Постройте понятный доступ к учебному серверу. В курсе Linux и Bash для DevOps-инженеров предусмотрены окружение, доступы и сетевые проверки. Откройте программу и продолжите от рабочего подключения к сопровождению сервиса с воспроизводимым порядком диагностики.

Ещё по теме

• mTLS в curl: где сертификат клиента, где ключ, а где доверие к серверу
• Кто задержал запрос: читаем request_time и upstream_response_time в Nginx