3.0 - Unable to fetch GPG key from keyserver

This happens frequently with lxc-create

Setting up the GPG keyring
ERROR: Unable to fetch GPG key from keyserver

Sometimes not at all but more than often it does and it takes some repetition of lxc-create till it goes through

Your system seems to have connectivity issue with pool.sks-keyservers.net, this is a very large pool distributed around the planet with lots of redundancy so it’s pretty unlikely to be a problem on their side.

Instead, firewalls and proxies on the client side are much more common source of problems.
Anyway, you can also override the GPG server use by using the DOWNLOAD_KEYSERVER environment variable and point it to a valid gpg keyserver to use instead of pool-sks.

There is no proxy involved and it happens even with all firewall rules flushed from the system.

I would agree concur about the connection issue. Just run a test which came out fine


gpg -vvvv --keyserver-options=debug --keyserver "hkp://pool.sks-keyservers.net" --recv-keys "0xBAEFF88C22F6E216"

gpg: keyserver option ‘debug’ is unknown
gpg: using character set ‘utf-8’
gpg: keybox ‘/root/.gnupg/pubring.kbx’ created
gpg: data source:
gpg: armour header: Version: SKS 1.1.6
gpg: armour header: Comment: Hostname: sks2.cryptokeys.org.za

off=0 ctb=99 tag=6 hlen=3 plen=525

:public key packet:
version 4, algo 1, created 1389412108, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: BAEFF88C22F6E216

off=528 ctb=b4 tag=13 hlen=2 plen=58

:user ID packet: “LXC pre-built images lxc-devel@lists.linuxcontainers.org

off=588 ctb=89 tag=2 hlen=3 plen=568

:signature packet: algo 1, keyid BAEFF88C22F6E216
version 4, created 1389412108, md5len 0, sigclass 0x13
digest algo 2, begin of digest dc d5
hashed subpkt 2 len 4 (sig created 2014-01-11)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID BAEFF88C22F6E216)
data: [4095 bits]
gpg: pub rsa4096/BAEFF88C22F6E216 2014-01-11 LXC pre-built images <lxc-devel@lists.linuxcontainers.or
gpg: writing to ‘/root/.gnupg/pubring.kbx’
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: using pgp trust model
gpg: key BAEFF88C22F6E216: public key “LXC pre-built images lxc-devel@lists.linuxcontainers.org” impoed
gpg: Total number processed: 1
gpg: imported: 1

Here https://blog.hackingcodeschool.net/error-unable-to-fetch-gpg-key-from-keyserver/ it is suggested that swapping gnupgp for gnupg2 may solve it.

Hopefully a ‘me too’ isn’t considered to be totally inappropriate!

I have been fighting this issue for about a month. First only on containers (only place I was trying to set up x2goserver) but the last week on a test system as well. (See my questions on ‘failing to connect to container using x2go’ and ‘useradd working differently between versions’.)
As I am a total noob at anything gnupg (and most other under the hood stuff) I appreciate the option that was shared here. Will try using it later to see if I can effect a connection (haven’t been able to using any of the other 3 techniques that I know of.)

Wondering if their is any chance that the issue is at the intersection point of the three technologies (rather than just being any combination other than all three)? (gnupg lxd and snapd)

Thanks for raising this issue!!

Now it even fails every time with lxc-create -t download. And it does not look like a connectivity issue

ping pool.sks-keyservers.net

PING pool.sks-keyservers.net ( 56(84) bytes of data.
64 bytes from sks-nrt.semperen.com ( icmp_seq=1 ttl=50 time=243 ms

traceroute pool.sks-keyservers.net

traceroute to pool.sks-keyservers.net (, 30 hops max, 60 byte packets
1 81.17.x.x (81.17.x.x) 0.740 ms 0.784 ms 0.778 ms
2 190.211.x.x (190.211.x.x) 0.444 ms 0.569 ms 0.599 ms
3 179.43.x.x (179.43.x.x) 3.436 ms 3.454 ms 3.650 ms
4 ( 3.738 ms 3.737 ms 3.661 ms
5 ( 16.833 ms 16.774 ms 17.179 ms
6 * * *
7 sks-ams.semperen.com ( 16.227 ms !X * *

Did you try using another keyserver?

Anyway, you can also override the GPG server use by using the DOWNLOAD_KEYSERVER environment variable and point it to a valid gpg keyserver to use instead of pool-sks.

That was in my initial response to this thread :slight_smile:

1 Like

Indeed, and I missed it… shame on me

Anyway, suppose the syntax is something like DOWNLOAD_KEYSERVER="pgp.mit.edu"?

But where to place this variable, not in the command line with lxc-create -t download is it?

DOWNLOAD_KEYSERVER="pgp.mit.edu" lxc-create -t download ...


Yup, that worked just fine.

Meantime I did some more reading on the subject and further testing and it seems that it bears down to a dns resolution issue when ipv6 is involed, and this lxc host is pure ipv4.

gpg -vvvv --keyserver-options=debug --keyserver "hkps.pool.sks-keyservers.net" --recv-keys "0xE7FB0CAEC8173D669066514CBAEFF88C22F6E216"

gpg: keyserver option ‘debug’ is unknown
gpg: using character set ‘utf-8’
gpg: keyserver receive failed: Cannot assign requested address
dirmngr[5679]: can’t connect to ‘2001:470:1:116::6’: Cannot assign requested address
dirmngr[5679]: error connecting to ‘http://[2001:470:1:116::6]:11371’: Cannot assign requested address
dirmngr[5679]: command ‘KS_GET’ failed: Cannot assign requested address

Notwithstanding mentioned at https://sks-keyservers.net/overview-of-pools.php

ipv4.pool.sks-keyservers.net if anyone for some reason (broken IPv6) should have difficulties


Otherwise you can skip GPG check with --no-validate option.

Neither changing the environment variable nor using --no-validate has any effect on Debian Buster’s lxc-create. Each run results in this error.

You just have to try again and again.

Worked like a charm for me also. Thanks!


Overriding DOWNLOAD_KEYSERVER is supported since 2.1.0. And pgp.mit.edu seems to be down, at least right now. What worked for me is:

$ lxc-create -t download -n my-container -- --keyserver keyserver.ubuntu.com

Considering that lxc also switched to the ubuntu servers, sounds like a good option.