Wie kann ich einen gpg-Schlüssel per ssh-agent weiterleiten?

8874
txwikinger

Ich kann die ssh-Konfigurationsdatei verwenden, um die Weiterleitung der zu ssh-agent hinzugefügten ssh-Schlüssel zu aktivieren. Wie kann ich dasselbe mit gpg-Schlüsseln machen?

28
Beide Antworten schlagen vor, Socat auszuführen, um den Unix-Socket des GPG-Agenten auf einem TCP-Port bereitzustellen. Im Gegensatz zu Unix-Sockets haben TCP-Ports jedoch nicht die gleiche Zugriffssteuerung. Insbesondere kann jeder _-Benutzer auf demselben Host eine Verbindung zu Ihrem GPG-Agenten herstellen. Dies ist wahrscheinlich in Ordnung, wenn Sie ein Einzelbenutzer-Laptop haben. Wenn sich jedoch auch andere Benutzer an demselben System anmelden können (dem System, auf dem der GPG-Agent ausgeführt wird), können sie auch auf Ihren GPG-Agenten zugreifen, was ein erhebliches Sicherheitsproblem darstellt. Wenn Sie socat direkt mit dem EXEC-Adresstyp SSH starten lassen, ist dies wahrscheinlich der beste Weg, dies zu beheben. Matthijs Kooijman vor 9 Jahren 3
Eine weitere Präsentation der openssh 6.7+ -Lösung finden Sie unter https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf phs vor 7 Jahren 0
[This] (http://www.gossamer-threads.com/lists/gnupg/users/77816) war für mich nützlich. phs vor 7 Jahren 0

5 Antworten auf die Frage

17
Brian Minton

Das neue Unix Domain Socket Forwarding von OpenSSH kann dies ab Version 6.7 direkt tun.

Sie sollten etwas können wie:

ssh -R /home/bminton/.gnupg/S.gpg-agent:/home/bminton/.gnupg/S-gpg-agent -o "StreamLocalBindUnlink=yes" -l bminton 192.168.1.9
@DrewR. Freut mich das zu hören. Brian Minton vor 8 Jahren 0
Ich habe ein erforderliches kritisches Detail gefunden: Auf dem Remote-Computer (ohne privaten Schlüssel) muss der _public_-Schlüssel der Signaturidentität vorhanden sein. Lokale GPG-Version 2.1.15 OS X, Remote 2.1.11 Linux. phs vor 7 Jahren 1
16
b0fh

BEARBEITEN: Diese Antwort ist veraltet, da in OpenSSH eine angemessene Unterstützung implementiert wurde, siehe Brian Mintons Antwort.

SSH kann nur TCP-Verbindungen innerhalb des Tunnels weiterleiten.

Sie können jedoch ein Programm verwenden, socatum den Unix-Socket über TCP mit etwas anderem weiterzuleiten (Sie benötigen socat sowohl auf dem Client als auch auf den Serverhosts):

# Get the path of gpg-agent socket: GPG_SOCK=$(echo "$GPG_AGENT_INFO" | cut -d: -f1)  # Forward some local tcp socket to the agent (while true; do socat TCP-LISTEN:12345,bind=127.0.0.1 UNIX-CONNECT:$GPG_SOCK; done) &  # Connect to the remote host via ssh, forwarding the TCP port ssh -R12345:localhost:12345 host.example.com  # (On the remote host) (while true; do socat UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent,unlink-close,unlink-early TCP4:localhost:12345; done) &

Testen Sie, ob es mit klappt gpg-connect-agent. Stellen Sie sicher, dass GPG_AGENT_INFO auf dem Remote-Host undefiniert ist, damit es wieder in den $HOME/.gnupg/S.gpg-agentSocket fällt .

Jetzt ist es hoffentlich alles, was Sie brauchen, um dies alles automatisch auszuführen!

Nun, die SSH-Agentenschlüssel werden automatisch weitergeleitet, wenn die Weiterleitung in der Konfigurationsdatei festgelegt ist. Ich werde das ausprobieren. txwikinger vor 13 Jahren 0
Du hast recht, ssh-agent benutzt auch einen Unix-Socket, hat aber spezielle Unterstützung dafür (etwas müde hier :) Trotzdem sollte die Lösung trotzdem funktionieren. b0fh vor 13 Jahren 0
Für diese Lösung wäre mein GPG-Agent über Port 12345 öffentlich zugänglich, wenn ich nicht hinter einer Firewall / NAT stünde. Dies sollte bitte in der Antwort erwähnt werden. Jonas Schäfer vor 12 Jahren 1
Ich schätze, Ihre letzte Bearbeitung hat dieses Problem behoben, Jonas? es ist jetzt nur für localhost bindend. jmtd vor 12 Jahren 0
Dies schlägt für mich mit dem folgenden Argument aus dem gpg-connect-agent des entfernten Hosts fehl: `kann keine Verbindung zum Server herstellen: ec = 31.16383 gpg-connect-agent: Fehler beim Senden des Befehls RESET: Ungültiger Wert an IPC übergeben. Der entfernte "Socat" stirbt dann. Der lokale "socat" stirbt und spricht "socat [24692] E connect (3, AF = 1" ", 2): Ungültiges Argument". [Diese Seite] (http://snafu.priv.at/interests/crypto/remotegpg.html) lässt mich glauben, dass dies niemals funktionieren wird, da der Agent den Schlüssel nicht speichert (nur die Passphrase). Wurde dies von jemandem bestätigt? jmtd vor 12 Jahren 0
@jmtd Ja, dies behebt das Datenschutzproblem. Ich konnte jedoch nicht mit socat arbeiten, weshalb ich ein Python-Skript gehackt habe, das den Trick macht: http://fpaste.org/Um0D/ (dies kann verbessert werden). Andere Probleme, die ich mit socat hatte, waren anhaltende TCP-Steckdosen und so. Jonas Schäfer vor 12 Jahren 0
@ JonasWielicki - Der Link zu fpaste.org ist jetzt defekt. Können Sie Ihr Skript über einen neuen pfaste.org-Link oder besser noch als A zu diesem Q bereitstellen? slm vor 9 Jahren 0
@slm Ich habe fpaste als informativen Kommentar verwendet. Tatsächlich kann ich mich nicht einmal daran erinnern, was es war, obwohl die Kommentare vermuten lassen, dass es sich um ein einfaches socat-like-Dienstprogramm handelt, das an localhost bindet und den Datenverkehr zwischen dem TCP und dem Unix-Socket weiterleitet. Jonas Schäfer vor 9 Jahren 0
3
antifuchs

Ich musste dasselbe tun, und mein Skript basierte auf der Lösung von b0fh, mit ein paar winzigen Modifikationen: Es fängt Exits ab und beendet Hintergrundprozesse, und es verwendet die "Fork" - und "Reuseaddr" -Optionen zum Socat, was Ihnen das erspart Schleife (und macht den Hintergrund sauber tötbar).

Das Ganze macht alles auf einmal in einem Zug vor, so dass es wahrscheinlich einem automatisierten Setup näher kommt.

Beachten Sie, dass Sie auf dem Remote-Host Folgendes benötigen:

  1. Die Schlüsselringe, die Sie zum Signieren / Entschlüsseln verwenden möchten.
  2. Abhängig von der Version von gpg auf der Fernbedienung eine gefälschte GPG_AGENT_INFOVariable. Ich fülle meine mit ~/.gnupg/S.gpg-agent:1:1- die erste 1 ist eine PID für den gpg-Agenten (ich fälsche es als "init" s, was immer läuft), die zweite ist die Versionsnummer des Agentenprotokolls. Dies sollte mit dem übereinstimmen, das auf Ihrem lokalen Computer ausgeführt wird.
 #!/bin/bash -e  FORWARD_PORT=$  trap '[ -z "$LOCAL_SOCAT" ] || kill -TERM $LOCAL_SOCAT' EXIT  GPG_SOCK=$(echo "$GPG_AGENT_INFO" | cut -d: -f1) if [ -z "$GPG_SOCK" ] ; then echo "No GPG agent configured - this won't work out." >&2 exit 1 fi  socat TCP-LISTEN:$FORWARD_PORT,bind=127.0.0.1,reuseaddr,fork UNIX-CONNECT:$GPG_SOCK & LOCAL_SOCAT=$!  ssh -R $FORWARD_PORT:127.0.0.1:$FORWARD_PORT socat 'UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent,unlink-close,unlink-early,fork,reuseaddr TCP4:localhost:$FORWARD_PORT'

Ich glaube, es gibt auch eine Lösung, bei der nur ein SSH-Befehl aufgerufen wird (Verbindung vom Remote-Host zum lokalen) -o LocalCommand, aber ich konnte nicht ganz herausfinden, wie ich das beim Beenden bequem beenden kann.

Vermissen Sie im letzten Befehl nicht ein Argument "user @ host" vor socat? Trotzdem scheitert das für mich mit "socat [6788] E connect (3, AF = 2 127.0.0.1:0, 16): Verbindung wurde abgelehnt", wenn lokal versucht wurde, gpg-connect-agent aus der Ferne zu starten. David Faure vor 7 Jahren 0
2
MaLo

In neuen Versionen von GnuPG- oder Linux-Distributionen können sich die Pfade der Sockets ändern. Diese können über herausgefunden werden

$ gpgconf --list-dirs agent-extra-socket

und

$ gpgconf --list-dirs agent-socket

Fügen Sie dann diese Pfade zu Ihrer SSH-Konfiguration hinzu:

Host remote RemoteForward <remote socket> <local socket>

Schnelle Lösung zum Kopieren der öffentlichen Schlüssel:

scp .gnupg/pubring.kbx remote:~/.gnupg/

Aktivieren Sie auf dem Remote-Computer den GPG-Agenten:

echo use-agent >> ~/.gnupg/gpg.conf

Ändern Sie auf dem Remote-Computer auch die SSH-Serverkonfiguration und fügen Sie diesen Parameter hinzu (/ etc / ssh / sshd_config):

StreamLocalBindUnlink yes

Starten Sie den SSH-Server neu, stellen Sie die Verbindung zum Remote-Computer wieder her - dann sollte es funktionieren.

Ein ausführlicheres Tutorial mit einigen Fehlerbehebungen finden Sie hier: https://mlohr.com/gpg-agent-forwarding/ MaLo vor 5 Jahren 0
Falls der entfernte Host eine aktuelle Version von Debian ausführt, scheint er `systemctl --global mask --now gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg- agent-browser.socket` ist erforderlich, um zu verhindern, dass systemd einen Socket startet, der den Remote-GPG-Agenten stiehlt. Gemäß https://bugs.debian.org/850982 ist dies das beabsichtigte Verhalten. sampi vor 5 Jahren 0
1
doak

Laut GnuPG Wiki müssen Sie den Remote-Socket S.gpg-agent.extraan den lokalen Socket weiterleiten S.gpg-agent. Außerdem müssen Sie StreamLocalBindUnlinkauf dem Server aktivieren .
Beachten Sie, dass Sie auch den öffentlichen Teil Ihres Schlüssels benötigen, der auf der Remote- GnuPG verfügbar ist .

Verwenden Sie gpgconf --list-dir agent-socketjeweils gpgconf --list-dir agent-extra-socketauf der Fernbedienung, um die tatsächlichen Pfade abzurufen.

Zusammenfassung

  1. Hinzugefügte Konfiguration für Remote /etc/sshd_config:

    StreamLocalBindUnlink yes

  2. Importieren Sie Ihren öffentlichen Schlüssel auf der Fernbedienung:

    gpg --export <your-key> >/tmp/public scp /tmp/public <remote-host>:/tmp/public ssh <remote-host> gpg --import /tmp/public

  3. Befehl zum Herstellen einer Verbindung über SSH mit aktivierter gpg-agent-Weiterleitung: (Pfade für mein Debian)

    ssh -R /run/user/1000/gnupg/S.gpg-agent:/run/user/1000/gnupg/S.gpg-agent.extra <remote-host>
@brian minton: Es funktioniert nicht für mich, wenn nicht an die zusätzliche Buchse weitergeleitet wird. doak vor 5 Jahren 0

Verwandte Probleme