Backup fails with GPG Error, Bad Session Key

About 2 months ago, I started having issues with backups. My email notices consistently show the following:

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES256.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====

This seems to happen regardless of the backup method. I’ve tried backing up to the server, backing up to my NAS using rsync, and backing up to Amazon S3. In all instances, the report is the same. The full email is as follows:

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES256.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====

Traceback (most recent call last):
  File "/home/ubuntu/mailinabox/management/", line 647, in <module>
  File "/home/ubuntu/mailinabox/management/", line 318, in perform_backup
    shell('check_call', [
  File "/home/ubuntu/mailinabox/management/", line 126, in shell
    ret = getattr(subprocess, method)(cmd_args, **kwargs)
  File "/usr/lib/python3.10/", line 369, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/duplicity', 'full', '--verbosity', 'warning', '--no-print-statistics', '--archive-dir', '/home/user-data/backup/cache', '--exclude', '/home/user-data/backup', '--volsize', '250', '--gpg-options', "'--cipher-algo=AES256'", '--allow-source-mismatch', '/home/user-data', 'file:///home/user-data/backup/encrypted']'7; returned non-zero exit status 31.

I have tried rerunning sudo mailinabox, deleting the secret key and the running curl -s | sudo -E bash. None of that has fixed anything. I still get the GPG error.

At the moment, I have no backups and this concerns me. Any help would be greatly appreciated!

Hi Heather! :slight_smile:

Have you checked with @davness on Slack? He’s the first person I’d ask about this issue.

Hmm, this may have something to do with it. Backup script failing

After that, I’d probably migrate to a completely new server.

Thanks, Alento. I went to that other topic and used the command there to downgrade duplicity. I will check in the morning to see if the backup worked this time. If it did, I will restart the backups to S3. Is this something that is likely to be an ongoing problem? Migrating to a new server really isn’t an option for me at this time. I really need to keep the IP address of the current box for the time being. At some future point I will probably need to migrate but it needs to wait.

Most VPS providers have a way to redeploy and keep IP

I use cloud servers from Digital Ocean and they do not have that option, unfortunately.

I have backups working again. For future reference for anyone else who might come across this topic and have the same issue, here is why I was getting this error message and how I resolved it:

At some point during an update, the secret_key.txt changed. When MIAB initiates a backup, it also checks the previous backups (either full or incremental) against the secret key to make sure a decrypt is possible. It didn’t help that while troubleshooting, I deleted the key and had a new one generated. Because there were previous backups stored both locally and on Amazon S3 that were encrypted with a different key, the backup failed with the “Bad Session Key” error message.

My solution was to simply delete the existing backups (that were very out of date anyway) in both locations. This resulted in MIAB generating a full backup using the current secret_key.txt to encrypt the backup. It is now successfully generating incremental nightly backups. So. If for any reason you change the secret_key.txt file, you must make sure to keep a copy of the previous key on your computer with that last set of backups in your storage location. Then you have to delete the backups in the storage location and start fresh with that new key.

This is verbose, but I always like to know why an error was generated because it helps me understand the solution.

1 Like

Also for future reference. DO does support rebuilding and keeping IP. I used it during the last upgrade. You have to use the rebuild option. How to Rebuild Droplets :: DigitalOcean Documentation

This topic was automatically closed 40 days after the last reply. New replies are no longer allowed.