gpg decryption fails with no secret key error
UnixEncryptionPublic Key-EncryptionGnupgUnix Problem Overview
I have a gpg .key file that is used as passphrase for decrypting a .dat.pgp file. The encrypted .data.pgp file gets successfully decrypted on one server with same .key file using following command
cat xxx_gpg.key | /usr/bin/gpg --batch --quiet -o xxx.dat --passphrase-fd O -d xxx.dat.pgp
But, when I move same key to another server xxx_gpg.key and run same above command, I get following error -
gpg: decryption failed: No secret key
EDIT:
I find that gpg --list-secret-keys
returns some data on server where it works but no results are returned for other server.
How can we configure secret key
Unix Solutions
Solution 1 - Unix
I just ran into this issue, on the gpg CLI in Arch Linux. I needed to kill the existing "gpg-agent" process, then everything was back to normal ( a new gpg-agent should auto-launch when you invoke the gpg command, again; ...).
- edit: if the process fails to reload (e.g. within a minute), execute
gpg-agent
in a terminal and/or reboot ...
Solution 2 - Unix
Looks like the secret key isn't on the other machine, so even with the right passphrase (read from a file) it wouldn't work.
These options should work, to
- Either copy the keyrings (maybe only secret keyring required, but public ring is public anyway) over to the other machine
- Or export the secret key & then import it on the other machine
A few useful looking options from man gpg
:
>--export
>Either export all keys from all keyrings (default keyrings and those
registered via option --keyring
), or if at least one name is given,
those of the given name. The new keyring is written to STDOUT or to
the file given with option --output
. Use together with --armor
to
mail those keys.
>
>--export-secret-keys
> Same as --export
, but exports the secret keys instead.
>
>--import
>--fast-import
> Import/merge keys. This adds the given keys to the keyring. The fast
version is currently just a synonym.
And maybe
>--keyring file
> Add file to the current list of keyrings. If file begins with a tilde
and a slash, these are replaced by the $HOME directory. If the file‐
name does not contain a slash, it is assumed to be in the GnuPG home
directory ("~/.gnupg" if --homedir or $GNUPGHOME is not used).
>Note that this adds a keyring to the current list. If the intent is
to use the specified keyring alone, use --keyring
along with --no-default-keyring
.
>--secret-keyring file
> Same as --keyring
but for the secret keyrings.
Solution 3 - Unix
I was trying to use aws-vault which uses pass and gnugp2 (gpg2). I'm on Ubuntu 20.04 running in WSL2.
I tried all the solutions above, and eventually, I had to do one more thing -
$ rm ~/.gnupg/S.* # remove cache
$ gpg-connect-agent reloadagent /bye # restart gpg agent
$ export GPG_TTY=$(tty) # prompt for password
# ^ This last line should be added to your ~/.bashrc file
The source of this solution is from some blog-post in Japanese, luckily there's Google Translate :)
Solution 4 - Unix
This error will arise when using the utility pass
if the terminal window is too small!
Just make the terminal window a few lines taller.
Very confusing.
EXPLANATION FOR SKEPTICS. This is a problem when using the curses version of pinentry, as described here: "because of the way they draw the dialog with curses, pinentry-curses only works on terminals which are greater than 10 lines tall"
Solution 5 - Unix
You can also sometimes get this error if you try to decrypt a secret while su
-ed to a different user on a system with GPG 2.x installed. This bug has been reported against RHEL 6 but there is no fix available; apparently this is due to some design decisions in GPG 2.x. One workaround suggested in the bug report is to run the decryption inside of a tmux or screen session. More reading here.
Solution 6 - Unix
When migrating from one machine to another-
-
Check the gpg version and supported algorithms between the two systems.
gpg --version
-
Check the presence of keys on both systems.
gpg --list-keys
pub 4096R/62999779 2020-08-04 sub 4096R/0F799997 2020-08-04
gpg --list-secret-keys
sec 4096R/62999779 2020-08-04 ssb 4096R/0F799997 2020-08-04
Check for the presence of same pair of key ids on the other machine. For decrypting, only secret key(sec) and secret sub key(ssb) will be needed.
If the key is not present on the other machine, export the keys in a file from the machine on which keys are present, scp the file and import the keys on the machine where it is missing.
Do not recreate the keys on the new machine with the same passphrase, name, user details as the newly generated key will have new unique id and "No secret key" error will still appear if source is using previously generated public key for encryption. So, export and import, this will ensure that same key id is used for decryption and encryption.
gpg --output gpg_pub_key --export <Email address>
gpg --output gpg_sec_key --export-secret-keys <Email address>
gpg --output gpg_sec_sub_key --export-secret-subkeys <Email address>
gpg --import gpg_pub_key
gpg --import gpg_sec_key
gpg --import gpg_sec_sub_key
Solution 7 - Unix
You can also be interested at the top answer in here: https://askubuntu.com/questions/1080204/gpg-problem-with-the-agent-permission-denied
basically the solution that worked for me too is:
gpg --decrypt --pinentry-mode=loopback <file>
Solution 8 - Unix
Following this procedure worked for me.
To create gpg key.
gpg --gen-key --homedir /etc/salt/gpgkeys
export the public key, secret key, and secret subkey.
gpg --homedir /etc/salt/gpgkeys --export test-key > pub.key
gpg --homedir /etc/salt/gpgkeys --export-secret-keys test-key > sec.key
gpg --homedir /etc/salt/gpgkeys --export-secret-subkeys test-key > sub.key
Now import the keys using the following command.
gpg --import pub.key
gpg --import sec.key
gpg --import sub.key
Verify if the keys are imported.
gpg --list-keys
gpg --list-secret-keys
Create a sample file.
echo "hahaha" > a.txt
Encrypt the file using the imported key
gpg --encrypt --sign --armor -r test-key a.txt
To decrypt the file, use the following command.
gpg --decrypt a.txt.asc
Solution 9 - Unix
I got the same error when trying to decrypt the key from a different user account via su - <otherUser>
. (Like jayhendren suggests in his answer)
In my case, this happened because there would normally start a graphical pinentry
prompt so I could enter the password to decrypt the key, but the su -
ed to user had no access to the (graphical) X-Window-System that was currently running.
The solution was to simply issue in that same console (as the user under which the X Server was currently running):
xhost +local:
Which gives other local users access to the currently running (local) X-Server. After that, the pinentry
prompt appeared, I could enter the password to decrypt the key and it worked...
Of course you can also forward X over ssh
connections. For this look into ssh
's -X
parameter (client side) and X11Forwarding yes
(server side).
Solution 10 - Unix
I have solved this problem, try to use root privileges, such as sudo gpg ... I think that gpg elevated without permissions does not refer to file permissions, but system
Solution 11 - Unix
The problem is that the default pinentry doesn't work remotely through ssh (even with the -X option). Solution:
sudo update-alternatives --config pinentry
Choose the pinentry-curses
or pinentry-tty
alternative.
Now you can use gpg remotely without workaround options like pinentry-mode.
Solution 12 - Unix
This just happened to me and the solution depends on the causing issue. In my case I deleted the keys I initialized the password database with and hence the solution was to delete my .password_store folder in my home directory. If you cause this problem in the same way and have no passwords stored, go for it.