3

When backup start, I have the error

===== Begin GnuPG log =====
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====

Though it seems similar to Duplicity fails with bad session key error, this seems not to be the same issue (the original question is obsolete and solved by a gpg upgrade / machine reboot, which didn't work here).

I decrypted duplicity-inc.20200914T123225Z.to.20200917T121115Z.manifest.gpg with the command gpg --verbose --decrypt duplicity-full.20200914T123225Z.manifest.gpg > duplicity-full.20200914T123225Z.manifest sucessfully, I could read the manifest, so my passphrase is OK and this is not a pure GPG issue.

This error occurs each time, and ticking "remember passphrase" changes only one thing: Deja Dup obviously stop asking for passphrase on backup start.

What is this "session key" ? Is this a Deja Dup / duplicity bug ? Do you know a workaround ?

JRo
  • 73

1 Answers1

1

Introduction comment - a possible cause of the issue

I had the same or similar issue. I followed some advice to create a totally new backup, but after some time the problem occurred again. I believe I could have - in a meantime - type in the wrong password, and after that I could not do backup anymore (just as Das Auge describled - thanks for the suggestion).

Quick answer - creating a fresh backup with newer Déjà Dup version

Installing the newer version (42.7) of Déjà Dup (from a snap package) and creating the fresh backup seems to solve the issue in my case as I had no need to restore anything I backed up before.

  1. I removed an older version of Déjà Dup with sudo apt remove deja-dup.
  2. I installed a newer version with sudo snap install deja-dup.
  3. Because the newly installed Déjà Dup couldn't start for some reason, I had to remove ~/snap/deja-dup/common/.cache folder to fix that.
  4. I started the application, set it up and created a fresh backup.

After the first backup succeeded I also tried creating new incremental backup (at least I believe that's what happens when You click a 'Back Up Now' button), typing in a wrong password (just to check the effect) and then a correct one and it worked.

Longer answer - possible options to restore the backed up data

I found a link to Wiki page considering this topic I believe (I found it in one of the comments in the issue on an official GitLab page of the project). Quotations of some parts of it below.

How to Confirm the Issue

First, if your backup files are on another server or on Google Drive, download the backup files to a local folder.

Then run the following command, replacing $BACKUPFOLDER with the path to the folder with your backup folders and $PASSPHRASE with your encryption passphrase:

for i in /$BACKUPFOLDER/*; do echo $i; if gpg --passphrase=$PASSPHRASE --batch --pinentry-mode=loopback --decrypt $i >/dev/null 2>/dev/null; then echo -e "^ \033[0;32mcorrect passphrase\033[0m"; else echo -e "^ \033[0;31mwrong passphrase\033[0m"; fi; done

If you see that some of the files have the correct passphrase and some have the wrong passphrase, you are affected by this bug.

Maybe in Your case, if You do have more than one backup file, just some of the files got encrypted using the wrong passphrase, but not the one You already tried decrypting. In my case, on the other hand, I haven't noticed any "correct passphrase" message.

How to Recover

If you are not actively trying to restore a file, (1) see below to upgrade deja-dup to avoid the problem in the future and then either (2) delete the files with the wrong passphrase and any backup files after them to clean up your backups or (3) just start backing up to a new folder.

Discover the Wrong Passphrase

It’s possible that you could discover what wrong password was used.

  1. Open up your password manager (search for “Passwords and Keys” in your app launcher). Look for a password entry called “Backup encryption password”. Open it up and click the “Show password” checkbox. Does that passphrase match what you thought your passphrase was? If not, that is probably the wrong passphrase that got used.
  2. It might be a typo version of your regular passphrase. Try a few common typo versions using the command below, replacing $BACKUPFILE with the path to one of the files that has a wrong passphrase, and $PASSPHRASE with the typo version you are trying:
if gpg --passphrase=$PASSPHRASE --batch --pinentry-mode=loopback
--decrypt $BACKUPFILE >/dev/null 2>/dev/null; then echo -e "\033[0;32mpassphrase worked\033[0m"; else echo -e
"\033[0;31mpassphrase did not work\033[0m"; fi

If you can't figure out what the wrong passphrase was, that's still OK. You can hopefully still recover the files you care about.

Manually Unpack the Files You Care About

Unfortunately, we have to perform some surgery on the chain of backup volumes. The bottom section of the Worst Case page has instructions on how to manually unpack volumes.

If you know the wrong passphrase, you can decrypt all the files needed when manually unpacking.

If you don't know the wrong password, you are going to have to skip some backup volumes. Because duplicity stores patches to files (rather than full snapshots every backup), skipping volumes might create problems when trying to patch files later. But if you're lucky, you will be able to get all the data you need.

As I could not find the right passphrase I just decided to try installing a new version of Déjà Dup as I described it in the "Quick answer" section.

kcpr
  • 1,472