SSH ProxyCommand en hostgebaseerde authenticatie: welke host ondertekent?

Een doel ziet een TCP-verbinding van het bastion binnenkomen, terwijl de SSH-client die de authenticatie uitvoert nog op de werkstation draait.

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

Hier logt de helper in op het bastion en vraagt zijn SSH-server om een doorgestuurde verbinding naar het doel. De buitenste SSH-client van de werkstation wisselt het SSH-protocol van het doel uit via die stroom. Het bastion levert het transport; het heeft de op het doel gerichte SSH-client niet gestart.

Dat onderscheid is belangrijk voor hostgebaseerde authenticatie. De ssh-keysign-helper van OpenSSH gebruikt lokale hostsleutels om de vereiste handtekening te maken. Een netwerkbronadres dat bij het bastion hoort, zorgt er niet voor dat de werkstation met de hostsleutel van het bastion ondertekent.

Vergelijk dat met:

ssh -t bastion ssh target

Dit start een ander SSH-programma op het bastion. De lokale configuratie en beschikbare hostsleutels horen bij die machine, dus het kan deelnemen aan een al geconfigureerde hostgebaseerde vertrouwensregeling tussen bastion en doel. Het heeft nog steeds de bijbehorende autorisatie en naamcontroles van het doel nodig.

De tweede vorm verandert ook hoe de sessie werkt: hij voert een opdracht op afstand uit en gebruikt een terminal. Het is geen transparante vervanging voor elke SSH-bestandsoverdracht of automatiseringstransport. Kies de regeling op basis van welke machine zich bij het doel moet authenticeren, in plaats van de vertrouwenscontroles van de server te verzwakken zodat het bronadres voldoende lijkt.