gpg: keyserver receive failed: Server indicated a failure

learnarch · 2020-10-01 10:28:26

Hi,

I was trying to install AUR package powerdevil-light. There was an error when running makepkg:
powerdevil-5.19.5.tar.xz ... FAILED (unknown public key EC94D18F7F05997E)
==> ERROR: One or more PGP signatures could not be verified!

So I tried: gpg --recv-keys EC94D18F7F05997E
The result was:
gpg: keyserver receive failed: Server indicated a failure

I did some googling. It seems some similar issues are related to DNS. But I can access all of the following sites in Firefox (no proxy). Pinging in terminal was also successful.

pool.sks-keyservers.net
keyserver.ubuntu.com
pgp.mit.edu
keyserver.pgp.com
keys.openpgp.org
Since a query of the public key on openpgp.org was successful, I also tried the following:
gpg --keyserver keys.openpgp.org --recv EC94D18F7F05997E
gpg --keyserver hkp://keys.openpgp.org:80 --recv EC94D18F7F05997E
But the result is aloways:
gpg: keyserver receive failed: Server indicated a failure

I also did "killall dirmngr" even though I don't know if it's relevant.

Can someone please give me some guidance?

Thanks a lot

mpan · 2020-10-01 10:44:23

As a workaround, you may go to a selected keyserver in your browser, search the key there, download it manually and import from a file. For example ~~EC94D18F7F05997E on key.openpgp.org~~ EC94D18F7F05997E on keyserver.ubuntu.com.

As for debugging: look if you can find something with --debug-level=advanced, --debug-level=expert or --debug-level=guru. Each provides progressively more details.

Last edited by mpan (2020-10-01 18:06:05)

learnarch · 2020-10-01 10:56:01

mpan wrote:

As a workaround, you may go to a selected keyserver in your browser, search the key there, download it manually and import from a file. For example EC94D18F7F05997E on key.openpgp.org.
As for debugging: look if you can find something with --debug-level=advanced, --debug-level=expert or --debug-level=guru. Each provides progressively more details.

Thanks a lot for your reply. I downloaded the key and ran: gpg --import ~/Downloads/2D1D5B0588357787DE9EE225EC94D18F7F05997E.asc
The output is:
gpg: key EC94D18F7F05997E: no user ID
gpg: Total number processed: 1

Running makepkg again shows the error is still there. What is the complaint about no user ID?

Thx

learnarch · 2020-10-01 12:55:52

Googled and it seems the "no user ID" error is specific to keys downloaded from openpgp.org. Strangedly, all the other key servers return "not found" when searching the key in firefox.

I've installed the package withe the --skippgpcheck option of makepkg. I believe this should not be the solution. So I still appreciate if anyone can suggest a proper solution to the gpg error.

Thx

progandy · 2020-10-01 13:30:16

learnarch wrote:

Strangedly, all the other key servers return "not found" when searching the key in firefox.

For some reason, those keyservers are a bit dumb and you need to prepend "0x" to make the search happy.

0xEC94D18F7F05997E

solskog · 2020-10-01 14:37:12

man gpg
The keyserver hkp://keys.gnupg.net uses round robin DNS to give a different keyserver each time you use it.
$ gpg --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E

learnarch · 2020-10-02 02:28:52

progandy wrote:

learnarch wrote:
Strangedly, all the other key servers return "not found" when searching the key in firefox.
For some reason, those keyservers are a bit dumb and you need to prepend "0x" to make the search happy.
0xEC94D18F7F05997E

Perfect! Thank you so much. Now I can download the key from one of the other servers (I used the ubuntu one) and successfully import. I guess the following message when importing can be ignored because the imported key did work in makepkg:
gpg: key EC94D18F7F05997E: 33 signatures not checked due to missing keys

I'll leave my post open for a few more days to see if someone can shed some light on the root cause of the error with "gpg --recv-keys".

learnarch · 2020-10-02 02:30:40

solskog wrote:

man gpg
The keyserver hkp://keys.gnupg.net uses round robin DNS to give a different keyserver each time you use it.
$ gpg --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E

Thanks. Tried. Same error message.
$ gpg --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E
gpg: keyserver receive failed: Server indicated a failure

I wonder if the result would be different in your system.

solskog · 2020-10-02 02:58:34

learnarch wrote:

I wonder if the result would be different in your system.

$ gpg --verbose --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E
gpg: directory '/home/solskog/.gnupg' created
gpg: keybox '/home/solskog/.gnupg/pubring.kbx' created
gpg: no running Dirmngr - starting '/usr/bin/dirmngr'
gpg: waiting for the dirmngr to come up ... (5s)
gpg: connection to dirmngr established
gpg: data source: http://hkps.pool.sks-keyservers.net:11371
gpg: armor header: Version: SKS 1.1.6
gpg: armor header: Comment: Hostname: sks.pod02.fleetstreetops.com
gpg: key EC94D18F7F05997E: number of dropped non-self-signatures: 33
gpg: pub  rsa2048/EC94D18F7F05997E 2016-09-06  Jonathan Riddell <jr@jriddell.org>
gpg: /home/solskog/.gnupg/trustdb.gpg: trustdb created
gpg: using pgp trust model
gpg: key EC94D18F7F05997E: public key "Jonathan Riddell <jr@jriddell.org>" imported
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to agent established
gpg: Total number processed: 1
gpg:               imported: 1

mpan · 2020-10-02 04:51:50

learnarch wrote:

I guess the following message when importing can be ignored because the imported key did work in makepkg:
gpg: key EC94D18F7F05997E: 33 signatures not checked due to missing keys

As long as for some reason you believe, that the key with fingerprint 2D1D5B0588357787DE9EE225EC94D18F7F05997E in fact belongs to Jonathan Riddell, or this information is unimportant: the message may be ignored.

Each OpenPGP key may have signatures from other users. By signing the key they certify it belongs to the specific person. Since you do not have keys of those people in the keyring, GnuPG can’t verify the signatures and this is what you’re being warned about. Wikipedia describes the concept of the web of trust, if you want to understand it better.

learnarch · 2020-10-02 04:59:27

solskog wrote:

learnarch wrote:

I wonder if the result would be different in your system.

$ gpg --verbose --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E
gpg: directory '/home/solskog/.gnupg' created
gpg: keybox '/home/solskog/.gnupg/pubring.kbx' created
gpg: no running Dirmngr - starting '/usr/bin/dirmngr'
gpg: waiting for the dirmngr to come up ... (5s)
...
gpg:               imported: 1

Thanks a lot for showing me the correct output. I deleted my .gnupg directory and tried again. Here's the result:
me@Inspiron ~]$ gpg --verbose --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E
gpg: directory '/home/me/.gnupg' created
gpg: keybox '/home/me/.gnupg/pubring.kbx' created
gpg: keyserver receive failed: Server indicated a failure
[me@Inspiron ~]$

Pinging was not successful.
$ ping keys.gnupg.net
PING hkps.pool.sks-keyservers.net (209.244.105.201) 56(84) bytes of data.
^C
--- hkps.pool.sks-keyservers.net ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4058ms

But accessing both hkps.pool.sks-keyservers.net and keys.gnupg.net in firefox was successful.

The --verbose option does not seem to reveal at which step the error occurred. If it's about dirmngr, why there's no mention of dirmngr not running etc.? Is there a way to check if dirmngr is running "properly"?

Thx

Last edited by learnarch (2020-10-02 05:03:03)

solskog · 2020-10-02 05:36:27

These sites don't accept UDP, Pls try this:

# pacman -S mtr
$ mtr --tcp sks-keyservers.net

If you can reach this site without big packet drop (>60%), then it's all right. the next thing to check is if the dirmngr started as a daemon:

$ gpg --verbose --keyserver ...
...
$ pstree
systemd(1)-+-dbus-daemon(230,dbus)
           |-dirmngr

If it's not started try lunch it before import key.

$ gpgconf --launch dirmngr
$ gpg --verbose --keyserver ...

Last edited by solskog (2020-10-02 06:05:13)

solskog · 2020-10-02 05:39:04

[redundant post]

Last edited by solskog (2020-10-02 05:42:12)

learnarch · 2020-10-02 06:13:17

mpan wrote:

learnarch wrote:
I guess the following message when importing can be ignored because the imported key did work in makepkg:
gpg: key EC94D18F7F05997E: 33 signatures not checked due to missing keys
As long as for some reason you believe, that the key with fingerprint 2D1D5B0588357787DE9EE225EC94D18F7F05997E in fact belongs to Jonathan Riddell, or this information is unimportant: the message may be ignored.
Each OpenPGP key may have signatures from other users. By signing the key they certify it belongs to the specific person. Since you do not have keys of those people in the keyring, GnuPG can’t verify the signatures and this is what you’re being warned about. Wikipedia describes the concept of the web of trust, if you want to understand it better.

I see. Thanks a lot for the explanation.

learnarch · 2020-10-02 06:28:12

solskog wrote:

These sites don't accept UDP, Pls try this:
# pacman -S mtr
$ mtr --tcp sks-keyservers.net
If you can reach this site without big packet drop (>60%), then it's all right. the next thing to check is if the dirmngr started as a daemon:
$ gpg --verbose --keyserver ...
...
$ pstree
systemd(1)-+-dbus-daemon(230,dbus)
           |-dirmngr
If it's not started try lunch it before import key.
$ gpgconf --launch dirmngr
$ gpg --verbose --keyserver ...

Thanks a lot for your reply. I don't know how to capture the mtr output. From host 9 to 17, it seems they are the key servers. Only one of them has a drop around 50%. All the others have 0% drop. So I suppose this is ok.
pstree does not show dirmngr. After running "gpgconf --launch dirmngr", it appeared:
├─systemd─┬─(sd-pam)
│ ├─at-spi-bus-laun─┬─dbus-daemon
│ │ └─3*[{at-spi-bus-laun}]
│ ├─at-spi2-registr───2*[{at-spi2-registr}]
│ ├─dbus-daemon
│ ├─dconf-service───2*[{dconf-service}]
│ ├─dirmngr

But the error persists:
$ gpg --verbose --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E
gpg: keyserver receive failed: Server indicated a failure

This is expected, because gpg can start dirmngr when it finds "no running Dirmngr", as shown in your log. So dirmngr missing in pstree should not be the cause. It seems the error occurrs even before gpg tries to check for a running dirmngr.

Thx

Last edited by learnarch (2020-10-02 06:32:48)

solskog · 2020-10-02 07:55:06

You can trace it even further if you like:

# pacman -S strace
$ strace gpg --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E

And to capture any output from a command and read it.

$ date >/tmp/datelog
$ less /tmp/datelog

You don't have to show your output due to privicy concern.

Last edited by solskog (2020-10-02 08:16:01)

learnarch · 2020-10-02 13:21:31

solskog wrote:

You can trace it even further if you like:
# pacman -S strace
$ strace gpg --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E
And to capture any output from a command and read it.
$ date >/tmp/datelog
$ less /tmp/datelog
You don't have to show your output due to privicy concern.

Thanks a lot. I knew the basics of redirection. But mtr's output is special -it keeps overwriting existing lines on the screen. I did capture in a txt file. But opening with Kate, the file is almost a mess. I just realized using the more command in terminal is a better way for viewing the file.

The gpg problem just disappeared. I now know this is because I just changed my network configuration. The problem occurred when I wanted to install the AUR package powerdevil-light, the purpose was to completely get rid of the networkmanager package. When I first encountered the gpg error, I was already running iwd+resolved. I've been struggling to replace resolved with resolvconf. Due to an iwd bug, that wasn't successful until I found the solution in the forum today. I've switched back and forth between iwd+resolved and iwd+resolvconf to confirm that the gpg error is really caused by the network config.

Using strace, I found the following difference in the output.
iwd+resolvconf: from line 272:
stat("/run/user/1000/gnupg/S.dirmngr", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 3
stat("/run/user/1000/gnupg/S.dirmngr", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/gnupg/S.dirmngr"}, 32) = 0
read(3, "# Home: /home/me/.gnupg\n# Config"..., 1002) = 44
read(3, "Dirmngr 2.2.23 at your service\n", 999) = 31
write(3, "GETINFO version", 15) = 15
write(3, "\n", 1) = 1
read(3, "D 2.2.23\nOK", 1002) = 11
read(3, "\n", 1000) = 1
write(3, "KEYSERVER --clear hkp://keys.gnu"..., 38) = 38
write(3, "\n", 1) = 1
read(3, "OK\n", 1002) = 3
write(3, "KS_GET -- 0xEC94D18F7F05997E", 28) = 28
write(3, "\n", 1) = 1
read(3, "S SOURCE http://hkps.pool.sks-ke"..., 1002) = 51
read(3, "D -----BEGIN PGP PUBLIC KEY BLOC"..., 1002) = 1002
Obviously gpg is successfully receiving the key.

iwd+resolved: from line 272:
stat("/run/user/1000/gnupg/S.dirmngr", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 3
stat("/run/user/1000/gnupg/S.dirmngr", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/gnupg/S.dirmngr"}, 32) = 0
read(3, "# Home: /home/me/.gnupg\n# Config"..., 1002) = 75
write(3, "GETINFO version", 15) = 15
write(3, "\n", 1) = 1
read(3, "D 2.2.23\nOK\n", 1002) = 12
write(3, "KEYSERVER --clear hkp://keys.gnu"..., 38) = 38
write(3, "\n", 1) = 1
read(3, "OK\n", 1002) = 3
write(3, "KS_GET -- 0xEC94D18F7F05997E", 28) = 28
write(3, "\n", 1) = 1
read(3, "ERR 219 Server indicated a failu"..., 1002) = 56
write(2, "gpg: keyserver receive failed: S"..., 57gpg: keyserver receive failed: Server indicated a failure) = 57

Before line 272, the output were virtually identical except some hex values and the pid.

Why read(3, "# Home: /home/me/.gnupg\n# Config"..., 1002) has different results in the two different network settings? What's being read is a local directory. Why dns seems to be in play?

Thx

solskog · 2020-10-02 15:47:52

learnarch wrote:

Why dns seems to be in play?

I use plain text file /etc/resolv.conf and by deny permission to it I get this error.

# chmod a= /etc/resolv.conf
$ gpg --keyserver ...
gpg: keyserver receive failed: Permission denied

learnarch wrote:

Why read(3, "# Home: /home/me/.gnupg\n# Config"..., 1002) has different results in the two different network settings?

I think this is a database that updates each time you import a key. An unsuccessful dns request shouldn't change what was already in the database. I wish someone with right knowledge could tel us more about it.

learnarch · 2020-10-03 02:39:03

I did some more testing with iwd+resolved. I think this is a gpg bug (or feature?).

Scenario 1: /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf automatically created by systemd-resolved. gpg error message.
Scenario 2: /etc/resolv.conf is a regular file but has only one line, a comment line like "# Generated by ...". Same gpg error message.
Scenario 3: /etc/resolv.conf is a regular file and has two lines of valid "nameserver" records. gpg succeeds.

In all the above scenarios, other apps (ping, firefox, konqueror, the weather applet in system tray, KDE's Discover etc.) have no issue at all with internet access.

So I think it's obvious gpg refuses to handle name resolution in a "standard" way.

Last edited by learnarch (2020-10-04 04:04:30)

loqs · 2020-10-03 02:42:38

What if you add the option

standard-resolver

to ~/.gnupg/dirmngr.conf
Then killall dirmngr

learnarch · 2020-10-04 04:10:24

loqs wrote:

What if you add the option
standard-resolver
to ~/.gnupg/dirmngr.conf
Then killall dirmngr

I've reinstalled arch using the Oct 1 iso. Now scenario 1 always succeed. I have no idea what was wrong with my previous installation. Maybe I messed up something when wrestling with the network config. I've update my previous post accordingly.

Now the only scenario with error is scenario 2. With your suggestion, the error message changes to: gpg: keyserver receive failed: Try again later. But no matter how long I waited to try again (also rebooted), the error persists. Again, all other Internet activities are without any issue.

Thx

kulak · 2021-01-01 07:40:06

I have exactly the same problem.

Content of ~/.gnupg/dirmngr.conf:

cat ~/.gnupg/dirmngr.conf 
standard-resolver

get key:

gpg --verbose --keyserver hkp://keys.gnupg.net --recv EC94D18F7F05997E
gpg: keyserver receive failed: Try again later

journalctl -f log:

Dec 31 23:35:10 stol systemd[461]: Started GnuPG network certificate management daemon.
Dec 31 23:35:10 stol dirmngr[3590]: permanently loaded certificates: 130
Dec 31 23:35:10 stol dirmngr[3590]:     runtime cached certificates: 0
Dec 31 23:35:10 stol dirmngr[3590]:            trusted certificates: 130 (129,0,0,1)
Dec 31 23:35:10 stol dirmngr[3590]: command 'KS_GET' failed: Try again later

I know key exists: https://keyserver.ubuntu.com/pks/lookup … 8F7F05997E

kulak · 2021-01-01 07:50:11

Post #19 gave me some clues. Options that did not work:

1. Started without dirmngr.conf file. Fails.
2. Added keyserver to dirmngr.conf file. Fails.
3. Static IP in /etc/hosts for server listed in the dirmngr.conf file. It proceeds further, but still fails.
4. standard-resolver in dirmngr.conf file with /etc/hosts cleaned up. Fails and reported in post #21.
5. Originally my /etc/resolve.conf had no records. I added 2:

nameserver 8.8.8.8
nameserver 8.8.4.4

It started to work.

I wish there was a solution that does not require editing of resolve.conf file.

finoderi · 2021-01-01 12:08:43

kulak wrote:

I wish there was a solution that does not require editing of resolve.conf file.

The file is called resolv.conf and it's actually your responsibility to properly configure DNS resolution on your system: https://wiki.archlinux.org/index.php/Do … resolution

kulak · 2021-01-01 16:50:45

finoderi wrote:

kulak wrote:
I wish there was a solution that does not require editing of resolve.conf file.
The file is called resolv.conf and it's actually your responsibility to properly configure DNS resolution on your system: https://wiki.archlinux.org/index.php/Do … resolution

Every other app has no problem with DNS resolution with empty `/etc/resolve.conf`, because I followed instructions to configure DHCP with [systemd-networkd](https://wiki.archlinux.org/index.php/Systemd-networkd).

Post #19 is correct. PGP is doing its own thing and is failing.

Arch Linux

#1 2020-10-01 10:28:26

gpg: keyserver receive failed: Server indicated a failure

#2 2020-10-01 10:44:23

Re: gpg: keyserver receive failed: Server indicated a failure

#3 2020-10-01 10:56:01

Re: gpg: keyserver receive failed: Server indicated a failure

#4 2020-10-01 12:55:52

Re: gpg: keyserver receive failed: Server indicated a failure

#5 2020-10-01 13:30:16

Re: gpg: keyserver receive failed: Server indicated a failure

#6 2020-10-01 14:37:12

Re: gpg: keyserver receive failed: Server indicated a failure

#7 2020-10-02 02:28:52

Re: gpg: keyserver receive failed: Server indicated a failure

#8 2020-10-02 02:30:40

Re: gpg: keyserver receive failed: Server indicated a failure

#9 2020-10-02 02:58:34

Re: gpg: keyserver receive failed: Server indicated a failure

#10 2020-10-02 04:51:50

Re: gpg: keyserver receive failed: Server indicated a failure

#11 2020-10-02 04:59:27

Re: gpg: keyserver receive failed: Server indicated a failure

#12 2020-10-02 05:36:27

Re: gpg: keyserver receive failed: Server indicated a failure

#13 2020-10-02 05:39:04

Re: gpg: keyserver receive failed: Server indicated a failure

#14 2020-10-02 06:13:17

Re: gpg: keyserver receive failed: Server indicated a failure

#15 2020-10-02 06:28:12

Re: gpg: keyserver receive failed: Server indicated a failure

#16 2020-10-02 07:55:06

Re: gpg: keyserver receive failed: Server indicated a failure

#17 2020-10-02 13:21:31

Re: gpg: keyserver receive failed: Server indicated a failure

#18 2020-10-02 15:47:52

Re: gpg: keyserver receive failed: Server indicated a failure

#19 2020-10-03 02:39:03

Re: gpg: keyserver receive failed: Server indicated a failure

#20 2020-10-03 02:42:38

Re: gpg: keyserver receive failed: Server indicated a failure

#21 2020-10-04 04:10:24

Re: gpg: keyserver receive failed: Server indicated a failure

#22 2021-01-01 07:40:06

Re: gpg: keyserver receive failed: Server indicated a failure

#23 2021-01-01 07:50:11

Re: gpg: keyserver receive failed: Server indicated a failure

#24 2021-01-01 12:08:43

Re: gpg: keyserver receive failed: Server indicated a failure

#25 2021-01-01 16:50:45

Re: gpg: keyserver receive failed: Server indicated a failure

Board footer