Настройка SSH Config для подключения через шлюз с AD-аутентификацией

Подключение через промежуточный шлюз с Active Directory – обычная история в корпоративных сетях. Вы наверняка уже используете что-то вроде ssh -t user@gateway ssh destination, но хочется упростить процесс до банального ssh destination. Конфигурационный файл SSH позволяет это сделать, но есть нюансы с путями к ключам, именами пользователей и выбором правильных директив. Давайте разберёмся, как избежать подводных камней.

Настройка SSH Config для двойного прыжка через шлюз

Основная идея – заменить ручной ввод команды с -t автоматизированной цепочкой. Если коротко: вместо ProxyJump здесь понадобится RemoteCommand. Вот рабочий пример:

Host gateway  
    HostName 192.168.1.100  
    User ad_user  
    RequestTTY yes  
    RemoteCommand ssh ad_user@destination_host

Теперь команда ssh gateway выполнит два действия:

Подключится к шлюзу с вашими AD-учётными данными
Автоматически запустит ssh-сессию на целевом хосте (обратите внимание: RemoteCommand требует явного указания пользователя даже если он совпадает!)

Параметр RequestTTY критичен – без него не сработает интерактивный ввод пароля (если не настроена беcпарольная аутентификация). Кстати, некоторые версии SSH требуют писать force вместо yes – если что-то не работает, попробуйте изменить значение.

Совет: Если шлюз и целевой хост используют один и тот же AD-аккаунт, можно указать User только в секции gateway – но я рекомендую дублировать для надёжности.

Почему ProxyJump может не подойти

ProxyJump – этот метод создаёт туннель через шлюз, а не выполняет команду на нём. Он идеален для прямого проброса портов, но:

Не работает, если на шлюзе нет прямого доступа к приватным ключам (а при AD-аутентификации их там обычно нет)
Требует, чтобы локальный ssh-клиент мог резолвить имя целевого хоста (в то время как в вашем случае это делает сам шлюз)

Попытка использовать ProxyJump приведёт к ошибкам вида “Could not resolve hostname destination_host” – потому что ваш компьютер, а не шлюз, пытается найти этот хост.

Типичные ошибки и как их обойти

1. Проблема с путями к ключам:

SSH по умолчанию ищет ключи в ~/.ssh/ локального пользователя, но на удалённом хосте (шлюзе) он будет проверять /home/ad_user/. Решений два:

Явно указать IdentityFile /home/local_user/.ssh/id_rsa в секции Host gateway – но это сработает только если шлюз разрешает аутентификацию по ключам (в AD-средах это редкость)
Использовать ssh-agent для проброса ключей – но тут могут вмешаться политики безопасности компании

2. Ошибки форматирования конфига:

Отступы должны быть табами или пробелами, но не смешанными
Имена хостов (gateway, destination) чувствительны к регистру
После RemoteCommand не должно быть других директив в той же секции Host

Проверьте конфиг через ssh -T gateway – если видите сообщение типа “Welcome to destination_host”, значит всё настроено верно.

3. Сломалась автодополнение в терминале:

Да, такое бывает при использовании RequestTTY. Чтобы исправить, добавьте в секцию:

Host gateway  
    ...  
    SetEnv TERM=xterm-256color

И напоследок: если вдруг перестало работать после перезагрузки проверьте права на ~/.ssh/config – файл должен быть доступен только владельцу (chmod 600). У меня как-то полдня ушло на поиск этой проблемы, пока я не заметил что права сменились после копирования конфига с флешки.

Теперь вы можете подключаться одной командой, не вспоминая IP-адреса и логины. Главное – не забудьте проверить настройки брандмауэра если что-то не работает: иногда корпоративные правила блокируют нестандартные ssh-сессии.