SSH ProxyCommand і аўтэнтыфікацыя па хосце: які хост падпісвае?

Мэта бачыць 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 або транспарту аўтаматызацыі. Выбірайце схему па тым, якая машына павінна аўтэнтыфікавацца на мэце, а не паслабляйце праверкі даверу сервера, каб адрас крыніцы выглядаў дастатковым.