Estou configurando um backup de uma máquina local para um servidor remoto.
Gerei chaves gpg na máquina local e executei um backup de teste com:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path
O backup parece funcionar bem, três arquivos são criados no servidor.
Meu problema é que não consigo fazer a restauração funcionar.
Excluí o arquivo de teste na máquina local e tentei restaurá-lo com:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test
Estou tendo o erro a seguir:
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 =====
Exportei as chaves gpg na máquina local com:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key
E importou-os para o servidor com:
gpg --import secret.key
gpg --import public.key
Há mais alguma coisa que precisa ser feita para que a restauração funcione?
Editar:
Se eu executar o comando sem o ambiente PASSPHRASE, duplicity --encrypt-key Key D test scp://user@host/patho backup será criado de qualquer maneira, sem solicitar a senha.
A saída de file duplicity-full.20151011T115714Z.vol1.difftar.gpglista um KeyID diferente daquele especificado em --encrypt-key. Não tenho a chave listada em meu chaveiro.
Responder1
O problema é, como afirma a postagem vinculada, que o gpg 2.1 retira a senha do pipe para autenticação de chave.
Os agentes gpg precisam ser habilitados e configurados para que a restauração funcione.
Adicione o seguinte a ~/.gnupg/gpg.conf:
use-agent
pinentry-mode loopback
E para o seu ~/.gnupg/gpg-agent.conf:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Em seguida, reinicie o agente com echo RELOADAGENT | gpg-connect-agent.
A restauração funciona mesmo que as chaves estejam apenas na máquina local. Ainda não entendo por que ele não pede a senha ao fazer incremental.
Responder2
Eu tive esse problema ao usar sudoto execute duplicity, o que faz com que ele procure a chave privada no rootdiretório inicial de. Não encontrando a chave privada, o erro "Sem chave secreta" aparece e - pelo menos para mim - não ficou imediatamente claro o porquê.
A solução mais simples para esse problema foi evitar o uso sudo, no meu caso, definindo as permissões corretas no diretório de destino.
Se sudofor obrigatório, as opções GPG apropriadas precisam ser definidas para que ele use as chaves GPG do usuário: adicionando --gpg-options "~user/.gnupg"ao comando duplicity, comodeclarado nesta resposta
Talvez isso ajude outra pessoa :-)
Responder3
Você está usando gpg 2.1? se sim, duplicidade e gpg precisam de alguns parâmetros extras se você quiser entregar a senha via env var.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternativamente, simplesmente não defina SENHA e o gpg-agent irá perguntar e memorizar o segredo para você.