gpg decryption fails with no secret key error

Question

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

Answer 1

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 1: if the process fails to reload (e.g. within a minute), execute gpg-agent in a terminal and/or reboot ...

---

• Edit 2 [2024-02-19]: if after doing that you later encounter the "Could not open a connection to your authentication agent" error, try also (note backticks)

   eval `ssh-agent`
  

  per

  • Could not open a connection to your authentication agent
  • https://gist.github.com/mvneves/a6a69a53f039b3755900

i.e.

gpg-agent
ssh-agent
ssh-add <your id_rsa public GPG key>

Explanation:

(a) The gpg-agent should enable you to use your GPG key.

(b) ssh-agent is needed for SSH authentication (launched with the eval command above, if needed - or simply ssh-agent).

(c) With my Arch Linux installation, it appears that a recent updates introduced the authentication issue, where applications needing SSH are not seeing the gpg server / daemon - hence authentication error messages.

Example: I've been using the Krusader file manager to connect to my VPS via a sFTP over a SSH connection (requires local host gpg-agent, ssh-agent daemons). Now, all of a sudden Krusader is reporting an authentication error. As a workaround in a terminal I issued the commands above, then in the same terminal launched Krusader (krusader &), which was them able to complete the sFTP connection to my VPS.

Answer 2

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.

Answer 3

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"

Answer 4

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.

Answer 5

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 :)

Answer 6

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>

Answer 7

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

Answer 8

When migrating from one machine to another-

1. Check the gpg version and supported algorithms between the two systems.

   gpg --version

2. 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

Answer 9

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).

Answer 10

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

Answer 11

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.

Answer 12

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.