SSH ProxyCommand und hostbasierte Authentifizierung: Welcher Host signiert?

Ein Ziel sieht eine TCP-Verbindung, die von der Bastion kommt, während der SSH-Client, der die Authentifizierung durchführt, weiterhin auf der Workstation läuft.

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

Hier meldet sich der Helfer an der Bastion an und bittet deren SSH-Server um eine weitergeleitete Verbindung zum Ziel. Der äußere SSH-Client der Workstation tauscht das SSH-Protokoll des Ziels über diesen Stream aus. Die Bastion liefert den Transport; sie hat den zielgerichteten SSH-Client nicht gestartet.

Dieser Unterschied ist für hostbasierte Authentifizierung wichtig. Der ssh-keysign-Helfer von OpenSSH greift auf lokale Hostschlüssel zu, um die erforderliche Signatur zu erzeugen. Eine Netzwerkquelladresse der Bastion führt nicht dazu, dass die Workstation mit dem Hostschlüssel der Bastion signiert.

Vergleichen Sie das mit:

ssh -t bastion ssh target

Dies startet ein weiteres SSH-Programm auf der Bastion. Dessen lokale Konfiguration und verfügbare Hostschlüssel gehören zu dieser Maschine, sodass es an einer bereits eingerichteten hostbasierten Vertrauensbeziehung zwischen Bastion und Ziel teilnehmen kann. Es benötigt weiterhin die entsprechende Autorisierung und Namensprüfungen des Ziels.

Die zweite Form ändert auch die Arbeitsweise der Sitzung: Sie führt einen entfernten Befehl aus und verwendet ein Terminal. Sie ist kein transparenter Ersatz für jede SSH-Dateiübertragung oder jeden Automatisierungstransport. Wählen Sie die Anordnung danach, welche Maschine sich gegenüber dem Ziel authentifizieren soll, statt die Vertrauensprüfungen des Servers abzuschwächen, damit die Quelladresse ausreichend erscheint.