SSH ProxyCommand и аутентификация по хосту: какой хост подписывает?

Отличайте пересылку TCP-потока через бастион от запуска там второго SSH-клиента, когда задействована аутентификация по хосту.

Цель видит TCP-соединение, идущее от бастиона, хотя SSH-клиент, выполняющий аутентификацию, всё ещё работает на рабочей станции.

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

Здесь вспомогательная программа входит на бастион и просит его SSH-сервер о пересланном соединении к цели. Внешний SSH-клиент рабочей станции обменивается протоколом SSH цели через этот поток. Бастион обеспечивает транспорт; он не запускал SSH-клиент, обращённый к цели.

Это различие важно для аутентификации по хосту. Помощник ssh-keysign в OpenSSH обращается к локальным ключам хоста, чтобы создать нужную подпись. Сетевой адрес источника, принадлежащий бастиону, не заставляет рабочую станцию подписывать ключом хоста бастиона.

Сравните с:

ssh -t bastion ssh target

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

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

Похожие статьи