64

This error has arise when I add gns repository and try to use this command:

#sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F88F6D313016330404F710FC9A2FD067A2E3EF7B

the error is:

gpg: keyserver receive failed: Server indicated a failure
Improve this question
1
  • as I've explained in my answer and comment to the downvotes, it's related to DNS and the way that dirmngr in version 2.1.6 did reverse DNS that have been removed in version 2.1.8 I recall, but 2.2.x I've installed from Debian testing/unstable (Debian 9 current as at writing this) also fixed this issue.
    – Hvisage
    Feb 4, 2018 at 15:52

12 Answers 12

Reset to default
84

Behind a firewall you should use the port 80 instead of the default port 11371 :

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9A2FD067A2E3EF7B

Sample output:

Executing: /tmp/apt-key-gpghome.mTGQWBR2AG/gpg.1.sh --keyserver hkp://keyserver.ubuntu.com:80 --recv 9A2FD067A2E3EF7B
gpg: key 9A2FD067A2E3EF7B: "Launchpad PPA for GNS3" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
Improve this answer
4
  • 1
    Not port 11371 or 80 related behind firewall. seems to be rather related to DNS resolution when you start to google the net... ``` Executing: /tmp/apt-key-gpghome.imkAGGXMO8/gpg.1.sh --receive-keys --debug-all -vvv --keyserver hkp://sks1.cryptokeys.org.za:80 gpg: DBG: chan_3 -> KEYSERVER --clear hkp://sks1.cryptokeys.org.za:80 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KS_GET -- 0x9C1384B1168FD423 gpg: DBG: chan_3 <- ERR 167772379 Server indicated a failure <Dirmngr>```
    – Hvisage
    Feb 1, 2018 at 15:40
  • 19
    I get the same error using dirmngr 2.2.5, and adding hkp:// and :80 resolved the issue
    – lofidevops
    Apr 11, 2018 at 15:25
  • Thanks. FInally I solved the issue by following command - sudo gpg --keyserver keyserver.ubuntu.com --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
    – Sanaulla
    Jan 31 at 5:14
  • works like a charm!
    – Alex
    Apr 16 at 2:49
20

This issue was really tough for me; none of the proposed solutions worked for me until I found this post on reddit. I just went and added this line to /etc/resolv.conf:

nameserver 8.8.8.8 # Google DNS

you can try any other DNS and see which one works for you, such as

nameserver 1.1.1.1 # Cloudflare
Improve this answer
2
  • This doesn't seem to work unless the first nameserver in the list is functional. Most DNS activity will failover to the next resolver, but this wouldn't for some reason.
    – Andrew Bobulsky
    Oct 11, 2020 at 19:19
  • 1
    nameserver 1.1.1.1 is a better option
    – pouya
    Nov 4, 2021 at 23:03
12

This problem can be caused (as I just experienced it) by an empty resolv.conf, as may be the case on a system using systemd-resolved for its primary DNS resolution via nsswitch.

I assume that it's a case of gpg not using nsswitch and the associated libc functions and instead, for some reason, reading resolv.conf itself.

Symptoms:

  • gpg: keyserver receive failed: Server indicated a failure

  • /etc/resolv.conf is empty but hostname resolution e.g. getent hosts google.com, ping google.com etc is fine. Note that dig, drill, nslookup all read resolv.conf directly, so these may not work.

  • /etc/nsswitch.conf has something like hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns in it, where resolve is a module provided by systemd (see man 8 libnss_resolve.so.2 for details).

Resolution:

You want to make a symbolic link to systemd's autogenerated resolv.conf that reflects the current resolver settings. I suggest reading man 8 systemd-resolved, section "/ETC/RESOLV.CONF" for details on what this does, exactly. Here are my recommended commands and output to make the symbolic link:

$ # you should check this has reasonable contents before using it
$ cat /run/systemd/resolve/stub-resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

$ rm /etc/resolv.conf
$ ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
Improve this answer
1
  • I'm on Ubuntu 20.04. ll /etc/resolv.conf shows that this was already a symbolic link to /run/systemd/resolve/stub-resolv.conf! Here is the output of ll /etc/resolv.conf: lrwxrwxrwx 1 root root 39 Aug 9 2020 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf. And yet, it still didn't work. So, I changed the nameserver from nameserver 127.0.0.53 to nameserver 1.1.1.1, as recommended by this answer, and now it works! Note that if you don't have ll, it is simply an alias for ls -alF, so use that instead.
    – Gabriel Staples
    Aug 1, 2022 at 0:31
8

It has to do with DNS and what your DNS server does or does return for dirmngr ;( It got introduce since 2.1.16 with dirmngr, and I've been looking for solution myself on 2.1.6 with Debian's default packages. ;(

The correct answer, is: Upgrade to version 2.2.x or later that fixed this problem first time.

Improve this answer
3
  • 4
    a temporary workaround: ping the server (ping keyserver.ubuntu.com) to get its IP number and use this number instead of keyserver.ubuntu.com in your command
    – likewise
    Nov 27, 2020 at 19:58
  • Relevant bugfix in 2.2+ dev.gnupg.org/T3374
    – isopropylcyanide
    Apr 25, 2021 at 20:56
  • @XavrasWyzryn Thank you, this comment helped me identify a server that is no longer operational, which is why I was getting the error.
    – semitones
    Apr 18, 2022 at 19:45
6

Encountered the same issue on ubuntu 18.04, running dirmngr 2.2.4. I went with the option of checking my dns settings and added my local dns server 'nameserver 1.1.1.1' and google's 'nameserver 8.8.8.8'. Then it worked.

Improve this answer
3
  • 1
    Specifying explicit DNS servers in my network config solved it for me. Gentoo, using NetworkManager.
    – Pistos
    Dec 28, 2018 at 22:55
  • Also remember Quad9 (9.9.9.9) for helping to filter out malware/etc. in a privacy-advocacy manner ;)
    – Hvisage
    Dec 31, 2018 at 10:14
  • Where add??? I just switched to dns 1.1.1.1 and am getting this issue
    – Trees4theForest
    Aug 20, 2019 at 13:06
4

Add 0x before key, so that it turns 0xF88F6D313016330404F710FC9A2FD067A2E3EF7B.

This plus GAD3R's answer solved it for me.

Improve this answer
2
  • damn, you're right! i would have never imagined that the missing 0x will not only make it fail, but also lead to such a cryptic message... thanks!
    – Attila Lendvai
    Nov 23, 2020 at 20:31
  • 2
    I think you'll find that the 0x is purely a placebo fix.
    – Orwellophile
    Oct 15, 2021 at 7:59
3

This also works to remove the DNS issue:

sudo apt-key adv --keyserver $( dig +short keyserver.ubuntu.com | head -n1 ) \
                 --recv-keys 42670A7FE4D0441C8E4632349E4FDC074A4EF02D
Improve this answer
2

Usually when you have a non default DNS configuration in your system, for example if you're using dnsmasq or another DNS service, other than systemd-resolve, it's possible that dirmngr used by gpg fails to get the resolved name for keyserver.ubuntu.com, then, you need to check your name resolution software.

In my case, I have installed dnsmasq for name resolution in a Zimbra mail server. In this case it is important that you prevent that the resolvconf software controls dnsmasq, this is editing the /etc/default/dnsmasq file and uncommenting this line: IGNORE_RESOLVCONF=yes. Then you have to restart the dnsmasq and try to resolve with the local dns server with this command:

:~$ host -v keyserver.ubuntu.com 127.0.0.1

If it is ok, you will see something like this:

Trying "keyserver.ubuntu.com"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13994
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;keyserver.ubuntu.com.      IN  A

;; ANSWER SECTION:
keyserver.ubuntu.com.   417 IN  A   162.213.33.8
keyserver.ubuntu.com.   417 IN  A   162.213.33.9

Received 70 bytes from 127.0.0.1#53 in 14 ms
Trying "keyserver.ubuntu.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;keyserver.ubuntu.com.      IN  AAAA

Received 38 bytes from 127.0.0.1#53 in 1 ms
Trying "keyserver.ubuntu.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45211
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;keyserver.ubuntu.com.      IN  MX

;; AUTHORITY SECTION:
ubuntu.com.     1748    IN  SOA ns1.canonical.com. hostmaster.canonical.com. 2018053167 10800 3600 604800 3600

Received 99 bytes from 127.0.0.1#53 in 16 ms

Even if you're not using some DNS server, try to ask to systemd-resolve if it can resolve the URL with this:

:~$ host -v keyserver.ubuntu.com 127.0.0.53

If not, let us know what you get.

Improve this answer
2

I was getting this error on when I tried to access a key.

gpg: keyserver receive failed: No dirmngr

Killing dirmngr and running the command again solved it for me, like below:

gpgconf --kill dirmngr

It is worth a try, let me know if it works.

Improve this answer
1
1

If you are living in Belarus, than you need to know that gpg issue may be cased by new buggy state firewall. Today state firewall in Belarus may block hkps using DPI for you. It is actually a bug: you can report it directly to firewall managers if you think this organization will change something.

If you want your hkps (and hkp too) back, than you have to follow complete china users firewall experience:

  1. remote openvpn server in normal country.
  2. obfs4proxy server (not required for now).
  3. stunnel server.
  4. frontend domain (azure) (not required for now).
  5. stunnel client.
  6. obfs4proxy client (not required for now).
  7. openvpn client.

See also gentoo issue.

Improve this answer
1
  • 1
    I am in Russia, and we have the same issue nowadays. (We are lagging behind by a few months only in the thickness of our firewall.) -- I had to bypass getting the keys by using the #apt-get --allow-unauthenticated, as in my answer below. All the best in surviving...
    – Maxim
    Dec 27, 2021 at 7:26
0

Sharing my 2 days of troubleshooting: Symptoms:

  • gpg: keyserver receive failed: Server indicated a failure
  • /etc/resolv.conf is using stub 127.0.0.53 but resolves hostname fine (ie. getent hosts google.com work as expected)
  • more than 1 ethernet adapter that is up

Troubleshoot:

  • open another terminal and execute journalctl -u systemd-resolved -f
  • in the first terminal do systemctl edit systemd-resolved

paste

 [Service]
 Environment=SYSTEMD_LOG_LEVEL=debug

restart

systemctl restart systemd-resolve<br/> sudo apt-key adv --keyserver
keyserver.ubuntu.com --recv-keys
F88F6D313016330404F710FC9A2FD067A2E3EF7B

check in the auxiliary terminal, the adapter it is using and the fail to be sure that this the cause, just set down the ethernet adapter and repeat the key request if, it works now, you may understand that the adapter do not have a satisfactory name server;

adding 8.8.8.8 to the netplan config of the 1st adapter will solve the problem

Improve this answer
0

I live in a totalitarian country* with thick firewall, and neither adding :80 nor editing resov.conf helped

I was forced to use #apt-get --allow-unauthenticated to bypass getting the keys...

*Russia

Improve this answer

You must log in to answer this question.

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