SSH Agent leitet spezifische Schlüssel und nicht alle registrierten SSH-Schlüssel weiter

Sieht so aus, als ob es mit OpenSSH 6.7 möglich ist - es unterstützt die Unix-Socket-Weiterleitung. Wir könnten sekundären ssh-agent mit bestimmten Schlüsseln starten und seinen Socket an den entfernten Host weiterleiten. Leider ist diese Version zum Zeitpunkt des Schreibens nicht für meine Server / Client-Systeme verfügbar.

Ich habe eine andere mögliche Lösung gefunden, mit socat und Standard-SSH-TCP-Weiterleitung.

Idee

1. Auf dem lokalen Host führen wir einen sekundären ssh-agent mit nur Schlüsseln aus, die wir auf dem entfernten Host sehen wollen.
2. Auf dem lokalen Host haben wir die Weiterleitung von TCP-Verbindungen auf einem Port (portXXX) zum sekundären ssh-agent-Socket eingerichtet.
3. Auf einem Remote-Host haben wir die Weiterleitung von einem Socket zu einem TCP-Port (portYYY) eingerichtet.
4. Dann richten wir eine SSH-Verbindung mit der Portweiterleitung von PortYYY der Gegenstelle zu local portXXX ein.

Anfragen an ssh Agent gehen so:

Nachteile

1. Es ist nicht vollständig sicher, da ssh-agent teilweise über TCP verfügbar ist: Benutzer von Remote-Hosts können sich unter 127.0.0.1:portYYY mit Ihrem lokalen Agenten verbinden, und andere Benutzer Ihres lokalen Hosts können sich unter 127.0.0.1 verbinden: portXXX. Sie sehen jedoch nur eine begrenzte Anzahl von Schlüsseln, die Sie diesem Agenten manuell hinzugefügt haben. Und da AllenLuce erwähnt wird, können sie es nicht erfassen, sie können es nur zur Authentifizierung verwenden, während der Agent läuft.
2. socat muss auf dem Remote-Host installiert sein. Aber es sieht so aus, als wäre es möglich einfach vorkompilierte Binärdateien hochzuladen (ich habe es unter FreeBSD getestet und es funktioniert).
3. Keine Automatisierung: Schlüssel müssen manuell über ssh-add hinzugefügt werden, die Weiterleitung erfordert 2 zusätzliche Prozesse (socat), die ausgeführt werden müssen, mehrere ssh-Verbindungen müssen manuell verwaltet werden.

Also, diese Antwort ist wahrscheinlich nur ein Beweis des Konzepts und keine Produktionslösung.

Mal sehen, wie es geht.

Anweisung

Clientseite (wo ssh-agent ausgeführt wird)

Führen Sie einen neuen ssh-agent aus. Es wird für Schlüssel verwendet, die nur auf Remote-Hosts angezeigt werden sollen.

Es druckt einige Variablen. Setze sie nicht: Du verlierst deinen Haupt-ssh-Agenten. Setzen Sie eine andere Variable mit dem vorgeschlagenen Wert von SSH_AUTH_SOCK :

Stellen Sie dann die Weiterleitung von einem TCP-Port zu unserem ssh-agent-Socket lokal her:

socat wird im Hintergrund ausgeführt. Vergiss nicht kill , wenn du fertig bist.

Fügen Sie einige Schlüssel mit ssh-add hinzu, führen Sie sie jedoch mit der modifizierten Umgebungsvariablen SSH_AUTH_SOCK :

Serverseite (Remote-Host)

Verbinden Sie sich mit dem Remote-Host mit Port-Weiterleitung. Ihr main (nicht sekundärer) ssh-Agent wird für die Authentifizierung auf HostA verwendet (wird aber nicht von ihm zur Verfügung gestellt, da wir ihn nicht weiterleiten).

Stellen Sie auf dem entfernten Host die Weiterleitung von ssh-agent socket zum selben TCP-Port wie auf Ihrem Heim-Host her:

socat wird im Hintergrund ausgeführt. Vergiss nicht kill , wenn du fertig bist. Es wird nicht automatisch beendet, wenn Sie die ssh-Verbindung schließen.

Verbindung

Auf Remote-Host-Set Umgebungsvariable für ssh zu wissen, wo Agent-Socket (aus dem vorherigen Schritt) ist. Dies kann in derselben ssh-Sitzung oder parallel dazu erfolgen.

Es ist jetzt möglich, Schlüssel des sekundären Agenten auf dem Remote-Host zu verwenden:

Die Schlüssel selbst werden nicht geteilt, indem Sie Ihren Agenten weiterleiten. Was weitergeleitet wird, ist die Möglichkeit, den ssh-agent auf Ihrem lokalen Host zu kontaktieren. Entfernte Systeme senden Challenge-Anforderungen über den Weiterleitungstunnel. Sie fordern die Schlüssel nicht selbst an.

Siehe Ссылка für eine grafische Erklärung.