Ich richte ein Backup von einem lokalen Rechner auf einen Remote-Server ein.
Ich habe GPG-Schlüssel auf dem lokalen Rechner generiert und ein Test-Backup ausgeführt mit:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path
Das Backup scheint einwandfrei zu funktionieren, es werden drei Dateien 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 wiederherzustellen mit:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test
Ich erhalte die 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 habe die GPG-Schlüssel auf dem lokalen Computer mit folgendem exportiert:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key
Und importierte sie auf den Server mit:
gpg --import secret.key
gpg --import public.key
Muss noch etwas getan werden, damit die Wiederherstellung funktioniert?
Bearbeiten:
Wenn ich den Befehl ohne die PASSPHRASE-Umgebung ausführe, duplicity --encrypt-key Key D test scp://user@host/pathwird das Backup trotzdem erstellt, ohne nach der Passphrase zu fragen.
Die Ausgabe file duplicity-full.20151011T115714Z.vol1.difftar.gpglistet eine andere KeyID auf als die in --encrypt-key angegebene. Ich habe den aufgelisteten Schlüssel nicht in meinem Schlüsselbund.
Antwort1
Das Problem ist, wie im verlinkten Beitrag angegeben, dass GPG 2.1 die Passphrase für die Schlüsselauthentifizierung aus der Pipe entfernt.
Die GPG-Agenten müssen aktiviert und konfiguriert werden, damit die Wiederherstellung funktioniert.
Fügen Sie Folgendes hinzu ~/.gnupg/gpg.conf:
use-agent
pinentry-mode loopback
Und zu Ihrer ~/.gnupg/gpg-agent.conf:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Starten Sie den Agenten anschließend mit neu 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 bei der inkrementellen Wiederherstellung nicht nach der Passphrase gefragt wird.
Antwort2
Ich hatte dieses Problem bei der Verwendung sudovon zum Ausführen duplicity, wodurch nach dem privaten Schlüssel im rootStammverzeichnis von gesucht wird. Wenn der private Schlüssel nicht gefunden wird, erscheint der Fehler „Kein geheimer Schlüssel“ und - zumindest für mich - war nicht sofort klar, warum.
Die einfachste Lösung für dieses Problem bestand sudoin meinem Fall darin, die Verwendung zu vermeiden, indem ich für das Zielverzeichnis die richtigen Berechtigungen festgelegt habe.
Wenn sudodies ein 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"zum Duplicity-Befehl, wiezu dieser Antwort angegeben
Vielleicht hilft das ja jemand anderem :-)
Antwort3
Verwenden Sie GPG 2.1? Wenn ja, benötigen Duplicity und GPG einige zusätzliche Parameter, wenn Sie die Passphrase über die Umgebungsvariable übermitteln möchten.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternativ legen Sie einfach keine PASSPHRASE fest. Der GPG-Agent fragt Sie dann und merkt sich das Geheimnis für Sie.