SSH-Agent leitet bestimmte Schlüssel weiter, anstatt alle registrierten SSH-Schlüssel.

Question

Ich verwende Agenten-Weiterleitung, es funktioniert gut. Aber der SSH-Client teilt alle registrierten (ssh-add) Schlüssel mit dem entfernten Server. Ich habe persönliche Schlüssel, die ich nicht mit dem entfernten Server teilen möchte. Gibt es eine Möglichkeit zu begrenzen, welche Schlüssel weitergeleitet werden?

Ich habe mehrere GitHub-Konten und AWS-Konten. Ich möchte nicht alle SSH-Schlüssel teilen.

Answer 1

Es scheint möglich zu sein mit OpenSSH 6.7 - es unterstützt Unix-Socket-Weiterleitung. Wir könnten einen sekundären ssh-agent mit spezifischen Schlüsseln starten und seinen Socket zum Remote-Host weiterleiten. Leider ist diese Version zum Zeitpunkt des Schreibens nicht für meine Server-/Client-Systeme verfügbar.

Ich habe eine weitere mögliche Lösung gefunden, indem ich socat und die Standard-SSH-TCP-Weiterleitung verwende.

Idee

1. Auf dem lokalen Host führen wir einen sekundären ssh-agent nur mit den Schlüsseln aus, die wir auf dem Remote-Host sehen möchten.
2. Auf dem lokalen Host richten wir die Weiterleitung von TCP-Verbindungen auf einem bestimmten Port (PortXXX) zum Socket des sekundären ssh-agent ein.
3. Auf dem Remote-Host richten wir die Weiterleitung von einem Socket zu einem bestimmten TCP-Port (PortYYY) ein.
4. Dann stellen wir eine SSH-Verbindung mit Portweiterleitung vom entfernten PortYYY zum lokalen PortXXX her.

Anfragen an den ssh-agent werden so verarbeitet:

lokaler ssh-agent (sekundär)
    ^
    |
    v
/tmp/ssh-.../agent.ZZZZZ   - Agent-Socket
    ^
    |   (socat lokal)
    v
localhost:portXXX
    ^
    |   (SSH-Portweiterleitung)
    v
Remote-Host: localhost:portYYY
    ^
    |   (socat remote)
    v
 $HOME/tmp/agent.socket
    ^
    |   (Anfragen für Authentifizierung über Agent)
    v
 SSH_AUTH_SOCK=$HOME/tmp/agent.socket
    ^
    |   (verwendet SSH_AUTH_SOCK-Variable, um Agent-Socket zu finden)
    v
   SSH

Nachteile

1. Es ist nicht komplett sicher, da der ssh-agent teilweise über TCP verfügbar wird: Benutzer des Remote-Hosts können sich mit Ihrem lokalen Agenten unter 127.0.0.1:PortYYY verbinden, und andere Benutzer Ihres lokalen Hosts können sich unter 127.0.0.1:PortXXX verbinden. Aber sie sehen nur einen begrenzten Satz von Schlüsseln, die Sie manuell zu diesem Agenten hinzugefügt haben. Und, wie AllenLuce erwähnt hat, können sie ihn nicht abgreifen, sie können ihn nur für die Authentifizierung nutzen, solange der Agent läuft.
2. socat muss auf dem Remote-Host installiert sein. Aber es scheint möglich zu sein, einfach eine vorkompilierte Binärdatei hochzuladen (Ich habe es auf FreeBSD getestet und es funktioniert).
3. Keine Automatisierung: Schlüssel müssen manuell über ssh-add hinzugefügt werden, Weiterleitung erfordert 2 zusätzliche Prozesse (socat), die ausgeführt werden müssen, mehrere SSH-Verbindungen müssen manuell verwaltet werden.

Daher ist diese Antwort wahrscheinlich nur ein Proof-of-Concept und keine Produktionslösung.

Schauen wir, wie es gemacht werden kann.

Anleitung

Client-Seite (wo ssh-agent läuft)

Führen Sie einen neuen ssh-agent aus. Er wird für Schlüssel verwendet, die Sie nur auf dem Remote-Rechner sehen möchten.

$ ssh-agent # unten ist der Ausgabe des ssh-agent, FÜHREN SIE DIESE BEFEHLE UNTEN NICHT TATSÄCHLICH AUS
SSH_AUTH_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982; export SSH_AUTH_SOCK;
SSH_AGENT_PID=22983; export SSH_AGENT_PID;

Es werden einige Variablen gedruckt. Setzen Sie sie nicht: Sie verlieren Ihren Haupt-ssh-Agenten. Setzen Sie eine andere Variable mit dem vorgeschlagenen Wert von SSH_AUTH_SOCK:

SSH_AUTH_SECONDARY_SOCK=/tmp/ssh-qVnT0UsgV6yO/agent.22982

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

PORT=9898
socat TCP4-LISTEN:$PORT,bind=127.0.0.1,fork UNIX-CONNECT:$SSH_AUTH_SECONDARY_SOCK &

socat wird im Hintergrund ausgeführt. Vergessen Sie nicht, es mit kill zu beenden, wenn Sie fertig sind.

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

SSH_AUTH_SOCK=$SSH_AUTH_SECONDARY_SOCK ssh-add

Server-Seite (Remote-Host)

Stellen Sie eine Verbindung zum Remote-Host mit Portweiterleitung her. Ihr hauptsächlicher (nicht sekundärer) ssh-agent wird für die Authentifizierung auf HostA verwendet (steht jedoch nicht zur Verfügung, da wir ihn nicht weiterleiten).

Heim-Host$ PORT=9898 # gleicher Port wie oben
Heim-Host$ ssh -R $PORT:localhost:$PORT BenutzerA@HostA

Richten Sie auf dem Remote-Host die Weiterleitung vom ssh-agent-Socket zum gleichen TCP-Port wie auf Ihrem Heim-Host ein:

Remote-Host$ PORT=9898 # gleicher Port wie auf dem Home-Host
Remote-Host$ mkdir -p $HOME/tmp
Remote-Host$ SOCKET=$HOME/tmp/ssh-agent.socket
Remote-Host$ socat UNIX-LISTEN:$SOCKET,fork TCP4:localhost:$PORT &

socat wird im Hintergrund ausgeführt. Vergessen Sie nicht, es mit kill zu beenden, wenn Sie fertig sind. Es beendet sich nicht automatisch, wenn Sie die SSH-Verbindung schließen.

Verbindung

Setzen Sie auf dem Remote-Host eine Umgebungsvariable, damit ssh weiß, wo der Agent-Socket (vom vorherigen Schritt) ist. Dies kann in derselben SSH-Sitzung oder in einer parallelen erfolgen.

Remote-Host$ export SSH_AUTH_SOCK=$HOME/tmp/ssh-agent.socket

Jetzt ist es möglich, die Schlüssel des sekundären Agents auf dem Remote-Host zu verwenden:

Remote-Host$ ssh BenutzerB@HostB # verwendet sekundären ssh-agent
Willkommen bei HostB!

Answer 2

Die Schlüssel selbst werden nicht weitergeleitet, indem Ihr Agent sie weitergibt. Was weitergeleitet wird, ist die Fähigkeit, den ssh-agent auf Ihrem lokalen Host zu kontaktieren. Remote-Systeme senden Herausforderungsanfragen durch den Weiterleitungstunnel. Sie fordern nicht die Schlüssel selbst an.

Siehe http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd für eine grafische Erklärung.