Duplicity-Wiederherstellung fehlgeschlagen: Kein geheimer Schlüssel

3690
Pabi

Ich richte ein Backup von einem lokalen Rechner auf einen Remote-Server ein.
Ich habe gpg-Schlüssel auf dem lokalen Computer generiert und eine Testsicherung mit folgendem durchgeführt: 

PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path

Die Sicherung scheint gut zu funktionieren, drei Dateien werden auf dem Server erstellt.

Mein Problem ist, dass die Wiederherstellung nicht funktioniert.
Ich habe die Testdatei auf dem lokalen Computer gelöscht und versuche, sie mit folgendem Befehl wiederherzustellen:

PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test

Ich erhalte folgende Fehlermeldung:

Synchronizing remote metadata to local cache... Copying duplicity-full-signatures.20151011T011134Z.sigtar.gpg to local cache. GPGError: GPG Failed, see log below: ===== Begin GnuPG log ===== gpg: encrypted with 2048-bit RSA key, ID KeyID(of ssb), created 2015-10-11 "Name <email>" gpg: public key decryption failed: Inappropriate ioctl for device gpg: decryption failed: No secret key ===== End GnuPG log =====

Ich exportierte die gpg-Schlüssel auf dem lokalen Rechner mit:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key

Und importierte sie auf dem Server mit:
gpg --import secret.key
gpg --import public.key

Gibt es noch etwas, das getan werden muss, damit die Wiederherstellung funktioniert?

Bearbeiten:
Wenn ich den Befehl ohne die PASSPHRASE-Umgebung ausführe, wird die duplicity --encrypt-key Key D test scp://user@host/pathSicherung trotzdem erstellt, ohne nach der Passphrase zu fragen.

Ausgabe von file duplicity-full.20151011T115714Z.vol1.difftar.gpgListen eine andere KeyID als die in --encrypt-key angegebene. Ich habe nicht den aufgeführten Schlüssel in meinem Schlüsselbund.

4
Sind Sie sicher, dass Sie die Schlüssel zum richtigen Benutzer importiert haben? GnuPG verwendet Schlüsselketten für Benutzer, Dienste verwenden jedoch häufig Systembenutzer mit einem eigenen Schlüsselring. Jens Erat vor 9 Jahren 0
Es gibt nur einen Benutzer (root) auf dem Remote-Computer. Pabi vor 9 Jahren 0
Könnte mit [this] zusammenhängen (https://github.com/keybase/keybase-issues/issues/1712). Kurz gesagt: Irgendwie fragt "gpg" nicht nach der Passphrase. Daniel B vor 9 Jahren 0

3 Antworten auf die Frage

3
Pabi

Das Problem ist, wie der Link laut ede feststellte, dass gpg 2.1 die Passphrase aus der Pipe für den Schlüssel auth zurücknimmt.
Die GPG-Agenten müssen aktiviert und konfiguriert sein, damit die Wiederherstellung funktioniert.

Fügen Sie Folgendes hinzu ~/.gnupg/gpg.conf:

use-agent pinentry-mode loopback

Und zu deinem ~/gnupg/gpg-agent.conf:

pinentry-program /usr/bin/pinentry-gtk-2 allow-loopback-pinentry

Starten Sie dann den Agenten erneut mit echo RELOADAGENT | gpg-connect-agent.

Die Wiederherstellung funktioniert auch, wenn sich die Schlüssel nur auf dem lokalen Computer befinden. Ich verstehe immer noch nicht, warum er nicht nach der Passphrase fragt, wenn er inkrementelle Einstellungen vornimmt.

Beim zweiten Dateipfad fehlt der Punkt. Es sollte "~ / .gnupg / gpg-agent.conf" sein (das gleiche Verzeichnis wie die zuvor erwähnte Datei). Sam vor 6 Jahren 2
1
ede

Verwenden Sie gpg 2.1? Wenn ja, benötigen duplicity und gpg zusätzliche Parameter, wenn Sie die Passphrase über env var übergeben möchten.
https://lists.launchpad.net/duplicity-team/msg02653.html

Oder setzen Sie einfach PASSPHRASE nicht und gpg-agent fragt Sie und speichert das Geheimnis für Sie.

Ich verwende gpg 2.1.8. Wenn ich es ohne die Passphrase env: "duplicity --encrypt-key KeyID test scp: // user @ host / path" ausführe, fragt es nicht nach der Passphrase, aber die Sicherung wird trotzdem erstellt. Pabi vor 9 Jahren 0
Danach führt die Ausgabe von `file duplicity-full.20151011T115714Z.vol1.difftar.gpg 'eine andere KeyID als die in --encrypt-key angegebene aus. Ich habe nicht den aufgeführten Schlüssel in meinem Schlüsselbund. Pabi vor 9 Jahren 0
1
Pablo

Dieses Problem hatte ich bei sudoder Ausführung duplicity, wodurch nach dem privaten Schlüssel im rootHome-Verzeichnis gesucht wird . Wenn der private Schlüssel nicht gefunden wird, wird der Fehler "Kein geheimer Schlüssel" angezeigt und - zumindest für mich - war nicht sofort klar, warum.

Die einfachste Lösung für dieses Problem bestand darin, die Verwendung sudoder korrekten Berechtigungen für das Zielverzeichnis in meinem Fall zu vermeiden .

Wenn dies sudoein Muss ist, müssen die entsprechenden GPG-Optionen so eingestellt werden, dass der GPG-Schlüsselbund des Benutzers verwendet wird: Hinzufügen --gpg-options "~user/.gnupg"des Duplizitätsbefehls, wie in dieser Antwort angegeben

Vielleicht hilft das jemand anderem :-)

Wie hast du das genau gelöst? Pimp Juice IT vor 7 Jahren 0
D'oh Zur Antwort hinzugefügt Danke, dass Sie darauf hingewiesen haben. Pablo vor 7 Jahren 1

Verwandte Probleme