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 чи транспорту автоматизації. Вибирайте схему за тим, яка машина має автентифікуватися перед ціллю, замість послаблення перевірок довіри сервера, щоб адреса джерела виглядала достатньою.

Схожі статті