gpg 解密失败，没有密钥错误
gpg decryption fails with no secret key error
我有一个 gpg .key 文件用作解密 .dat.pgp 文件的密码。加密的 .data.pgp 文件使用以下命令在具有相同 .key 文件的一台服务器上成功解密
cat xxx_gpg.key | /usr/bin/gpg --batch --quiet -o xxx.dat --passphrase-fd O -d xxx.dat.pgp
但是，当我将相同的密钥移动到另一台服务器 xxx_gpg.key 和 运行 相同的上述命令时，我收到以下错误 -
gpg: decryption failed: No secret key
编辑：
我发现 gpg --list-secret-keys returns 它工作的服务器上的一些数据，但没有返回其他服务器的结果。
我们如何配置密钥
看起来密钥不在另一台机器上，所以即使使用正确的密码（从文件中读取）它也不会起作用。
这些选项应该有效，
- 复制密钥环（可能只需要秘密密钥环，但 public 环是 public 无论如何）到另一台机器
- 或者导出密钥然后在另一台机器上导入它
来自 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.
也许
--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.
我刚刚 运行 在 Arch Linux 的 gpg CLI 上解决了这个问题。我需要终止现有的“gpg-agent”进程，然后一切恢复正常（当您再次调用 gpg 命令时，新的 gpg-agent 应该自动启动；...）。
- 编辑：如果进程无法重新加载（例如在一分钟内），请在终端中执行
gpg-agent and/or 重启 ...
如果您在安装了 GPG 2.x 的系统上 su-ed 到不同用户时尝试解密秘密，有时也会出现此错误。 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.
如果终端window太小，使用实用程序pass时会出现此错误！
只需将终端 window 高几行即可。
非常混乱。
对怀疑论者的解释。这是使用 curses 版本的 pinentry 时的问题，如所述here：“因为他们用 curses 绘制对话框的方式, pinentry-curses 仅适用于高度大于 10 行的终端
遵循此过程对我有用。
创建 gpg 密钥。
gpg --gen-key --homedir /etc/salt/gpgkeys
导出 public 密钥、秘密密钥和秘密子密钥。
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
现在使用以下命令导入密钥。
gpg --import pub.key
gpg --import sec.key
gpg --import sub.key
验证密钥是否已导入。
gpg --list-keys
gpg --list-secret-keys
创建示例文件。
echo "hahaha" > a.txt
使用导入的密钥加密文件
gpg --encrypt --sign --armor -r test-key a.txt
要解密文件，请使用以下命令。
gpg --decrypt a.txt.asc
尝试通过 su - <otherUser> 从不同的用户帐户解密密钥时，我遇到了同样的错误。 （就像 jayhendren 在他的回答中建议的那样）
在我的例子中，发生这种情况是因为通常会启动图形 pinentry 提示，因此我可以输入密码来解密密钥，但是 su -ed 用户无法访问（图形）X-Window-当前为 运行.
的系统
解决方案是简单地在同一个控制台中发出（作为 X 服务器当前 运行 所在的用户）：
xhost +local:
这让其他 本地用户 可以访问当前 运行 (local) X-Server。之后出现pinentry提示，我可以输入密码解密密钥成功了...
当然您也可以通过 ssh 连接转发 X。为此，请查看 ssh 的 -X 参数（客户端）和 X11Forwarding yes（服务器端）。
从一台机器迁移到另一台机器时-
检查两个系统之间的gpg版本和支持的算法。
gpg --version
检查两个系统上是否存在密钥。
gpg--list-keys
发布 4096R/62999779 2020-08-04
sub 4096R/0F799997 2020-08-04
gpg--list-secret-keys
秒 4096R/62999779 2020-08-04
ssb 4096R/0F799997 2020-08-04
检查另一台机器上是否存在同一对 密钥 ID。解密时，只需要密钥（sec）和子密钥（ssb）。
如果另一台机器上不存在密钥，则从存在密钥的机器上导出文件中的密钥，scp 文件并在缺少密钥的机器上导入密钥。
不要在新机器上使用相同的密码短语、名称、用户详细信息重新创建密钥，因为新生成的密钥将具有新的唯一 ID，如果源使用以前生成的 public 加密密钥。所以，导出和导入，这将确保相同的密钥id用于解密和加密。
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
我已经解决了这个问题，尝试使用root权限，比如sudo gpg ...
我认为 gpg elevated without permissions 不是指文件权限，而是 system
您也可以对此处的最佳答案感兴趣：
https://askubuntu.com/questions/1080204/gpg-problem-with-the-agent-permission-denied
基本上对我也适用的解决方案是：
gpg --decrypt --pinentry-mode=loopback <file>
我正在尝试使用 aws-vault which uses pass and gnugp2 (gpg2)。我在 WSL2 Ubuntu 20.04 运行。
我尝试了上面所有的解决方案，最后，我不得不多做一件事-
$ 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
这个解决方案的来源来自一些 blog-post in Japanese，幸运的是有 Google 翻译 :)
问题是默认的 pinentry 不能通过 ssh 远程工作（即使使用 -X 选项）。解决方案：
sudo update-alternatives --config pinentry
选择 pinentry-curses 或 pinentry-tty 选项。
现在您可以远程使用 gpg，而无需像 pinentry-mode 这样的解决方法选项。
这只是发生在我身上，解决方案取决于引起的问题。
在我的例子中，我删除了用于初始化密码数据库的密钥，因此解决方案是删除我的主目录中的 .password_store 文件夹。如果您以同样的方式导致此问题并且没有存储密码，那就去吧。
我有一个 gpg .key 文件用作解密 .dat.pgp 文件的密码。加密的 .data.pgp 文件使用以下命令在具有相同 .key 文件的一台服务器上成功解密
cat xxx_gpg.key | /usr/bin/gpg --batch --quiet -o xxx.dat --passphrase-fd O -d xxx.dat.pgp
但是，当我将相同的密钥移动到另一台服务器 xxx_gpg.key 和 运行 相同的上述命令时，我收到以下错误 -
gpg: decryption failed: No secret key
编辑：
我发现 gpg --list-secret-keys returns 它工作的服务器上的一些数据，但没有返回其他服务器的结果。
我们如何配置密钥
看起来密钥不在另一台机器上，所以即使使用正确的密码（从文件中读取）它也不会起作用。
这些选项应该有效，
- 复制密钥环（可能只需要秘密密钥环，但 public 环是 public 无论如何）到另一台机器
- 或者导出密钥然后在另一台机器上导入它
来自 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--armorto 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.
也许
--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
--keyringalong with--no-default-keyring.
--secret-keyring file
Same as--keyringbut for the secret keyrings.
我刚刚 运行 在 Arch Linux 的 gpg CLI 上解决了这个问题。我需要终止现有的“gpg-agent”进程，然后一切恢复正常（当您再次调用 gpg 命令时，新的 gpg-agent 应该自动启动；...）。
- 编辑：如果进程无法重新加载（例如在一分钟内），请在终端中执行
gpg-agentand/or 重启 ...
如果您在安装了 GPG 2.x 的系统上 su-ed 到不同用户时尝试解密秘密，有时也会出现此错误。 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.
如果终端window太小，使用实用程序pass时会出现此错误！
只需将终端 window 高几行即可。
非常混乱。
对怀疑论者的解释。这是使用 curses 版本的 pinentry 时的问题，如所述here：“因为他们用 curses 绘制对话框的方式, pinentry-curses 仅适用于高度大于 10 行的终端
遵循此过程对我有用。
创建 gpg 密钥。
gpg --gen-key --homedir /etc/salt/gpgkeys
导出 public 密钥、秘密密钥和秘密子密钥。
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
现在使用以下命令导入密钥。
gpg --import pub.key
gpg --import sec.key
gpg --import sub.key
验证密钥是否已导入。
gpg --list-keys
gpg --list-secret-keys
创建示例文件。
echo "hahaha" > a.txt
使用导入的密钥加密文件
gpg --encrypt --sign --armor -r test-key a.txt
要解密文件，请使用以下命令。
gpg --decrypt a.txt.asc
尝试通过 su - <otherUser> 从不同的用户帐户解密密钥时，我遇到了同样的错误。 （就像 jayhendren 在他的回答中建议的那样）
在我的例子中，发生这种情况是因为通常会启动图形 pinentry 提示，因此我可以输入密码来解密密钥，但是 su -ed 用户无法访问（图形）X-Window-当前为 运行.
解决方案是简单地在同一个控制台中发出（作为 X 服务器当前 运行 所在的用户）：
xhost +local:
这让其他 本地用户 可以访问当前 运行 (local) X-Server。之后出现pinentry提示，我可以输入密码解密密钥成功了...
当然您也可以通过 ssh 连接转发 X。为此，请查看 ssh 的 -X 参数（客户端）和 X11Forwarding yes（服务器端）。
从一台机器迁移到另一台机器时-
检查两个系统之间的gpg版本和支持的算法。
gpg --version
检查两个系统上是否存在密钥。
gpg--list-keys
发布 4096R/62999779 2020-08-04 sub 4096R/0F799997 2020-08-04
gpg--list-secret-keys
秒 4096R/62999779 2020-08-04 ssb 4096R/0F799997 2020-08-04
检查另一台机器上是否存在同一对 密钥 ID。解密时，只需要密钥（sec）和子密钥（ssb）。
如果另一台机器上不存在密钥，则从存在密钥的机器上导出文件中的密钥，scp 文件并在缺少密钥的机器上导入密钥。
不要在新机器上使用相同的密码短语、名称、用户详细信息重新创建密钥，因为新生成的密钥将具有新的唯一 ID，如果源使用以前生成的 public 加密密钥。所以，导出和导入，这将确保相同的密钥id用于解密和加密。
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
我已经解决了这个问题，尝试使用root权限，比如sudo gpg ... 我认为 gpg elevated without permissions 不是指文件权限，而是 system
您也可以对此处的最佳答案感兴趣： https://askubuntu.com/questions/1080204/gpg-problem-with-the-agent-permission-denied
基本上对我也适用的解决方案是：
gpg --decrypt --pinentry-mode=loopback <file>
我正在尝试使用 aws-vault which uses pass and gnugp2 (gpg2)。我在 WSL2 Ubuntu 20.04 运行。
我尝试了上面所有的解决方案，最后，我不得不多做一件事-
$ 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
这个解决方案的来源来自一些 blog-post in Japanese，幸运的是有 Google 翻译 :)
问题是默认的 pinentry 不能通过 ssh 远程工作（即使使用 -X 选项）。解决方案：
sudo update-alternatives --config pinentry
选择 pinentry-curses 或 pinentry-tty 选项。
现在您可以远程使用 gpg，而无需像 pinentry-mode 这样的解决方法选项。
这只是发生在我身上，解决方案取决于引起的问题。 在我的例子中，我删除了用于初始化密码数据库的密钥，因此解决方案是删除我的主目录中的 .password_store 文件夹。如果您以同样的方式导致此问题并且没有存储密码，那就去吧。