SSH ProxyCommand i uwierzytelnianie oparte na hoście: który host podpisuje?

Odróżnij przekazywanie strumienia TCP przez bastion od uruchamiania tam drugiego klienta SSH, gdy w grę wchodzi uwierzytelnianie oparte na hoście.

Cel widzi połączenie TCP pochodzące z bastionu, podczas gdy klient SSH wykonujący uwierzytelnianie nadal działa na stacji roboczej.

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

Tutaj pomocnik loguje się na bastion i prosi jego serwer SSH o przekazane połączenie do celu. Zewnętrzny klient SSH stacji wymienia protokół SSH celu przez ten strumień. Bastion zapewnia transport; nie uruchomił klienta SSH skierowanego do celu.

Ta różnica ma znaczenie dla uwierzytelniania opartego na hoście. Pomocnik ssh-keysign w OpenSSH sięga po lokalne klucze hosta, aby wygenerować wymagany podpis. Adres źródłowy sieci należący do bastionu nie powoduje, że stacja podpisuje kluczem hosta bastionu.

Porównaj z:

ssh -t bastion ssh target

To uruchamia inny program SSH na bastionie. Jego lokalna konfiguracja i dostępne klucze hosta należą do tej maszyny, więc może uczestniczyć w już skonfigurowanym układzie zaufania opartym na hoście między bastionem a celem. Nadal potrzebuje odpowiedniej autoryzacji i sprawdzeń nazwy po stronie celu.

Druga forma zmienia też działanie sesji: wykonuje polecenie zdalne i używa terminala. Nie jest przezroczystym zamiennikiem każdego transferu plików SSH ani transportu automatyzacji. Wybierz układ według tego, która maszyna ma się uwierzytelnić przed celem, zamiast osłabiać sprawdzenia zaufania serwera, by adres źródłowy wyglądał na wystarczający.

Powiązane artykuły