Pages : 1
#1 Le 15/02/2019, à 23:46
- RidingAround
GPG : echec de chiffrement
Bonjour à tous, je dois sauvegarder un serveur et expédier en rsync mon produit.
Voici ce qui me gêne :
duplicity 0.7.06 (December 07, 2015)
Args:
/usr/bin/duplicity incremental --progress --verbosity 8 --full-if-older-than 1M --encrypt-key D13F678A --sign-key D13F678A --allow-source-mismatch --exclude /bin --exclude /tmp --exclude /dev --exclude /lib --exclude /media --exclude /opt --exclude /sbin --exclude /sys --exclude /usr --exclude /boot --exclude /lib64 --exclude /mnt --exclude /proc --exclude /run --exclude /srv --exclude /tmp / file:///tmp/backups --log-file /home/maxime/backups/logs/duplicity_backup.log
donne
Linux audit 4.9.149-xxxx-std-ipv6-64 #539070 SMP Thu Jan 10 08:31:30 UTC 2019 x86_64 x86_64
/usr/bin/python2 2.7.12 (default, Nov 12 2018, 14:36:49)
[GCC 5.4.0 20160609]
================================================================================
Using temporary directory /tmp/duplicity-IqfdBW-tempdir
Temp has 3312648192 available, backup will use approx 34078720.
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20190114T230002Z.sigtar.gpg to local cache.
GPG error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 1532, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1526, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1380, in main
do_backup(action)
File "/usr/bin/duplicity", line 1401, in do_backup
sync_archive(decrypt)
File "/usr/bin/duplicity", line 1188, in sync_archive
copy_to_local(fn)
File "/usr/bin/duplicity", line 1133, in copy_to_local
gpg.GzipWriteFile(src_iter, tdp.name, size=sys.maxsize)
File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 401, in GzipWriteFile
new_block = block_iter.next()
File "/usr/bin/duplicity", line 1113, in next
self.fileobj.close()
File "/usr/lib/python2.7/dist-packages/duplicity/dup_temp.py", line 226, in close
assert not self.fileobj.close()
File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 259, in close
self.gpg_failed()
File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 226, in gpg_failed
raise GPGError(msg)
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with RSA key, ID D13F678A
gpg: decryption failed: secret key not available
===== End GnuPG log =====
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with RSA key, ID D13F678A
gpg: decryption failed: secret key not available
===== End GnuPG log =====
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with RSA key, ID D13F678A
gpg: decryption failed: secret key not available
===== End GnuPG log =====
Alors je précise que j'ai bien une bi-clé gpg fraîchement générée sans accroc, et que mes dossiers et fichiers .gnupg ont les bons droits.
Je vois pas pourquoi il me parle d'une clé ayant une ID que je n'ai pas, ni pourquoi il me dit qu'il ne peut pas décrypter, alors qu'on lui demande de crypter.
Merci
Update:
Tiens, j'ai trouvé pourquoi il me parle de déchiffrer : duplicity regarde les éléments présents dans le dossier backups, et ne peut déterminer ce qui est nouveau, faute de pouvoir déchiffrer une ancienne sauvegarde faite avec une autre clé.
MAIS, j'ai un autre souci, c'est que quand je lance la sauvegarde, j'ai un message GPG relatif aux droits du dossier .gnupg, alors qu'il est bon (appartient au user, et droits 700) - je précise que le script est lancé par sudo ./script.sh, et qu'il se situe dans le home de l'utilisateur maxime.
Quand je lance le cript sans sudo, voilà ce que ça donne :
GPG error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 1532, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1526, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1380, in main
do_backup(action)
File "/usr/bin/duplicity", line 1496, in do_backup
full_backup(col_stats)
File "/usr/bin/duplicity", line 567, in full_backup
globals.backend)
File "/usr/bin/duplicity", line 425, in write_multivol
at_end = gpg.GPGWriteFile(tarblock_iter, tdp.name, globals.gpg_profile, globals.volsize)
File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 356, in GPGWriteFile
file.close()
File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 241, in close
self.gpg_failed()
File "/usr/lib/python2.7/dist-packages/duplicity/gpg.py", line 226, in gpg_failed
raise GPGError(msg)
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: no default secret key: secret key not available
gpg: [stdin]: sign+encrypt failed: secret key not available
===== End GnuPG log =====
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: no default secret key: secret key not available
gpg: [stdin]: sign+encrypt failed: secret key not available
===== End GnuPG log =====
Traceback (most recent call last):
File "/usr/bin/duplicity", line 1532, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1526, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1380, in main
do_backup(action)
File "/usr/bin/duplicity", line 1459, in do_backup
verify(col_stats)
File "/usr/bin/duplicity", line 855, in verify
collated = diffdir.collate2iters(restore_get_patched_rop_iter(col_stats),
File "/usr/bin/duplicity", line 744, in restore_get_patched_rop_iter
backup_chain = col_stats.get_backup_chain_at_time(time)
File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 970, in get_backup_chain_at_time
raise CollectionsError("No backup chains found")
CollectionsError: No backup chains found
Dernière modification par RidingAround (Le 16/02/2019, à 14:08)
RAID 5 luks 4x1To - SSD M2 120 - RX 480 - 4x4 DDR4 - Xeon
24 ans de Linux ! Ubuntu aux particuliers -> puis aux entreprises -> monter des serveurs -> sécuriser les entreprises -> des armoires -> des clusters -> des conteneurs ... que du bonheur :}
Hors ligne
#2 Le 18/02/2019, à 16:04
- RidingAround
Re : GPG : echec de chiffrement
Ok j'ai trouvé :
- le déchiffrement en échec venait d'une tentative du logiciel de comparer la précédente sauvegarde, effectuée par une clé différente.
- le problème de .gnupg venait du fait que la sauvegarde tentait de prendre en compte ce dossier, protégé biensûr
sinon, le processus fonctionnait jusqu'à la fin, mais je l'avais stoppé à cause des messages du mode verbose, et parce qu'il était très long.
RAID 5 luks 4x1To - SSD M2 120 - RX 480 - 4x4 DDR4 - Xeon
24 ans de Linux ! Ubuntu aux particuliers -> puis aux entreprises -> monter des serveurs -> sécuriser les entreprises -> des armoires -> des clusters -> des conteneurs ... que du bonheur :}
Hors ligne