SSH ProxyCommand și autentificarea bazată pe gazdă: care gazdă semnează?

Distingeți redirecționarea unui flux TCP printr-un bastion de pornirea unui al doilea client SSH acolo când este implicată autentificarea bazată pe gazdă.

O țintă vede o conexiune TCP venind din bastion, în timp ce clientul SSH care efectuează autentificarea rulează în continuare pe stația de lucru.

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

Aici ajutorul se conectează la bastion și cere serverului său SSH o conexiune redirecționată către țintă. Clientul SSH exterior al stației schimbă protocolul SSH al țintei prin acel flux. Bastionul asigură transportul; nu a pornit clientul SSH orientat spre țintă.

Această distincție contează pentru autentificarea bazată pe gazdă. Ajutorul ssh-keysign din OpenSSH accesează cheile de gazdă locale pentru a genera semnătura necesară. O adresă de sursă de rețea care aparține bastionului nu face stația să semneze cu cheia de gazdă a bastionului.

Comparați cu:

ssh -t bastion ssh target

Aceasta pornește un alt program SSH pe bastion. Configurația sa locală și cheile de gazdă disponibile aparțin acelei mașini, așa că poate participa la un aranjament de încredere bazat pe gazdă deja configurat între bastion și țintă. Are în continuare nevoie de autorizarea corespunzătoare și de verificările de nume ale țintei.

A doua formă schimbă și modul de funcționare al sesiunii: execută o comandă la distanță și folosește un terminal. Nu este un substitut transparent pentru fiecare transfer de fișiere SSH sau transport de automatizare. Alegeți aranjamentul în funcție de mașina care trebuie să se autentifice la țintă, în loc să slăbiți verificările de încredere ale serverului pentru ca adresa sursă să pară suficientă.

Articole similare