You are not logged in.
Whenever I setup a new arch system I have encountered difficulties with gnupg reaching key servers.
The problem typically manifests when I need to trust a new key from a PKGBUILD file.
Using an AUR helper, the problem is seen as follows:
==> PGP keys need importing:
-> 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2, required by: libcurl-openssl-1.0
==> Import? [Y/n]
:: Importing keys with gpg...
gpg: keyserver receive failed: Server indicated a failure
The arch wiki provides a number of suggestions in this case at https://wiki.archlinux.org/index.php/Pa … mport_keys I think in my case the problem falls under "dirmngr is not correctly configured".
Unfortunately, this problem is not easy to diagnose as dirmngr seems somewhat of a difficult process to monitor:
* gnupg is intend on spawning a new process and not use the dirmngr process I spawned to monitor dirmngr stdout/stderr.
* Changing the settings file for the spawned dirmngr process in ~/.gnupg/dirmngr.conf and monitoring stdout via strace also does not provide insight into where dirmngr fails.
As a result, I am unable to monitor dirmngr's output when I ask gpg to receive a key from a key server. Any suggestions on how to achieve this are welcomed.
It turns out that dirmngr cannot resolve the key server, as it cannot reach the DNS server. This is confirmed by a tcpdump (there is never a response to the query):
❯ sudo tcpdump -i any -n port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
13:20:59.525103 IP 127.0.0.1.52123 > 127.0.0.1.53: 30002+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65)
13:20:59.525125 IP 127.0.0.1.52123 > 127.0.0.1.53: 30002+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65)
Note my system is setup to use systemd-resolved, where I haven't touched /etc/resolv.conf (it's not a symlink). While this is a valid systemd-resolved setup as per the documentation of systemd-resolved (/etc/resolv.conf mode 4), in my case there is no other package handling /etc/resolve.conf and there is no DNS server configured within:
❯ ls -al /etc/resolv.conf
-rw-r--r-- 1 root root 65 Jul 3 12:34 /etc/resolv.conf
❯ cat /etc/resolv.conf
# Resolver configuration file.
# See resolv.conf(5) for details.
Providing a valid /etc/resolv.conf (symlink to systemd-resolved) fixes the resolve issue for dirmngr.
❯ sudo tcpdump -i any -n port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
13:18:32.364076 IP 127.0.0.1.51641 > 127.0.0.53.53: 30002+ [1au] SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (76)
13:18:32.364286 IP6 2a02:1812:1711:b100:4e52:62ff:febb:9f1e.46744 > 2a02:1800:100::42:2.53: 45641+ [1au] SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (76)
13:18:32.381555 IP6 2a02:1800:100::42:2.53 > 2a02:1812:1711:b100:4e52:62ff:febb:9f1e.46744: 45641 NXDomain 0/1/1 (126)
13:18:32.381713 IP 127.0.0.53.53 > 127.0.0.1.51641: 30002 NXDomain 0/0/1 (76)
13:18:32.381829 IP 127.0.0.1.42180 > 127.0.0.53.53: 20127+ [1au] A? hkps.pool.sks-keyservers.net. (57)
13:18:32.381989 IP6 2a02:1812:1711:b100:4e52:62ff:febb:9f1e.36606 > 2a02:1800:100::42:2.53: 63598+ [1au] A? hkps.pool.sks-keyservers.net. (57)
13:18:32.398873 IP6 2a02:1800:100::42:2.53 > 2a02:1812:1711:b100:4e52:62ff:febb:9f1e.36606: 63598 3/0/1 A 192.146.137.140, A 192.146.137.141, A 209.244.105.201 (105)
13:18:32.399144 IP 127.0.0.53.53 > 127.0.0.1.42180: 20127 3/0/1 A 192.146.137.140, A 192.146.137.141, A 209.244.105.201 (105)
13:18:32.399306 IP 127.0.0.1.42180 > 127.0.0.53.53: 18851+ [1au] AAAA? hkps.pool.sks-keyservers.net. (57)
13:18:32.399612 IP6 2a02:1812:1711:b100:4e52:62ff:febb:9f1e.42204 > 2a02:1800:100::42:2.53: 40504+ [1au] AAAA? hkps.pool.sks-keyservers.net. (57)
13:18:32.417653 IP6 2a02:1800:100::42:2.53 > 2a02:1812:1711:b100:4e52:62ff:febb:9f1e.42204: 40504 2/0/1 AAAA 2001:67c:26b4:ff00::141, AAAA 2001:67c:26b4:ff00::140 (113)
13:18:32.417961 IP 127.0.0.53.53 > 127.0.0.1.42180: 18851 2/0/1 AAAA 2001:67c:26b4:ff00::141, AAAA 2001:67c:26b4:ff00::140 (113)
Note dirmngr contacts 127.0.0.53 instead of 127.0.0.1, as per /etc/resolv.conf:
❯ ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 37 Jul 3 13:16 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
❯ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
# ...nameserver 127.0.0.53
options edns0
dirmngr is one of the few packages that fails with an empty /etc/resolv.conf, maybe it's using a special dns lookup method (e.g. read /etc/resolve.conf instead of using some sys call)? Anway, I'm guessing most arch users have setup /etc/resolve.conf with a valid dns server and therefore don't experience this issue. E.g. run systemd-resolved in /etc/resolve.conf mode 1 (which I will do in the future) or use a network manager that populates /etc/resolve.conf.
I am wondering though if the arch wiki entry on 'Cannot import keys' could be expanded to point the user to look at DNS issues with dirmngr. As the error "gpg: keyserver receive failed: Server indicated a failure" is not very descriptive, it may cost (un)experienced users some time to look at DNS configuration. Any thoughts on the matter?
Last edited by fvdnabee (2020-07-03 11:49:37)
Offline
Inspecting the IPC (MITM unix socket) between gpg and dirmngr does not point to a DNS failure either:
❯ socat -t100 -v UNIX-LISTEN:/run/user/1000/gnupg/S.dirmngr,mode=777,reuseaddr,fork UNIX-CONNECT:/run/user/1000/gnupg/S.dirmngr.original
< 2020/07/03 13:48:51.274726 length=109 from=0 to=108
# Home: /home/fvdnabee/.gnupg
# Config: /home/fvdnabee/.gnupg/dirmngr.conf
OK Dirmngr 2.2.20 at your service
> 2020/07/03 13:48:51.275318 length=16 from=0 to=15
GETINFO version
< 2020/07/03 13:48:51.275461 length=12 from=109 to=120
D 2.2.20
OK
> 2020/07/03 13:48:51.275630 length=53 from=16 to=68
KS_GET -- 0xD8AFDDA07A5B6EDFA7D8CCDAD6D055F927843F1C
< 2020/07/03 13:48:51.276153 length=56 from=121 to=176
ERR 219 Server indicated a failure <Unspecified source>
> 2020/07/03 13:48:51.276601 length=4 from=69 to=72
BYE
< 2020/07/03 13:48:51.276725 length=22 from=177 to=198
OK closing connection
2020/07/03 13:48:51 socat[54263] E write(6, 0x561487e60b10, 22): Broken pipe
Offline