【问题标题】:GnuPG2.1 is using the wrong signing subkeyGnuPG2.1 使用了错误的签名子密钥
【发布时间】:2017-02-13 02:57:51
【问题描述】:

所以我在使用 gpg2.1 签署文档时遇到问题。每次我尝试签名时,我都会得到:

λ dixonwille [~] → gpg2 --detach-sign Images/EinsteinWP.jpg 
gpg: using "0xEC933DA229123788" as default secret key for signing
gpg: signing failed: No secret key
gpg: signing failed: No secret key

正如上面的消息所指出的,我的配置中确实设置了一个默认键。这是我的私人列表显示的内容:

λ dixonwille [~] → gpg2 -K --with-keygrip
/home/dixonwille/.gnupg/pubring.kbx
-----------------------------------
sec#  rsa4096/0x496AC5165C585343 2017-01-14 [SC]
      Key fingerprint = 2092 7961 2A0C EF20 83D0  8244 496A C516 5C58 5343
      Keygrip = 308FF7DD37FB9E175378D76125FCB2BC4C5C225C
uid                   [ultimate] William E. Dixon <dixonwille@gmail.com>
uid                   [ultimate] William E. Dixon <dixonwille@hotmail.com>
uid                   [ultimate] William E. Dixon <will.dixon@acstechnologies.com>
uid                   [ultimate] [jpeg image of size 5910]
ssb   rsa4096/0xD3522B485A800AFD 2017-01-14 [E] [expires: 2018-01-14]
      Keygrip = 178AB20F816E5FAA31440968AD6EA06B0340FB90
ssb   rsa4096/0xEC933DA229123788 2017-01-14 [S] [expires: 2018-01-14]
      Keygrip = 89A90662E5908D5F271B87A5DC6D26F01B53C9EC
ssb   rsa4096/0xBAA693EC561AD6D9 2017-01-14 [A] [expires: 2018-01-14]
      Keygrip = 9D48688AF67C407BB91900BA07725CCE7E08B546
ssb   rsa4096/0x7A3D17611B1FFDD2 2017-01-14 [S] [expires: 2018-01-14]
      Keygrip = 50EE902E41E323600B02769FA2A96FE8C51D5A35
ssb   rsa4096/0xB64824658CE421C8 2017-01-14 [A] [expires: 2018-01-14]
      Keygrip = D3BD87D77B844A5AE54CEC0466353030A816441B
ssb   rsa4096/0x7642000294227858 2017-01-16 [S] [expires: 2018-01-14]
      Keygrip = B10269A98E3D357F3B32C155367B1CEDCAE998E8
ssb   rsa4096/0x32C4DD59E753B43B 2017-01-16 [A] [expires: 2018-01-14]
      Keygrip = 40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264

现在所有这些密钥都没有私有密钥。其中只有三个(0xD3522B485A800AFD、0xEC933DA229123788、0xBAA693EC561AD6D9)。为了确保我运行了gpg-connect-agent,然后运行了keyinfo --list

λ dixonwille [~] → gpg-connect-agent 
> keyinfo --list
S KEYINFO 178AB20F816E5FAA31440968AD6EA06B0340FB90 D - - - P - - -
S KEYINFO 89A90662E5908D5F271B87A5DC6D26F01B53C9EC D - - - P - - -
S KEYINFO 9D48688AF67C407BB91900BA07725CCE7E08B546 D - - - P - - -
OK
> 

如您所见,我的秘密存储在 gpg-agent 中。运行echo foo | gpg --clearsign -v --debug ipc 以获取调试信息显示了这些有趣的行:

gpg: DBG: chan_5 -> HAVEKEY 308FF7DD37FB9E175378D76125FCB2BC4C5C225C
gpg: DBG: chan_5 <- ERR 67108881 No secret key <GPG Agent>
gpg: DBG: chan_5 -> HAVEKEY 89A90662E5908D5F271B87A5DC6D26F01B53C9EC
gpg: DBG: chan_5 <- OK
gpg: using "0xEC933DA229123788" as default secret key for signing
gpg: DBG: chan_5 -> HAVEKEY 308FF7DD37FB9E175378D76125FCB2BC4C5C225C 178AB20F816E5FAA31440968AD6EA06B0340FB90 89A90662E5908D5F271B87A5DC6D26F01B53C9EC 9D48688AF67C407BB91900BA07725CCE7E08B546 50EE902E41E323600B02769FA2A96FE8C51D5A35 D3BD87D77B844A5AE54CEC0466353030A816441B B10269A98E3D357F3B32C155367B1CEDCAE998E8 40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264
gpg: DBG: chan_5 <- OK
gpg: using subkey 0x7642000294227858 instead of primary key 0x496AC5165C585343
gpg: writing to stdout
gpg: DBG: chan_5 -> KEYINFO B10269A98E3D357F3B32C155367B1CEDCAE998E8
gpg: DBG: chan_5 <- ERR 67108891 Not found <GPG Agent>

这让我很困惑。它首先检查我的主主密钥的秘密,它找不到它所以失败了。然后它检查我的默认键的键柄,然后声明using "0xEC933DA229123788" as default secret key for signing。听起来不错,请做。但随后它会发送另一个HAVEKEY 来处理我所有的按键。这将返回 true,因为其中一个确实有秘密。所以它然后声明using subkey 0x7642000294227858 instead of primary key 0x496AC5165C585343 这是我所做的最新签名密钥。

如何强制 GnuPG2.1 使用我在默认密钥中指定的密钥?似乎它被 GnuPG2.1 的感觉所覆盖。

为了揭穿 pinentry 的答案,我知道如果我现在不提,可能有人会提。如果我运行ssh git@github.com,我会弹出一个对话框来输入我的密钥密码(我使用身份验证密钥作为我的 ssh 密钥并存储在 gpg-agent 中)。所以我知道我的 gpg-agent.conf 设置正确并且 gpg.conf 设置正确。

【问题讨论】:

  • 你解决过这个问题吗?我也遇到了同样的问题。
  • 是的,mutt 和 gpgme 也有同样的问题...
  • 还没解决...

标签: gnupg


【解决方案1】:

在 '.gnupg/gpg.conf' 中使用以下内容:

default-key 0xEC933DA229123788!

注意“!”在末尾。从 gpg 手册页:

“使用 gpg 时,可能会附加感叹号 (!) 以强制使用指定的主键或辅助键,而不是尝试计算要使用的主键或辅助键。”

【讨论】:

  • 这就是我在默认配置中的设置方式。对不起,应该特别说明。我确实理解 (!) 的作用。我认为这与创建时生成密钥的顺序有关。
猜你喜欢
  • 2019-07-09
  • 1970-01-01
  • 1970-01-01
  • 2016-01-03
  • 2021-04-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-01-17
相关资源
最近更新 更多