Niepowodzenie przywracania duplikatów: brak tajnego klucza

Konfiguruję kopię zapasową z komputera lokalnego na zdalny serwer.
Wygenerowałem klucze gpg na komputerze lokalnym i uruchomiłem testową kopię zapasową z:

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

Kopia zapasowa wydaje się działać poprawnie, na serwerze tworzone są trzy pliki.

Mój problem polega na tym, że nie mogę uruchomić przywracania do pracy.
Usunąłem plik testowy na komputerze lokalnym i próbuję go przywrócić za pomocą:

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

Otrzymuję następujący błąd:

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 =====

Wyeksportowałem klucze gpg na lokalnym komputerze za pomocą:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key

I zaimportowałem je na serwer za pomocą:
gpg --import secret.key
gpg --import public.key

Czy jest coś jeszcze do zrobienia, aby przywracanie działało?

Edycja:
Jeśli wykonam polecenie bez PASSPHRASE env, duplicity --encrypt-key Key D test scp://user@host/pathkopia zapasowa zostanie utworzona mimo to bez pytania o hasło.

Wyjście file duplicity-full.20151011T115714Z.vol1.difftar.gpglist zawiera inny KeyID niż ten określony w --encrypt-key. Nie mam wymienionego klucza w moim breloku.

Problem polega na tym, że, jak stwierdzono w łączonym poście, gpg 2.1 wycofuje hasło z potoku w celu autoryzacji klucza.
Agenty gpg muszą być włączone i skonfigurowane, aby przywracanie działało.

Dodaj następujące elementy do ~/.gnupg/gpg.conf:

use-agent
pinentry-mode loopback

I do twojego ~/.gnupg/gpg-agent.conf:

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

Następnie uruchom ponownie agenta za pomocą echo RELOADAGENT | gpg-connect-agent.

Przywracanie działa, nawet jeśli klucze znajdują się tylko na komputerze lokalnym. Nadal nie rozumiem, dlaczego nie prosi o hasło podczas tworzenia przyrostowego.

Czy używasz gpg 2.1? jeśli tak, duplikat i gpg wymagają dodatkowych parametrów, jeśli chcesz dostarczyć hasło za pomocą env var.
https://lists.launchpad.net/duplicity-team/msg02653.html

Alternatywnie po prostu nie ustawiaj PASSPHRASE, a gpg-agent zapyta cię i zapamięta dla ciebie sekret.

Miałem ten problem podczas używania sudodo wykonania duplicity, co powoduje, że szuka klucza prywatnego do rootkatalogu domowego. Nie znajdując na nim klucza prywatnego, pojawia się błąd „Brak tajnego klucza” i - przynajmniej dla mnie - nie jest od razu jasne, dlaczego.

Najprostszym rozwiązaniem tego problemu było uniknięcie sudo, w moim przypadku, ustawienia właściwych uprawnień do katalogu docelowego.

Jeśli sudojest to konieczne, należy ustawić odpowiednie opcje GPG, aby korzystał z pęku kluczy GPG użytkownika: dodając --gpg-options "~user/.gnupg"do polecenia duplikacji, jak podano w tej odpowiedzi

Może to pomaga komuś innemu :-)