I'm using Debian-based Docker image, and I have only one usable key in the keyring:

$ gpg -K
sec>  rsa2048 2012-01-16 [C] [expires: 2024-05-15]
      Card serial no. = 00nn 00nnnnnn
uid           [ unknown] John Doe <[email protected]>
ssb#  rsa2048 2012-01-16 [S] [expires: 2024-05-14]
ssb   rsa3072 2012-01-16 [S] [expires: 2024-05-15]

As you can see here, there are three keys:

  • Primary key tagged with > resides on the smart card. It is marked as certify-only key, therefore it can't be used for signing.
  • Private part for the second secondary signing key, tagged with #, isn't present here. Therefore it can't be used for signing.
  • Third secondary signing key has a private part available. This is the only key here that can be used for signing.

Again, last key here is the only key usable for signing purposes.

Alas, for some reason GnuPG fails to see it:

$ echo test | gpg --clearsign
gpg: no default secret key: Unusable public key
gpg: [stdin]: clear-sign failed: Unusable public key

Yet has no problem signing if I specify a user ID directly:

$ echo test | gpg --clearsign --default-key [email protected]
gpg: using "[email protected]" as default secret key for signing
Hash: SHA512


The manual says it should be working out of the box:

--default-key name Use name as default user ID for signatures. If this is not used the default user ID is the first user ID found in the secret keyring.

I'm using GnuPG 2.2.19:

$ gpg --version
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5

I've applied a known Docker workaround with GPG_TTY, to no avail.

What do I do to make it work?

  • Just a guess, but the issue may be that the trust status of the key is “unknown”. Try setting the trust to “ultimate” with gpg --edit-key [email protected] and then trust.
    – tastytea
    Feb 16, 2020 at 15:32
  • @tastytea it wasn't that :(
    – sanmai
    Feb 16, 2020 at 15:52

3 Answers 3


You can put default-key [email protected] or default-key CB522FE0379DDF40A93400D7E4BC91FACDA9A65B into ~/.gnupg/gpg.conf to work around the issue.


If I'm reading this right: you have two subkeys for signing but one is offline:

ssb#  rsa2048 2012-01-16 [S] [expires: 2024-05-14]
ssb   rsa3072 2012-01-16 [S] [expires: 2024-05-15]

I would expect to see: ssb> on both, which confirms that the subkeys have been replaced by stubs. That might be why gnupg is confused.

From the same source:

The # indicates that the private key for that key is not available at all. This is the case with off-line master keys.

My setup is something like this with 3 subkeys for Signing, Encrypting and Authentication. Note that all 3 subkeys reside on a smart card:

sec#  rsa4096 2011-01-15 [C]
uid           [ unknown] xxxxxxxxxxxxx
ssb>  rsa4096 2011-01-15 [S]
ssb>  rsa4096 2011-01-15 [E]
ssb>  rsa4096 2011-01-15 [A]

I am wondering if the smart card was in the reader when you attempted the sign operation.

  • It was, and it started working as it should once I get the card removed. I have one subkey residing locally, that's why it isn't marked with > or #. And that's probably why signing still works if I remove the card. Thank you for asking.
    – sanmai
    Feb 17, 2020 at 1:12

The problem disappears if I happen to unplug the smart-card, and repeat signing operation. This was a GnuPG bug, and it appears that it is going to be fixed in the next release.

Dockerized environment has nothing to do with this.

  • It is May 2022 here and this was still the solution for me...
    – Timo Ernst
    May 30, 2022 at 15:22

You must log in to answer this question.

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