I have batch encrypted some backup files using a script. The OS is CentOS 7 and the current version of gpg is 2.0.22. The important parts of the script are:

enter code here`echo Enter passphrase
read PASS

for sourcefile in $(find /quitelarge/upload/proton/ -name *.gz); do

  echo $sourcefile
  destfile=$(echo $sourcefile | sed '1 s;/quitelarge/upload/proton;/quitelarge/upload/mega;')
  gpg --batch --passphrase "$PASS" -o $destfile.gpg -c $sourcefile


When I attempted to decrypt one of the files this happened:

gpg -d agent.tar.gz.gpg
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: DBG: cleared passphrase cached with ID: SAEFA41D323D1BAE9
gpg: decryption failed: Bad session key

Yes, I did enter the correct passphrase. In researching this problem I have found reference to:

  • Different version of gpg used to encrypt and decrypt - just tried encrypting/decrypting with the same version of gpg, same error
  • Issue on Windoze with cr/lf being included in pass phrase - from what I read I do not think this is a Linux concern

I tested this process a year or more back and I could decrypt the backup files. perhaps something has changed in gpg (?) I am at a loss. Any suggestions?



p.s. As CentOS 7 is getting rather old in the tooth I tried decrypting the files on a Linux Mint 20.3 machine with gpg 2.2.19. Same issue. I have a suspicion that this may be related to the fact that gpg was upgraded at some point to gpg2. which gpg points to a link to gpg2.

I DID run the test script against a new plaintext file with the current gpg and then tried to decrypt. Same issue.

  • Change read PASS to read -r PASS and see if you get the same error. Commented Mar 22, 2022 at 19:41
  • Thank you. As I described below my underlying issue seemed to be related to an old instantiation of the gpg-agent daemon and a shoot oneself in the foot error.
    – Ken-T
    Commented Mar 23, 2022 at 13:59
  • Please remove the question. Commented Jun 29, 2023 at 1:15

1 Answer 1


I love it when I answer my own question but not necessarily when the problem is self inflicted...

The session business had me bugged. I decided to create a script to accept a passphrase, encrypt a file then decrypt the file to another name - all within one script. It did not work. I then wondered what is running in the way of gpg?

[ken@taylor20 upload]$ ps aux | grep gpg
ken       7422  0.3  0.0 121812  1064 ?        Ss   09:36   0:00 gpg-agent --daemon --use-standard-socket
ken       7598  0.0  0.0 112812   976 pts/0    S+   09:38   0:00 grep --color=auto gpg

I killed the gpg-agent daemon and my script ran. Then I went back to the original archive file I was trying to decrypt. Still no luck. I examined my archive and encrypt script and found this offending line of code


It seems that when I was last making some changes I got tired of entering the passphrase each time ran a test so I commented out the read statement and used the above. When I went back to production I uncommented the read but forgot to remove the above statement so I overrode the passphrase I entered :-( I can decrypt my file using the testing passphrase.


  • 1
    So maybe better delete the question.
    – U. Windl
    Commented Mar 30, 2022 at 13:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .