Estoy configurando una copia de seguridad desde una máquina local a un servidor remoto.
Generé claves gpg en la máquina local y ejecuté una copia de seguridad de prueba con:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID test scp://user@server/path
La copia de seguridad parece funcionar bien, se crean tres archivos en el servidor.
Mi problema es que no puedo hacer que la restauración funcione.
Eliminé el archivo de prueba en la máquina local e intenté restaurarlo con:
PASSPHRASE="MyGPGPassphrase" duplicity --encrypt-key KeyID scp://user@server/path test
Obtuve el siguiente error:
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 =====
Exporté las claves gpg en la máquina local con:
gpg --export-secret-key KeyID > secret.key
gpg --armor --export KeyID > public.key
Y los importó al servidor con:
gpg --import secret.key
gpg --import public.key
¿Hay algo más que deba hacerse para que la restauración funcione?
Editar:
si ejecuto el comando sin el entorno PASSPHRASE, duplicity --encrypt-key Key D test scp://user@host/pathla copia de seguridad se crea de todos modos sin solicitar la frase de contraseña.
La salida de file duplicity-full.20151011T115714Z.vol1.difftar.gpgenumera un KeyID diferente al especificado en --encrypt-key. No tengo la clave listada en mi llavero.
Respuesta1
El problema es, como indica la publicación vinculada, que gpg 2.1 retira la frase de contraseña de la tubería para la autenticación clave.
Los agentes gpg deben estar habilitados y configurados para que la restauración funcione.
Agregue lo siguiente a ~/.gnupg/gpg.conf:
use-agent
pinentry-mode loopback
Y a tu ~/.gnupg/gpg-agent.conf:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Luego reinicie el agente con echo RELOADAGENT | gpg-connect-agent.
La restauración funciona incluso si las claves están solo en la máquina local. Sin embargo, todavía no entiendo por qué no solicita la frase de contraseña cuando se realiza de forma incremental.
Respuesta2
Tuve este problema al usar sudoto ejecutar duplicity, lo que hace que busque la clave privada en rootel directorio de inicio. Al no encontrar la clave privada, aparece el error "Sin clave secreta" y, al menos para mí, no quedó claro de inmediato por qué.
La solución más sencilla a este problema fue evitar el uso sudo, en mi caso, configurando los permisos correctos en el directorio de destino.
Si sudoes imprescindible, entonces se deben configurar las opciones GPG apropiadas para que utilice el llavero GPG del usuario: agregando --gpg-options "~user/.gnupg"al comando duplicity, comoindicado en esta respuesta
Quizás esto ayude a alguien más :-)
Respuesta3
¿Estás usando gpg 2.1? En caso afirmativo, duplicity y gpg necesitan algunos parámetros adicionales si desea entregar la frase de contraseña a través de env var.
https://lists.launchpad.net/duplicity-team/msg02653.html
Alternativamente, simplemente no establezca FRASE DE CONTRASEÑA y gpg-agent le preguntará y memorizará el secreto por usted.