gpg: keyserver receive failed: Server indicated a failure

solonovamax · 2025-03-07 20:18:05

I'm completely unsure what's causing this, however if I attempt to execute

gpg --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001

then I will get

gpg: keyserver receive failed: Server indicated a failure

this only occurs on my laptop. on my desktop, which has an identical config to my laptop, this does not occur. I have no clue why.
I've tried so many different things, and am honestly completely dumbfounded on why it's not working.

Here are some things I've tried/stuff about my environment, in no particular order:

gpg config

$ cat ~/.gnupg/gpg.conf
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
cert-digest-algo SHA512

(note: the same issue occurs with all of these removed. I have only added these to my config in an attempt to exactly mirror the config of my desktop)

using different protocols/keyservers

$ gpg --keyserver https://keyserver.ubuntu.com --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

$ gpg --keyserver https://pgp.mit.edu --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

$ gpg --keyserver hkp://pgp.mit.edu --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

$ gpg --keyserver $(dig +short keyserver.ubuntu.com | head -n1) --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: No keyserver available

max debug level logs

$ cat > ~/.gnupg/dirmngr.conf <<EOF
log-file /home/solonovamax/.gnupg/dirmngr.log
verbose
debug-level guru
EOF
$ pkill dirmngr
$ gpg --debug-level=guru --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: enabled compatibility flags:
gpg: DBG: [no clock] start
gpg: DBG: chan_3 <- # Home: /home/solonovamax/.gnupg
gpg: DBG: chan_3 <- # Config: /home/solonovamax/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.4.7 at your service, process 12808
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.4.7
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0xB420FD3777CCE3A7F0076B55C85668DF69375001
gpg: DBG: chan_3 <- ERR 219 Server indicated a failure <Unspecified source>
gpg: keyserver receive failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: DBG: [no clock] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0
gpg: objcache: uids=0/0/0 chains=0,0..0 buckets=0/0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
$ cat ~/.gnupg/dirmngr.log
2025-03-07 14:26:32 dirmngr[21123.0] permanently loaded certificates: 150
2025-03-07 14:26:32 dirmngr[21123.0]     runtime cached certificates: 0
2025-03-07 14:26:32 dirmngr[21123.0]            trusted certificates: 150 (150,0,0,0)
2025-03-07 14:26:32 dirmngr[21123.6] handler for fd 6 started
2025-03-07 14:26:32 dirmngr[21123.6] DBG: chan_6 -> # Home: /home/solonovamax/.gnupg
2025-03-07 14:26:32 dirmngr[21123.6] DBG: chan_6 -> # Config: /home/solonovamax/.gnupg/dirmngr.conf
2025-03-07 14:26:32 dirmngr[21123.6] DBG: chan_6 -> OK Dirmngr 2.4.7 at your service, process 21123
2025-03-07 14:26:32 dirmngr[21123.6] connection from process 21122 (1000:1000)
2025-03-07 14:26:32 dirmngr[21123.6] DBG: chan_6 <- GETINFO version
2025-03-07 14:26:32 dirmngr[21123.6] DBG: chan_6 -> D 2.4.7
2025-03-07 14:26:32 dirmngr[21123.6] DBG: chan_6 -> OK
2025-03-07 14:26:32 dirmngr[21123.6] DBG: chan_6 <- KS_GET -- 0xB420FD3777CCE3A7F0076B55C85668DF69375001
2025-03-07 14:26:42 dirmngr[21123.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
2025-03-07 14:26:42 dirmngr[21123.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
2025-03-07 14:26:42 dirmngr[21123.6] DBG: chan_6 <- BYE
2025-03-07 14:26:42 dirmngr[21123.6] DBG: chan_6 -> OK closing connection
2025-03-07 14:26:42 dirmngr[21123.6] handler for fd 6 terminated

using the 1.1.1.1 dns

Changing /etc/resolv.conf from

# Generated by NetworkManager
search lan
nameserver 192.168.86.1

to

# Generated by NetworkManager
search lan
nameserver 1.1.1.1

Checking to make sure that it can resolve keyserver.ubuntu.com (note: the result is the same regardless of dns server used)

$ ping keyserver.ubuntu.com
PING keyserver.ubuntu.com (185.125.188.26) 56(84) bytes of data.

(note: keyserver.ubuntu.com does not respond to pings, but as shown it can resolve properly)

$ nslookup keyserver.ubuntu.com
Server:		192.168.86.1
Address:	192.168.86.1#53

Non-authoritative answer:
Name:	keyserver.ubuntu.com
Address: 185.125.188.27
Name:	keyserver.ubuntu.com
Address: 185.125.188.26
Name:	keyserver.ubuntu.com
Address: 2620:2d:4000:1007::70c
Name:	keyserver.ubuntu.com
Address: 2620:2d:4000:1007::d43

mtr

$ mtr --tcp --report -c 10 keyserver.ubuntu.com
Start: 2025-03-07T14:41:29-0500
HOST: solo-laptop                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 46dd6c48c6fc81fab0cb98d86  0.0%    10    2.2   5.9   2.2  26.3   7.3
  2.|-- 192.168.2.1                0.0%    10    2.7  24.4   2.7 107.2  41.4
  3.|-- 10.11.16.9                 0.0%    10   56.0  16.1   4.1  56.0  18.2
  4.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 10.115.51.122              0.0%    10  118.7  27.4   5.1 118.7  42.6
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 64.230.38.186              0.0%    10    7.0   8.1   5.5  15.5   2.8
        64.230.38.188
        64.230.38.184
  8.|-- 64.230.26.133              0.0%    10  108.1  25.3   6.4 108.1  38.3
        64.230.33.141
        64.230.33.142
  9.|-- port-channel3.switch1.ymq 30.0%    10  4109. 3103.   7.4 5255. 1703.7
 10.|-- as6939.core1.nyc4.he.net   0.0%    10  3090. 637.0  12.7 3090. 990.7
 11.|-- port-channel20.core3.lon2 20.0%    10  4209. 1383.  83.4 4209. 1524.6
 12.|-- 100ge0-35.core1.lon6.he.n  0.0%    10  106.7  96.3  81.5 198.6  36.8
 13.|-- swp9.il3-core1.canonical.  0.0%    10  155.6 107.6  79.8 167.8  34.9
        swp9.il3-core2.canonical.com
 14.|-- keyserver.ubuntu.com       0.0%    10  120.2 122.9  79.4 245.2  66.2

using systemd-resolved's dns

$ sudo rm -rf /etc/resolv.conf
$ sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# 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
search lan
$ sudo systemd-resolve --flush-caches
$ gpg --keyserver https://keyserver.ubuntu.com --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

at the same time, I had also done

$ sudo systemctl edit systemd-resolved

and added

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

and then watched the log with

$ sudo systemctl restart systemd-resolve
$ journalctl -u systemd-resolved -f

and see absolutely nothing in the logs.
however, if I instead do

$ sudo systemd-resolve --flush-caches
$ gpg --keyserver $(dig +short keyserver.ubuntu.com | head -n1) --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: No keyserver available

then the following shows up in the logs:

Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Received dns UDP packet of size 61, ifindex=0, ttl=64, fragsize=0, sender=127.0.0.1, destination=127.0.0.53
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Got DNS stub UDP query packet for id 2486
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Looking up RR for keyserver.ubuntu.com IN A.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Cache miss for keyserver.ubuntu.com IN A
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Firing regular transaction 28695 for <keyserver.ubuntu.com IN A> scope dns on */* (validate=yes).
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Using feature level UDP+EDNS0 for transaction 28695.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Using DNS server 45.90.28.0#solo-laptop-a6b773.dns.nextdns.io for transaction 28695.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Announcing packet size 1472 in egress EDNS(0) packet.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Emitting UDP, link MTU is 1500, socket MTU is 1500, minimal MTU is 40
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Sending query packet with id 28695 of size 49.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Cache miss for keyserver.ubuntu.com IN A
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Firing regular transaction 42433 for <keyserver.ubuntu.com IN A> scope dns on wlo1/* (validate=yes).
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Using feature level UDP+EDNS0 for transaction 42433.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Using DNS server 192.168.86.1 for transaction 42433.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Announcing packet size 1472 in egress EDNS(0) packet.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Emitting UDP, link MTU is 1500, socket MTU is 0, minimal MTU is 40
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Sending query packet with id 42433 of size 49.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Processing query...
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Received dns UDP packet of size 81, ifindex=3, ttl=0, fragsize=0, sender=192.168.86.1, destination=192.168.86.239
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Processing incoming packet of size 81 on transaction 42433 (rcode=SUCCESS).
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 569s on wlo1/INET/192.168.86.1
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 569s on wlo1/INET/192.168.86.1
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Regular transaction 42433 for <keyserver.ubuntu.com IN A> on scope dns on wlo1/* now complete with <success> from network (unsigned; non-confidential).
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Sending response packet with id 2486 on interface 1/AF_INET of size 81.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Freeing transaction 42433.
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Received dns UDP packet of size 81, ifindex=3, ttl=0, fragsize=0, sender=45.90.28.0, destination=192.168.86.239
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Processing incoming packet of size 81 on transaction 28695 (rcode=SUCCESS).
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 600s on wlo1/INET/45.90.28.0
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 600s on wlo1/INET/45.90.28.0
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Regular transaction 28695 for <keyserver.ubuntu.com IN A> on scope dns on */* now complete with <success> from network (unsigned; non-confidential).
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Freeing transaction 28695.

so it seems like for some reason, it's not using my system dns??? and possibly it might just have a broken network configuration somehow??

if I add

standard-resolver

to ~/.gnupg/dirmngr.conf and then execute

$ sudo systemd-resolve --flush-caches
$ gpg --debug-level=guru --keyserver https://keyserver.ubuntu.com --recv B420FD3777CCE3A7F0076B55C85668DF69375001

I see

Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink: New incoming connection.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink: Connections of user 1000: 0 (of 576 max)
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Setting state idle-server
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Received message: {"method":"io.systemd.Resolve.ResolveHostname","parameters":{"name":"keyserver.ubuntu.com","flags":0}}
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Changing state idle-server → processing-method
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: idn2_lookup_u8: keyserver.ubuntu.com → keyserver.ubuntu.com
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Looking up RR for keyserver.ubuntu.com IN A.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Looking up RR for keyserver.ubuntu.com IN AAAA.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Cache miss for keyserver.ubuntu.com IN A
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Firing regular transaction 4613 for <keyserver.ubuntu.com IN A> scope dns on */* (validate=yes).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using feature level UDP+EDNS0 for transaction 4613.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using DNS server 45.90.28.0#solo-laptop-a6b773.dns.nextdns.io for transaction 4613.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Announcing packet size 1472 in egress EDNS(0) packet.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Emitting UDP, link MTU is 1500, socket MTU is 1500, minimal MTU is 40
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Sending query packet with id 4613 of size 49.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Cache miss for keyserver.ubuntu.com IN AAAA
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Firing regular transaction 6170 for <keyserver.ubuntu.com IN AAAA> scope dns on */* (validate=yes).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using feature level UDP+EDNS0 for transaction 6170.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using DNS server 45.90.28.0#solo-laptop-a6b773.dns.nextdns.io for transaction 6170.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Announcing packet size 1472 in egress EDNS(0) packet.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Emitting UDP, link MTU is 1500, socket MTU is 1500, minimal MTU is 40
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Sending query packet with id 6170 of size 49.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Cache miss for keyserver.ubuntu.com IN AAAA
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Firing regular transaction 54496 for <keyserver.ubuntu.com IN AAAA> scope dns on wlo1/* (validate=yes).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using feature level UDP+EDNS0 for transaction 54496.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using DNS server 192.168.86.1 for transaction 54496.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Announcing packet size 1472 in egress EDNS(0) packet.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Emitting UDP, link MTU is 1500, socket MTU is 0, minimal MTU is 40
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Sending query packet with id 54496 of size 49.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Cache miss for keyserver.ubuntu.com IN A
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Firing regular transaction 22399 for <keyserver.ubuntu.com IN A> scope dns on wlo1/* (validate=yes).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using feature level UDP+EDNS0 for transaction 22399.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Using DNS server 192.168.86.1 for transaction 22399.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Announcing packet size 1472 in egress EDNS(0) packet.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Emitting UDP, link MTU is 1500, socket MTU is 0, minimal MTU is 40
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Sending query packet with id 22399 of size 49.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Changing state processing-method → pending-method
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Received dns UDP packet of size 81, ifindex=3, ttl=0, fragsize=0, sender=192.168.86.1, destination=192.168.86.239
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Processing incoming packet of size 81 on transaction 22399 (rcode=SUCCESS).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 40s on wlo1/INET/192.168.86.1
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 40s on wlo1/INET/192.168.86.1
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Regular transaction 22399 for <keyserver.ubuntu.com IN A> on scope dns on wlo1/* now complete with <success> from network (unsigned; non-confidential).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Received dns UDP packet of size 105, ifindex=3, ttl=0, fragsize=0, sender=192.168.86.1, destination=192.168.86.239
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Processing incoming packet of size 105 on transaction 54496 (rcode=SUCCESS).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN AAAA 567s on wlo1/INET/192.168.86.1
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN AAAA 567s on wlo1/INET/192.168.86.1
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Regular transaction 54496 for <keyserver.ubuntu.com IN AAAA> on scope dns on wlo1/* now complete with <success> from network (unsigned; non-confidential).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Freeing transaction 22399.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Sending message: {"parameters":{"addresses":[{"ifindex":3,"family":10,"address":[38,32,0,45,64,0,16,7,0,0,0,0,0,0,7,12]},{"ifindex":3,"family":10,"address":[38,32,0,45,64,0,16,7,0,0,0,0,0,0,13,67]},{"ifindex":3,"family":2,"address":[185,125,188,27]},{"ifindex":3,"family":2,"address":[185,125,188,26]}],"name":"keyserver.ubuntu.com","flags":8388609}}
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Changing state pending-method → idle-server
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Freeing transaction 54496.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Got POLLHUP from socket.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Changing state idle-server → pending-disconnect
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Changing state pending-disconnect → processing-disconnect
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: varlink-28-28: Changing state processing-disconnect → disconnected
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Received dns UDP packet of size 105, ifindex=3, ttl=0, fragsize=0, sender=45.90.28.0, destination=192.168.86.239
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Processing incoming packet of size 105 on transaction 6170 (rcode=SUCCESS).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN AAAA 293s on wlo1/INET/45.90.28.0
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN AAAA 293s on wlo1/INET/45.90.28.0
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Regular transaction 6170 for <keyserver.ubuntu.com IN AAAA> on scope dns on */* now complete with <success> from network (unsigned; non-confidential).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Freeing transaction 6170.
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Received dns UDP packet of size 81, ifindex=3, ttl=0, fragsize=0, sender=45.90.28.0, destination=192.168.86.239
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Processing incoming packet of size 81 on transaction 4613 (rcode=SUCCESS).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 600s on wlo1/INET/45.90.28.0
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Added positive unauthenticated non-confidential cache entry for keyserver.ubuntu.com IN A 600s on wlo1/INET/45.90.28.0
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Regular transaction 4613 for <keyserver.ubuntu.com IN A> on scope dns on */* now complete with <success> from network (unsigned; non-confidential).
Mar 07 15:09:28 solo-laptop systemd-resolved[12376]: Freeing transaction 4613.

in the systemd-resolved logs, however the gpg command hangs at

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: enabled compatibility flags:
gpg: DBG: [no clock] start
gpg: DBG: chan_3 <- # Home: /home/solonovamax/.gnupg
gpg: DBG: chan_3 <- # Config: /home/solonovamax/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.4.7 at your service, process 28929
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.4.7
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear https://keyserver.ubuntu.com
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- B420FD3777CCE3A7F0076B55C85668DF69375001

forever (from what I can tell), and dirmngr needs to be killed with

pkill -9 dirmngr

or else it just won't exit.

if there's any more info that is needed, please let me know.

-thc · 2025-03-08 07:31:31

Burrowed in the systemd-resolved logs are hints that the DNS resolution is done via

Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Using DNS server 45.90.28.0#solo-laptop-a6b773.dns.nextdns.io for transaction 28695.

and "nextdns.io" is advertising itself as "NextDNS - The new firewall for the modern Internet".

Is this configuration intended and the same for the other PCs on which gpg works?

solonovamax · 2025-03-09 03:44:41

-thc wrote:

Burrowed in the systemd-resolved logs are hints that the DNS resolution is done via
Mar 07 14:58:40 solo-laptop systemd-resolved[12376]: Using DNS server 45.90.28.0#solo-laptop-a6b773.dns.nextdns.io for transaction 28695.
and "nextdns.io" is advertising itself as "NextDNS - The new firewall for the modern Internet".
Is this configuration intended and the same for the other PCs on which gpg works?

I believe it is the case, however even if it isn't I don't think dns is the issue because

when using 1.1.1.1 as my dns, it still did not work
when contacting the ip address directly, it still did not work
I was able to resolve the ip address for the domain name

further, in my nextdns configuration, I have all firewall features disabled. they also offer web3 features as well (yuck), which I have also disabled. I just checked, and the only feature I have enabled is to "allow affiliate & tracking links", aka to not block those.

I can test later if changing it to instead use 1.1.1.1 would allow it through, however I doubt this will have any effect.

Last edited by solonovamax (2025-03-09 03:49:54)

-thc · 2025-03-09 08:27:49

O.K.

Just a couple of things you can try:

- Temporarily remove your dirmgr.conf
- prepend a "0x" to the key number ("0xB420FD3777CCE3A7F0076B55C85668DF6937500")
- use the IP address "185.125.188.26" instead of "keyserver.ubuntu.com".

seth · 2025-03-09 08:49:55

I would primarily test w/o nextdns altogether, primarily because of the fw.
And/also check netfilter/iptables …errr… tables.

solonovamax · 2025-03-12 22:46:49

sorry, this took me a hot minute to get to.
I'd previously tried looking to see if iptables or anything was disrupting it, but forgot to include it in the original post.

Note: after each test, I returned the environment to what it was previously (and also made sure to restart dirmngr where appropriate)

Remove dirmngr.conf

$ mv dirmngr.conf dirmngr.conf.bak
renamed 'dirmngr.conf' -> 'dirmngr.conf.bak'
$ pkill dirmngr
$ gpg --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

Prepend 0x to key id

$ gpg --recv-keys 0xB420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

Use the ip address directly

Technically I already did this before with the "dig +short keyserver.ubuntu.com | head -n1" command, but I'll do it again with the ip address directly

$ gpg --keyserver 185.125.188.26 --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: No keyserver available

Without nextdns

I edited /etc/systemd/resolved.conf and replaced

DNS=45.90.28.0#[...].dns.nextdns.io
DNS=2a07:a8c0::#[...].dns.nextdns.io
DNS=45.90.30.0#[...].dns.nextdns.io
DNS=2a07:a8c1::#[...].dns.nextdns.io

with

DNS=1.1.1.1#cloudflare-dns.com
DNS=2606:4700:4700::1111#cloudflare-dns.com

$ sudo nano /etc/systemd/resolved.conf
$ sudo systemctl restart systemd-resolved.service
$ sudo rm -rf /etc/resolv.conf
$ sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
$ gpg --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

iptables

I believe that if there's any firewall rules, they should be listed here:

$ sudo iptables -n -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  0    --  0.0.0.0/0            0.0.0.0/0
DOCKER-FORWARD  0    --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination
DROP       0    --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination
DOCKER     0    --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-CT (1 references)
target     prot opt source               destination
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination
DOCKER-CT  0    --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-1  0    --  0.0.0.0/0            0.0.0.0/0
DOCKER-BRIDGE  0    --  0.0.0.0/0            0.0.0.0/0
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  0    --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination
DROP       0    --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     0    --  0.0.0.0/0            0.0.0.0/0

Also, I believe that all the different *tables services (and other firewall services) are disabled:

$ systemctl status iptables.service
○ iptables.service - IPv4 Packet Filtering Framework
     Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; preset: disabled)
     Active: inactive (dead)
$ systemctl status ip6tables.service
○ ip6tables.service - IPv6 Packet Filtering Framework
     Loaded: loaded (/usr/lib/systemd/system/ip6tables.service; disabled; preset: disabled)
     Active: inactive (dead)
$ systemctl status nftables.service
○ nftables.service - Netfilter Tables
     Loaded: loaded (/usr/lib/systemd/system/nftables.service; disabled; preset: disabled)
     Active: inactive (dead)
       Docs: man:nft(8)
$ systemctl status ufw
○ ufw.service - CLI Netfilter Manager
     Loaded: loaded (/usr/lib/systemd/system/ufw.service; disabled; preset: disabled)
     Active: inactive (dead)

(is there maybe some better way to test if there is smth else I forgot about, like via an nmap scan or smth?)

seth · 2025-03-12 23:18:57

gpg --keyserver 185.125.188.26 --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: No keyserver available

nmap -p 80,443,11371 185.125.188.26
ip r get 185.125.188.26

solonovamax · 2025-03-16 18:00:13

seth wrote:

nmap -p 80,443,11371 185.125.188.26
ip r get 185.125.188.26

sorry for the long response again, I didn't see the email for this and then forgored about it. Here's the output of those commands:

$ nmap -p 80,443,11371 185.125.188.26
Starting Nmap 7.95 ( https://nmap.org ) at 2025-03-16 13:47 EDT
Nmap scan report for keyserver.ubuntu.com (185.125.188.26)
Host is up (0.082s latency).

PORT      STATE SERVICE
80/tcp    open  http
443/tcp   open  https
11371/tcp open  pksd

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds
$ ip r get 185.125.188.26
185.125.188.26 via 192.168.86.1 dev wlo1 src 192.168.86.239 uid 1000
    cache

it definitely doesn't seem to be an issue with port blocking, as nmap is able to see it.
this issue seems to be somehow isolated entirely to gnupg tools (since dirmngr belongs to gnupg), but I have absolutely no clue why??

also I forgot to mention it in the original post, but on both my desktop and my laptop

the /etc/gnupg directory does not exist which, afaik, is the global config
the $GNUPGHOME environment variable is unset (if this exist, then gnupg tools will look here for configuration, otherwise they look in ~/.gnupg
~/.gnupg/common.conf does not exist, which is a config file shared between all tools

so I don't think this is caused by some funny configuration?

this is completely baffling me as to what the issue is...

also also, I forgot to mention this as well, but this happens with (from what I can tell) all keys. not just this specific one.

Last edited by solonovamax (2025-03-16 18:02:40)

seth · 2025-03-16 20:38:33

Try adding "--keyserver-options timeout=100" to see whether it's just "you're too slow"…
Also are you behind/do you configure a proxy?

printenv | grep -i proxy

And what do you get for "gpg --refresh-keys"?
Did you play around w/ TOR?

solonovamax · 2025-03-18 15:29:30

seth wrote:

Try adding "--keyserver-options timeout=100" to see whether it's just "you're too slow"…

as-per the gpg configuration options page, that option is deprecated and now does nothing (as of gnupg 2.1).

instead, I've added the following to my ~/.gnupg/dirmngr.conf (options found on the dirmngr options page):

resolver-timeout 100
connect-timeout 100
connect-quick-timeout 100

the result is:

$ gpg --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

this command takes 10 seconds to execute, exactly the same as before.

seth wrote:

Also are you behind/do you configure a proxy?

nope, no proxy.

seth wrote:

printenv | grep -i proxy

outputs nothing.

seth wrote:

And what do you get for "gpg --refresh-keys"?

took an a while to complete. (according to the logs, 3 minutes and 30 seconds. unsure why it took that specific amount of time. if it took 10 seconds per key, then for 30 keys that would have been exactly 5 minutes, so I'm not sure why it ended up taking this long. who knows.)

$ gpg --refresh-keys
gpg: refreshing 30 keys from hkps://keyserver.ubuntu.com
gpg: keyserver refresh failed: Server indicated a failure

here are the dirmngr logs (note: there are some logs included from some previous attempts the other day to fetch the key, but I felt like including the full logs):

2025-03-16 13:59:50 dirmngr[18306.0] permanently loaded certificates: 150
2025-03-16 13:59:50 dirmngr[18306.0]     runtime cached certificates: 0
2025-03-16 13:59:50 dirmngr[18306.0]            trusted certificates: 150 (150,0,0,0)
2025-03-16 13:59:50 dirmngr[18306.6] handler for fd 6 started
2025-03-16 13:59:50 dirmngr[18306.6] DBG: chan_6 -> # Home: /home/solonovamax/.gnupg
2025-03-16 13:59:50 dirmngr[18306.6] DBG: chan_6 -> # Config: /home/solonovamax/.gnupg/dirmngr.conf
2025-03-16 13:59:50 dirmngr[18306.6] DBG: chan_6 -> OK Dirmngr 2.4.7 at your service, process 18306
2025-03-16 13:59:50 dirmngr[18306.6] connection from process 18305 (1000:1000)
2025-03-16 13:59:50 dirmngr[18306.6] DBG: chan_6 <- GETINFO version
2025-03-16 13:59:50 dirmngr[18306.6] DBG: chan_6 -> D 2.4.7
2025-03-16 13:59:50 dirmngr[18306.6] DBG: chan_6 -> OK
2025-03-16 13:59:50 dirmngr[18306.6] DBG: chan_6 <- KS_GET -- 0xB420FD3777CCE3A7F0076B55C85668DF69375001
2025-03-16 14:00:00 dirmngr[18306.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
2025-03-16 14:00:00 dirmngr[18306.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
2025-03-16 14:00:00 dirmngr[18306.6] DBG: chan_6 <- BYE
2025-03-16 14:00:00 dirmngr[18306.6] DBG: chan_6 -> OK closing connection
2025-03-16 14:00:00 dirmngr[18306.6] handler for fd 6 terminated
2025-03-16 21:30:16 dirmngr[18306.0] running scheduled tasks
2025-03-18 11:07:41 dirmngr[38420.0] permanently loaded certificates: 150
2025-03-18 11:07:41 dirmngr[38420.0]     runtime cached certificates: 0
2025-03-18 11:07:41 dirmngr[38420.0]            trusted certificates: 150 (150,0,0,0)
2025-03-18 11:07:41 dirmngr[38420.6] handler for fd 6 started
2025-03-18 11:07:41 dirmngr[38420.6] DBG: chan_6 -> # Home: /home/solonovamax/.gnupg
2025-03-18 11:07:41 dirmngr[38420.6] DBG: chan_6 -> # Config: /home/solonovamax/.gnupg/dirmngr.conf
2025-03-18 11:07:41 dirmngr[38420.6] DBG: chan_6 -> OK Dirmngr 2.4.7 at your service, process 38420
2025-03-18 11:07:41 dirmngr[38420.6] connection from process 38418 (1000:1000)
2025-03-18 11:07:41 dirmngr[38420.6] DBG: chan_6 <- GETINFO version
2025-03-18 11:07:41 dirmngr[38420.6] DBG: chan_6 -> D 2.4.7
2025-03-18 11:07:41 dirmngr[38420.6] DBG: chan_6 -> OK
2025-03-18 11:07:41 dirmngr[38420.6] DBG: chan_6 <- KS_GET -- 0xB420FD3777CCE3A7F0076B55C85668DF69375001
2025-03-18 11:07:51 dirmngr[38420.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
2025-03-18 11:07:51 dirmngr[38420.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
2025-03-18 11:07:51 dirmngr[38420.6] DBG: chan_6 <- BYE
2025-03-18 11:07:51 dirmngr[38420.6] DBG: chan_6 -> OK closing connection
2025-03-18 11:07:51 dirmngr[38420.6] handler for fd 6 terminated
2025-03-18 11:07:57 dirmngr[38420.6] handler for fd 6 started
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 -> # Home: /home/solonovamax/.gnupg
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 -> # Config: /home/solonovamax/.gnupg/dirmngr.conf
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 -> OK Dirmngr 2.4.7 at your service, process 38420
2025-03-18 11:07:57 dirmngr[38420.6] connection from process 38500 (1000:1000)
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 <- GETINFO version
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 -> D 2.4.7
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 -> OK
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 <- KEYSERVER
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 -> S KEYSERVER hkps://keyserver.ubuntu.com
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 -> OK
2025-03-18 11:07:57 dirmngr[38420.6] DBG: chan_6 <- KS_GET -- 0xA88441BD4864F95BEE08E63A71EB474019940E11 0x248097092B458509C508DAC0350585C4E9518F26 0x19882D92DDA4C400C22C0D56CC2AF4472167BE03 0xEF6E286DDA85EA2A4BA7DE684E2C6E8793298290 0xABBAD1CB484F53024CF5868B69332F9203F21F5C 0xF9A211976ED662F00E59361E5E3C45D7B312C643 0x3E09F5908333DD83DBDCE7375680CA389D365A88 0xD3A93CAD751C2AF4F8C7AD516C35B99309B5FA62 0x13975A70E63C361C73AE69EF6EEB81F8981C74C7 0x86CFFCA918CF3AF47147588051E8B148A9999C34 0xF3691687D867B81B51CE07D9BBE43771487328A9 0x060C6B7D3869F148C4C4ACD43C9BE9B64EC1EA64 0xD81C0CB38EB725EF6691C385BB463350D6EF31EF 0xF23275E4BF10AFC1DF6914A6DBD2CE893E2D1C87 0xCA262C6C83DE4D2FB28A332A3A6A4DB839EAA6D7 0x7C35920F1CE2899E8EA9AAD02E7C0367B9BFA089 0x6B42D40B4CC6B3018F2AF209ED0FC2D44CD76482 0x6A5571928D2222D83BC7456E4EDE055B645F044F 0x748231EBCBD808A14F5E85D28C004C2F93481F6B 0x7B74D1299568B586BA9962B5649E4D4AF74E7DEC 0xFCF986EA15E6E293A5644F10B4322F04D67658D8
2025-03-18 11:11:27 dirmngr[38420.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
2025-03-18 11:11:27 dirmngr[38420.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
2025-03-18 11:11:27 dirmngr[38420.6] DBG: chan_6 <- BYE
2025-03-18 11:11:27 dirmngr[38420.6] DBG: chan_6 -> OK closing connection
2025-03-18 11:11:27 dirmngr[38420.6] handler for fd 6 terminated
2025-03-18 11:12:21 dirmngr[38420.0] SIGTERM received - shutting down ...
2025-03-18 11:12:21 dirmngr[38420.0] dirmngr (GnuPG) 2.4.7 stopped

seth wrote:

Did you play around w/ TOR?

nope

Last edited by solonovamax (2025-03-18 15:32:00)

seth · 2025-03-18 20:50:57

Yubikey, oversized MTU (jumbo frames), VPN?
Any success using the IPv6

gpg --keyserver hkps://2620:2d:4000:1007::d43 …

?

solonovamax · 2025-03-27 16:22:44

(I keep forgetting to reply, sorry)

seth wrote:

Yubikey

don't have. (but want to get smth like a Nitrokey at some point)

seth wrote:

oversized MTU (jumbo frames)

I don't think I've changed anything that would make it use that, unless it uses it by default. not sure how I'd check that, though.

seth wrote:

VPN

not that I am aware of

seth wrote:

Any success using the IPv6
gpg --keyserver hkps://2620:2d:4000:1007::d43 …
?

$ gpg --keyserver hkps://2620:2d:4000:1007::d43 --recv-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: keyserver receive failed: Server indicated a failure

nope, still fails.

seth · 2025-03-27 17:22:23

not sure how I'd check that, though.

ip l

also lists the MTU

What if you switch the keyserver?

gpg --keyserver https://keys.openpgp.org --search-keys B420FD3777CCE3A7F0076B55C85668DF69375001

GeneArch · 2025-04-12 15:38:11

This may or may not be relevant but gpg dirmngr uses gnutls which has/had problems connecting with TLS in some circumstances. For example Open Bug

It may be worth trying gnutls command line rather than gpg -> dirmngr -> gnutls then back to you.

 gnutls-cli https://keys.openpgp.org

or with sequoia

 sq network keyserver search --server hkp://keys.openpgp.org B420FD3777CCE3A7F0076B55C85668DF69375001

Last edited by GeneArch (2025-04-12 15:39:21)

vlfig · 2025-04-17 16:40:35

For what it's worth,

I was having the original issue, and I also have systemd-resolved configured to use NextDNS. However, as soon as I tried with the (v4) IPs directly it worked. Then I:
- changed resolved config to point to 1.1.1.1 directly
- sudo systemctl restart systemd-resolved.service
- sudo systemd-resolve --flush-caches

and it worked with '--keyserver keyserver.ubuntu.com'. I then reverted the config, restarted and flushed again and it kept working (maybe there's some other cache?).

Good luck.

solonovamax · 2025-09-11 17:13:56

hey, sorry it's been a hot minute since I responded, however this is still an issue for me and it never really resolved itself.

seth wrote:

ip l
also lists the MTU

$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether 80:fa:5b:95:7b:77 brd ff:ff:ff:ff:ff:ff
    altname enx80fa5b957b77
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 48:51:c5:f6:e0:6e brd ff:ff:ff:ff:ff:ff
    altname wlp3s0
    altname wlx4851c5f6e06e

seth wrote:

What if you switch the keyserver?

gpg --keyserver https://keys.openpgp.org --search-keys B420FD3777CCE3A7F0076B55C85668DF69375001

searching doesn't seem to work:

$ gpg --debug-level=guru --keyserver https://keys.openpgp.org --search-keys B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: enabled compatibility flags:
gpg: DBG: [no clock] start
gpg: DBG: chan_3 <- # Home: /home/solonovamax/.gnupg
gpg: DBG: chan_3 <- # Config: /home/solonovamax/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.4.8 at your service, process 10594
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.4.8
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear https://keys.openpgp.org
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: DBG: chan_3 <- ERR 167772339 Not enabled <Dirmngr>
gpg: error searching keyserver: Not enabled
gpg: keyserver search failed: Not enabled
gpg: DBG: chan_3 -> BYE
gpg: DBG: [no clock] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0
gpg: objcache: uids=0/0/0 chains=0,0..0 buckets=0/0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

the same happens using keyserver.ubuntu.com, so idk what this is but maybe some configuration or smth with the keyservers themselves?

if I instead try to fetch the keys with

gpg --debug-level=guru --keyserver https://keys.openpgp.org --recv B420FD3777CCE3A7F0076B55C85668DF69375001

then the same issue happens.

GeneArch wrote:

This may or may not be relevant but gpg dirmngr uses gnutls which has/had problems connecting with TLS in some circumstances. For example Open Bug
It may be worth trying gnutls command line rather than gpg -> dirmngr -> gnutls then back to you.
 gnutls-cli https://keys.openpgp.org 

if the url passed to gnutls-cli is prefixed with https, it doesn't like it

$ gnutls-cli https://keys.openpgp.org
Processed 178 CA certificate(s).
Resolving 'https://keys.openpgp.org'...
Cannot resolve https://keys.openpgp.org: Servname not supported for ai_socktype

however if I don't prefix it with https I get

gnutls-cli keys.openpgp.org
Processed 178 CA certificate(s).
Resolving 'keys.openpgp.org:443'...
Connecting to '195.201.47.43:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=keys.openpgp.org', issuer `CN=E5,O=Let's Encrypt,C=US', serial 0x05581ab24bc97cc15a2c8961af9538aad71c, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2025-07-20 20:28:42 UTC', expires `2025-10-18 20:28:41 UTC', pin-sha256="XaUOS9I5g4oWoDZ/ywnCEwpBEFE7FCeJeM/pDA1QaZs="
	Public Key ID:
		sha1:72f656cf16d79ab001fbcf4170a9b2b876432e2d
		sha256:5da50e4bd239838a16a0367fcb09c2130a4110513b14278978cfe90c0d50699b
	Public Key PIN:
		pin-sha256:XaUOS9I5g4oWoDZ/ywnCEwpBEFE7FCeJeM/pDA1QaZs=

- Certificate[1] info:
 - subject `CN=E5,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet Security Research Group,C=US', serial 0x00838f6c63ceb1398c6206628315c9fdde, EC/ECDSA key 384 bits, signed using RSA-SHA256, activated `2024-03-13 00:00:00 UTC', expires `2027-03-12 23:59:59 UTC', pin-sha256="NYbU7PBwV4y9J67c4guWTki8FJ+uudrXL0a4V4aRcrg="
- Status: The certificate is trusted.
- Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
- Session ID: 7B:90:7D:0A:D4:2D:C4:D7:F2:30:E4:7F:B6:97:87:E6:2B:6D:26:73:DD:DD:35:82:05:A6:67:C4:3A:76:B8:82
- Options:
- Handshake was completed

- Simple Client Mode:

- Peer has closed the GnuTLS connection

not sure what to make of this or if it's bad (exit code is 0 though)

here's the output with a debug level of 4 if it means anything

$ gnutls-cli --debug=4 keys.openpgp.org
|<2>| Initializing needed PKCS #11 modules
|<2>| p11: Initializing module: p11-kit-trust
|<2>| p11: No login requested.
|<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
|<3>| p11 attrs: CKA_TRUSTED
|<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
|<2>| p11: No login requested.
|<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
|<3>| p11 attrs: CKA_TRUSTED
|<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
|<3>| ASSERT: pkcs11.c[find_multi_objs_cb]:3105
|<3>| ASSERT: pkcs11.c[gnutls_pkcs11_obj_list_import_url3]:3416
Processed 178 CA certificate(s).
Resolving 'keys.openpgp.org:443'...
Connecting to '195.201.47.43:443'...
|<2>| added 6 protocols, 29 ciphersuites, 22 sig algos and 10 groups into priority list
|<4>| HSK[0x5592936104a0]: Adv. version: 3.3
|<2>| Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite 13.03 (GNUTLS_CHACHA20_POLY1305_SHA256)
|<2>| Keeping ciphersuite 13.01 (GNUTLS_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite 13.04 (GNUTLS_AES_128_CCM_SHA256)
|<2>| Keeping ciphersuite c0.2c (GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.a9 (GNUTLS_ECDHE_ECDSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.ad (GNUTLS_ECDHE_ECDSA_AES_256_CCM)
|<2>| Keeping ciphersuite c0.0a (GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite c0.2b (GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.ac (GNUTLS_ECDHE_ECDSA_AES_128_CCM)
|<2>| Keeping ciphersuite c0.09 (GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite c0.30 (GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.a8 (GNUTLS_ECDHE_RSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.14 (GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite c0.2f (GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.13 (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9d (GNUTLS_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite c0.9d (GNUTLS_RSA_AES_256_CCM)
|<2>| Keeping ciphersuite 00.35 (GNUTLS_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9c (GNUTLS_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.9c (GNUTLS_RSA_AES_128_CCM)
|<2>| Keeping ciphersuite 00.2f (GNUTLS_RSA_AES_128_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9f (GNUTLS_DHE_RSA_AES_256_GCM_SHA384)
|<2>| Keeping ciphersuite cc.aa (GNUTLS_DHE_RSA_CHACHA20_POLY1305)
|<2>| Keeping ciphersuite c0.9f (GNUTLS_DHE_RSA_AES_256_CCM)
|<2>| Keeping ciphersuite 00.39 (GNUTLS_DHE_RSA_AES_256_CBC_SHA1)
|<2>| Keeping ciphersuite 00.9e (GNUTLS_DHE_RSA_AES_128_GCM_SHA256)
|<2>| Keeping ciphersuite c0.9e (GNUTLS_DHE_RSA_AES_128_CCM)
|<2>| Keeping ciphersuite 00.33 (GNUTLS_DHE_RSA_AES_128_CBC_SHA1)
|<4>| EXT[0x5592936104a0]: Preparing extension (Post Handshake Auth/49) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (Encrypt-then-MAC/22) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension Encrypt-then-MAC/22 (0 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Server Name Indication/0) for 'client hello'
|<2>| HSK[0x5592936104a0]: sent server name: 'keys.openpgp.org'
|<4>| EXT[0x5592936104a0]: Sending extension Server Name Indication/0 (21 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Extended Master Secret/23) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension Extended Master Secret/23 (0 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Safe Renegotiation/65281) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension Safe Renegotiation/65281 (1 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Compress Certificate/27) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (Key Share/51) for 'client hello'
|<4>| EXT[0x5592936104a0]: sending key share for SECP256R1
|<4>| EXT[0x5592936104a0]: sending key share for X25519
|<4>| EXT[0x5592936104a0]: Sending extension Key Share/51 (107 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Early Data/42) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (PSK Key Exchange Modes/45) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension PSK Key Exchange Modes/45 (3 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (SRTP/14) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (ALPN/16) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (Server Certificate Type/20) for 'client hello'
|<4>| EXT[0x5592936104a0]: Server certificate type was set to default cert type (X.509). We therefore do not send this extension.
|<4>| EXT[0x5592936104a0]: Preparing extension (Signature Algorithms/13) for 'client hello'
|<4>| EXT[0x5592936104a0]: sent signature algo (9.4) ML-DSA-44
|<4>| EXT[0x5592936104a0]: sent signature algo (9.5) ML-DSA-65
|<4>| EXT[0x5592936104a0]: sent signature algo (9.6) ML-DSA-87
|<4>| EXT[0x5592936104a0]: sent signature algo (4.1) RSA-SHA256
|<4>| EXT[0x5592936104a0]: sent signature algo (8.9) RSA-PSS-SHA256
|<4>| EXT[0x5592936104a0]: sent signature algo (8.4) RSA-PSS-RSAE-SHA256
|<4>| EXT[0x5592936104a0]: sent signature algo (4.3) ECDSA-SHA256
|<4>| EXT[0x5592936104a0]: sent signature algo (8.7) EdDSA-Ed25519
|<4>| EXT[0x5592936104a0]: sent signature algo (5.1) RSA-SHA384
|<4>| EXT[0x5592936104a0]: sent signature algo (8.10) RSA-PSS-SHA384
|<4>| EXT[0x5592936104a0]: sent signature algo (8.5) RSA-PSS-RSAE-SHA384
|<4>| EXT[0x5592936104a0]: sent signature algo (5.3) ECDSA-SHA384
|<4>| EXT[0x5592936104a0]: sent signature algo (8.8) EdDSA-Ed448
|<4>| EXT[0x5592936104a0]: sent signature algo (6.1) RSA-SHA512
|<4>| EXT[0x5592936104a0]: sent signature algo (8.11) RSA-PSS-SHA512
|<4>| EXT[0x5592936104a0]: sent signature algo (8.6) RSA-PSS-RSAE-SHA512
|<4>| EXT[0x5592936104a0]: sent signature algo (6.3) ECDSA-SHA512
|<4>| EXT[0x5592936104a0]: sent signature algo (2.1) RSA-SHA1
|<4>| EXT[0x5592936104a0]: sent signature algo (2.3) ECDSA-SHA1
|<4>| EXT[0x5592936104a0]: Sending extension Signature Algorithms/13 (40 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Session Ticket/35) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension Session Ticket/35 (0 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Maximum Record Size/1) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (Supported Groups/10) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sent group SECP256R1 (0x17)
|<4>| EXT[0x5592936104a0]: Sent group SECP384R1 (0x18)
|<4>| EXT[0x5592936104a0]: Sent group SECP521R1 (0x19)
|<4>| EXT[0x5592936104a0]: Sent group X25519 (0x1d)
|<4>| EXT[0x5592936104a0]: Sent group X448 (0x1e)
|<4>| EXT[0x5592936104a0]: Sent group FFDHE2048 (0x100)
|<4>| EXT[0x5592936104a0]: Sent group FFDHE3072 (0x101)
|<4>| EXT[0x5592936104a0]: Sent group FFDHE4096 (0x102)
|<4>| EXT[0x5592936104a0]: Sent group FFDHE6144 (0x103)
|<4>| EXT[0x5592936104a0]: Sent group FFDHE8192 (0x104)
|<4>| EXT[0x5592936104a0]: Sending extension Supported Groups/10 (22 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Cookie/44) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (OCSP Status Request/5) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension OCSP Status Request/5 (5 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Supported Versions/43) for 'client hello'
|<2>| Advertizing version 3.4
|<2>| Advertizing version 3.3
|<2>| Advertizing version 3.2
|<2>| Advertizing version 3.1
|<4>| EXT[0x5592936104a0]: Sending extension Supported Versions/43 (9 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Client Certificate Type/19) for 'client hello'
|<4>| EXT[0x5592936104a0]: Client certificate type was set to default cert type (X.509). We therefore do not send this extension.
|<4>| EXT[0x5592936104a0]: Preparing extension (Supported EC Point Formats/11) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension Supported EC Point Formats/11 (2 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (Record Size Limit/28) for 'client hello'
|<4>| EXT[0x5592936104a0]: Sending extension Record Size Limit/28 (2 bytes)
|<4>| EXT[0x5592936104a0]: Preparing extension (ClientHello Padding/21) for 'client hello'
|<4>| EXT[0x5592936104a0]: Preparing extension (Pre Shared Key/41) for 'client hello'
|<4>| HSK[0x5592936104a0]: CLIENT HELLO was queued [399 bytes]
|<3>| ASSERT: buffers.c[get_last_packet]:1138
|<4>| HSK[0x5592936104a0]: SERVER HELLO (2) was received. Length 151[151], frag offset 0, frag length: 151, sequence: 0
|<3>| ASSERT: buffers.c[get_last_packet]:1130
|<3>| ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1374
|<4>| HSK[0x5592936104a0]: Server's version: 3.3
|<4>| EXT[0x5592936104a0]: Parsing extension 'Supported Versions/43' (2 bytes)
|<4>| EXT[0x5592936104a0]: Negotiated version: 3.4
|<4>| HSK[0x5592936104a0]: Selected cipher suite: GNUTLS_AES_256_GCM_SHA384
|<4>| EXT[0x5592936104a0]: Parsing extension 'Key Share/51' (69 bytes)
|<4>| HSK[0x5592936104a0]: Selected group SECP256R1 (2)
|<2>| EXT[0x5592936104a0]: client generated SECP256R1 shared key
|<4>| REC[0x5592936104a0]: Sent ChangeCipherSpec
|<4>| HSK[0x5592936104a0]: TLS 1.3 re-key with cipher suite: GNUTLS_AES_256_GCM_SHA384
|<3>| ASSERT: buffers.c[get_last_packet]:1138
|<4>| HSK[0x5592936104a0]: ENCRYPTED EXTENSIONS (8) was received. Length 32[32], frag offset 0, frag length: 32, sequence: 0
|<4>| HSK[0x5592936104a0]: parsing encrypted extensions
|<4>| EXT[0x5592936104a0]: Parsing extension 'Server Name Indication/0' (0 bytes)
|<4>| EXT[0x5592936104a0]: Parsing extension 'Supported Groups/10' (22 bytes)
|<3>| ASSERT: buffers.c[get_last_packet]:1138
|<4>| HSK[0x5592936104a0]: CERTIFICATE (11) was received. Length 2043[2043], frag offset 0, frag length: 2043, sequence: 0
|<3>| ASSERT: buffers.c[get_last_packet]:1130
|<3>| ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1374
|<4>| HSK[0x5592936104a0]: parsing certificate message
|<3>| ASSERT: buffers.c[get_last_packet]:1138
|<4>| HSK[0x5592936104a0]: CERTIFICATE VERIFY (15) was received. Length 76[76], frag offset 0, frag length: 76, sequence: 0
|<4>| HSK[0x5592936104a0]: Parsing certificate verify
|<4>| HSK[0x5592936104a0]: verifying TLS 1.3 handshake data using ECDSA-SECP256R1-SHA256
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=keys.openpgp.org', issuer `CN=E5,O=Let's Encrypt,C=US', serial 0x05581ab24bc97cc15a2c8961af9538aad71c, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2025-07-20 20:28:42 UTC', expires `2025-10-18 20:28:41 UTC', pin-sha256="XaUOS9I5g4oWoDZ/ywnCEwpBEFE7FCeJeM/pDA1QaZs="
	Public Key ID:
		sha1:72f656cf16d79ab001fbcf4170a9b2b876432e2d
		sha256:5da50e4bd239838a16a0367fcb09c2130a4110513b14278978cfe90c0d50699b
	Public Key PIN:
		pin-sha256:XaUOS9I5g4oWoDZ/ywnCEwpBEFE7FCeJeM/pDA1QaZs=

- Certificate[1] info:
 - subject `CN=E5,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet Security Research Group,C=US', serial 0x00838f6c63ceb1398c6206628315c9fdde, EC/ECDSA key 384 bits, signed using RSA-SHA256, activated `2024-03-13 00:00:00 UTC', expires `2027-03-12 23:59:59 UTC', pin-sha256="NYbU7PBwV4y9J67c4guWTki8FJ+uudrXL0a4V4aRcrg="
|<3>| ASSERT: ocsp-api.c[gnutls_ocsp_status_request_get2]:96
|<3>| ASSERT: ocsp-api.c[gnutls_ocsp_status_request_get2]:96
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: verify.c[verify_crt]:702
|<3>| ASSERT: verify.c[verify_crt]:880
|<3>| ASSERT: verify.c[_gnutls_verify_crt_status]:1065
|<2>| issuer in verification was not found or insecure; trying against trust list
|<3>| ASSERT: verify.c[verify_crt]:702
|<3>| ASSERT: verify.c[verify_crt]:880
|<3>| ASSERT: verify.c[_gnutls_verify_crt_status]:1065
|<3>| ASSERT: verify-high.c[gnutls_x509_trust_list_verify_crt2]:1580
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<2>| crt_is_known: did not find cert, using issuer DN + serial, using DN only
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4627
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4649
|<2>| crt_is_known: did not find any cert
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<2>| crt_is_known: did not find cert, using issuer DN + serial, using DN only
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4627
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4649
|<2>| crt_is_known: did not find any cert
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<2>| crt_is_known: did not find cert, using issuer DN + serial, using DN only
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4627
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4649
|<2>| crt_is_known: did not find any cert
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<2>| crt_is_known: did not find cert, using issuer DN + serial, using DN only
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4627
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4649
|<2>| crt_is_known: did not find any cert
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<2>| Initializing all PKCS #11 modules
|<2>| p11: Initializing module: p11-kit-trust
|<2>| p11: module p11-kit-trust is already loaded.
|<3>| ASSERT: pkcs11.c[auto_load]:958
|<2>| Cannot load PKCS #11 module: p11-kit-trust
|<3>| ASSERT: pkcs11.c[compat_load]:906
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<2>| check_found_cert: cert doesn't match the expected
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<2>| get_distrust_after: did not find cert, using issuer DN + serial, using DN only
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_get_distrust_after]:4861
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<2>| check_found_cert: cert doesn't match the expected
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_get_distrust_after]:4876
|<2>| get_distrust_after: did not find any cert
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<2>| crt_is_known: did not find cert, using issuer DN + serial, using DN only
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4627
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<2>| p11: No login requested.
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4272
|<3>| ASSERT: pkcs11.c[find_cert_cb]:4083
|<3>| ASSERT: pkcs11.c[_gnutls_pkcs11_crt_is_known]:4649
|<2>| crt_is_known: did not find any cert
|<3>| ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:592
|<2>| looking for key purpose '1.3.6.1.5.5.7.3.1', but have '1.3.6.1.5.5.7.3.2'
|<3>| ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:592
- Status: The certificate is trusted.
|<3>| ASSERT: buffers.c[get_last_packet]:1138
|<4>| HSK[0x5592936104a0]: FINISHED (20) was received. Length 48[48], frag offset 0, frag length: 48, sequence: 0
|<4>| HSK[0x5592936104a0]: parsing finished
|<4>| HSK[0x5592936104a0]: sending finished
|<4>| HSK[0x5592936104a0]: FINISHED was queued [52 bytes]
|<3>| ASSERT: constate.c[_gnutls_epoch_get]:965
|<4>| HSK[0x5592936104a0]: TLS 1.3 re-key with cipher suite: GNUTLS_AES_256_GCM_SHA384
- Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
- Session ID: FE:EA:15:02:DD:FC:10:92:54:04:94:0E:DA:78:B9:C5:49:C7:26:8C:01:55:B8:6E:17:B0:88:78:A5:60:FE:EB
|<3>| ASSERT: server_name.c[gnutls_server_name_get]:224
|<3>| ASSERT: ocsp-api.c[gnutls_ocsp_status_request_get2]:96
|<3>| ASSERT: ocsp-api.c[gnutls_ocsp_status_request_is_checked]:638
- Options:
|<3>| ASSERT: srtp.c[gnutls_srtp_get_selected_profile]:295
|<3>| ASSERT: alpn.c[gnutls_alpn_get_selected_protocol]:233
- Handshake was completed

- Simple Client Mode:

|<3>| ASSERT: buffers.c[get_last_packet]:1138
|<4>| HSK[0x5592936104a0]: NEW SESSION TICKET (4) was received. Length 53[53], frag offset 0, frag length: 53, sequence: 0
|<3>| ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1392
|<4>| HSK[0x5592936104a0]: parsing session ticket message
|<3>| ASSERT: record.c[_gnutls_recv_in_buffers]:1565
|<3>| ASSERT: record.c[_gnutls_recv_int]:1759
|<3>| ASSERT: buffers.c[get_last_packet]:1138
|<4>| HSK[0x5592936104a0]: NEW SESSION TICKET (4) was received. Length 53[53], frag offset 0, frag length: 53, sequence: 0
|<3>| ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1392
|<4>| HSK[0x5592936104a0]: parsing session ticket message
|<3>| ASSERT: record.c[_gnutls_recv_in_buffers]:1565
|<3>| ASSERT: record.c[_gnutls_recv_int]:1759
|<3>| ASSERT: record.c[_gnutls_recv_in_buffers]:1565
- Peer has closed the GnuTLS connection

GeneArch wrote:

or with sequoia

 sq network keyserver search --server hkp://keys.openpgp.org B420FD3777CCE3A7F0076B55C85668DF69375001

initially, when I tried to fetch the key using the sequoia command, it failed. however I no longer have that error message. I believe it was the following but I'm not 100% sure.

$ sq network keyserver search --server hkp://keys.openpgp.org B420FD3777CCE3A7F0076B55C85668DF69375001
hkp://keys.openpgp.org: B420FD3777CCE3A7F0076B55C85668DF69375001: error sending request for url
(http://keys.openpgp.org:11371/pks/lookup?op=get&options=mr&search=0xB420FD3777CCE3A7F0076B55C85668DF69375001)

  Error: No cert found.

vlfig wrote:

For what it's worth,
I was having the original issue, and I also have systemd-resolved configured to use NextDNS. However, as soon as I tried with the (v4) IPs directly it worked. Then I:
- changed resolved config to point to 1.1.1.1 directly
- sudo systemctl restart systemd-resolved.service
- sudo systemd-resolve --flush-caches
and it worked with '--keyserver keyserver.ubuntu.com'. I then reverted the config, restarted and flushed again and it kept working (maybe there's some other cache?).
Good luck.

I tried doing these steps, and gpg still fails.
after the changes, /etc/systemd/resolved.conf is now

[Resolve]
DNS=1.1.1.1 1.0.0.1

and /etc/NetworkManager/conf.d/dns.conf is

[main]
dns=systemd-resolved

however, after doing this, the sequoia command works ??

$ sq network keyserver search --server hkp://keys.openpgp.org B420FD3777CCE3A7F0076B55C85668DF69375001

Found 1 certificate related to the query:

 - B420FD3777CCE3A7F0076B55C85668DF69375001
   - <unknown>
   - created 2024-11-13 15:00:16 UTC
   - not valid: No binding signature at time 2025-09-11T17:05:45Z
   - found via: hkp://keys.openpgp.org
Imported 0 new certificates, updated 0 certificates, 1 certificate unchanged, 0 errors.

even after changing the above two configs back to what they originally were, I still can't 100% reproduce the error. however intermitently I will sometimes get

$ sq network keyserver search --server hkp://keys.openpgp.org B420FD3777CCE3A7F0076B55C85668DF69375001
hkp://keys.openpgp.org: B420FD3777CCE3A7F0076B55C85668DF69375001: error sending request for url
(http://keys.openpgp.org:11371/pks/lookup?op=get&options=mr&search=0xB420FD3777CCE3A7F0076B55C85668DF69375001)

  Error: No cert found.

so I'm assuming that by random chance I just got that the first time I ran it and didn't try running it again before changing the dns.

seth · 2025-09-11 19:44:51

This is lethal:

gpg: DBG: chan_3 <- ERR 167772339 Not enabled <Dirmngr>

=> https://bbs.archlinux.org/viewtopic.php … 8#p2187838 ?

Edit: b/c of https://unix.stackexchange.com/question … iled-not-e - do you still have the standard-resolver enabled?

Last edited by seth (2025-09-11 19:46:09)

solonovamax · 2025-09-15 22:18:09

seth wrote:

This is lethal:
gpg: DBG: chan_3 <- ERR 167772339 Not enabled <Dirmngr>
=> https://bbs.archlinux.org/viewtopic.php … 8#p2187838 ?

$ nmap keyserver.ubuntu.com
Starting Nmap 7.97 ( https://nmap.org ) at 2025-09-15 17:57 -0400
Nmap scan report for keyserver.ubuntu.com (185.125.188.27)
Host is up (0.0088s latency).
Other addresses for keyserver.ubuntu.com (not scanned): 185.125.188.26
Not shown: 995 filtered tcp ports (no-response)
PORT     STATE  SERVICE
80/tcp   open   http
113/tcp  closed ident
443/tcp  open   https
5060/tcp open   sip
8010/tcp open   xmpp

I also ran nmap on port 11371 because according to wikipedia that's the port that hkp uses:

$ nmap keyserver.ubuntu.com -p 11371
Starting Nmap 7.97 ( https://nmap.org ) at 2025-09-15 17:57 -0400
Nmap scan report for keyserver.ubuntu.com (185.125.188.27)
Host is up (0.011s latency).
Other addresses for keyserver.ubuntu.com (not scanned): 185.125.188.26

PORT      STATE SERVICE
11371/tcp open  pksd

Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds

seth wrote:

Edit: b/c of https://unix.stackexchange.com/question … iled-not-e - do you still have the standard-resolver enabled?

this is the full contents of dirmngr.conf (with all comments):

###+++--- GPGConf ---+++###
debug-level basic
log-file socket:///home/solonovamax/.gnupg/log-socket
resolver-timeout 100
connect-timeout 100
connect-quick-timeout 100
###+++--- GPGConf ---+++### Fri 21 Feb 2022 03:44:00 PM EDT
# GPGConf edited this configuration file
# It will disable options before this marked block, but it will
# never change anything below these lines

#keyserver hkps://keys.openpgp.org
#keyserver https://keyserver.ubuntu.com
log-file /home/solonovamax/.gnupg/dirmngr.log
verbose
debug-level guru
nameserver 1.1.1.1
standard-resolver

if I disable the standard-resolver line, then I get the following:

$ gpg --debug-level=guru --keyserver https://keys.openpgp.org --recv B420FD3777CCE3A7F0076B55C85668DF69375001
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: enabled compatibility flags:
gpg: DBG: [no clock] start
gpg: DBG: chan_3 <- # Home: /home/solonovamax/.gnupg
gpg: DBG: chan_3 <- # Config: /home/solonovamax/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.4.8 at your service, process 51537
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.4.8
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear https://keys.openpgp.org
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0xB420FD3777CCE3A7F0076B55C85668DF69375001
gpg: DBG: chan_3 <- ERR 167772379 Server indicated a failure <Dirmngr>
gpg: keyserver receive failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: DBG: [no clock] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0
gpg: objcache: uids=0/0/0 chains=0,0..0 buckets=0/0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

also, that "not enabled" message doesn't show in the dirmngr logs, only in the gpg logs it seems
dirmngr shows:

2025-09-15 17:59:39 dirmngr[50176.0] permanently loaded certificates: 146
2025-09-15 17:59:39 dirmngr[50176.0]     runtime cached certificates: 0
2025-09-15 17:59:39 dirmngr[50176.0]            trusted certificates: 146 (146,0,0,0)
2025-09-15 17:59:39 dirmngr[50176.6] handler for fd 6 started
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 -> # Home: /home/solonovamax/.gnupg
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 -> # Config: /home/solonovamax/.gnupg/dirmngr.conf
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 -> OK Dirmngr 2.4.8 at your service, process 50176
2025-09-15 17:59:39 dirmngr[50176.6] connection from process 50175 (1000:1000)
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 <- GETINFO version
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 -> D 2.4.8
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 -> OK
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 <- KEYSERVER --clear https://keys.openpgp.org
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 -> OK
2025-09-15 17:59:39 dirmngr[50176.6] DBG: chan_6 <- KS_GET -- 0xB420FD3777CCE3A7F0076B55C85668DF69375001
2025-09-15 17:59:39 dirmngr[50176.6] number of system provided CAs: 178
2025-09-15 17:59:39 dirmngr[50176.6] detected interfaces: IPv4 IPv6
2025-09-15 18:01:40 dirmngr[50176.6] can't connect to 'keys.openpgp.org': Connection timed out
2025-09-15 18:01:40 dirmngr[50176.6] error connecting to 'https://keys.openpgp.org': Connection timed out
2025-09-15 18:01:40 dirmngr[50176.6] command 'KS_GET' failed: Connection timed out
2025-09-15 18:01:40 dirmngr[50176.6] DBG: chan_6 -> ERR 167805060 Connection timed out <Dirmngr>
2025-09-15 18:01:40 dirmngr[50176.6] DBG: chan_6 <- BYE
2025-09-15 18:01:40 dirmngr[50176.6] DBG: chan_6 -> OK closing connection
2025-09-15 18:01:40 dirmngr[50176.6] handler for fd 6 terminated

seth · 2025-09-16 07:13:25

This isn't about the hkp server but the local dirmngr port.

ss -tulpen

Your dirmngr log however shows a completely different problem

2025-09-15 18:01:40 dirmngr[50176.6] can't connect to 'keys.openpgp.org': Connection timed out
2025-09-15 18:01:40 dirmngr[50176.6] error connecting to 'https://keys.openpgp.org': Connection timed out
2025-09-15 18:01:40 dirmngr[50176.6] command 'KS_GET' failed: Connection timed out

Can you open https://keys.openpgp.org/ in a browser?

solonovamax · 2025-09-19 19:27:50

seth wrote:

This isn't about the hkp server but the local dirmngr port.
ss -tulpen

$ ss -tulpen
Netid State  Recv-Q Send-Q                    Local Address:Port  Peer Address:PortProcess                                                                                                                                                                                                                              
udp   UNCONN 0      0                            127.0.0.54:53         0.0.0.0:*                                                uid:977 ino:1398 sk:1 cgroup:/system.slice/systemd-resolved.service <->                                                                                                                 
udp   UNCONN 0      0                         127.0.0.53%lo:53         0.0.0.0:*                                                uid:977 ino:1396 sk:2 cgroup:/system.slice/systemd-resolved.service <->                                                                                                                 
udp   UNCONN 0      0                          172.31.4.169:123        0.0.0.0:*                                                uid:87 ino:80795 sk:3 cgroup:/system.slice/ntpd.service <->                                                                                                                             
udp   UNCONN 0      0                             127.0.0.1:123        0.0.0.0:*                                                ino:6819 sk:4 cgroup:/system.slice/ntpd.service <->                                                                                                                                     
udp   UNCONN 0      0                               0.0.0.0:123        0.0.0.0:*                                                ino:6814 sk:5 cgroup:/system.slice/ntpd.service <->                                                                                                                                     
udp   UNCONN 0      0                               0.0.0.0:33467      0.0.0.0:*    users:(("kdeconnectd",pid=1970,fd=21))      uid:1000 ino:71938 sk:6 cgroup:/user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus\x2d:1.1\x2dorg.kde.kdeconnect.slice/dbus-:1.1-org.kde.kdeconnect@0.service <->          
udp   UNCONN 0      0                               0.0.0.0:5353       0.0.0.0:*                                                uid:975 ino:5832 sk:7 cgroup:/system.slice/avahi-daemon.service <->                                                                                                                     
udp   UNCONN 0      0                               0.0.0.0:5353       0.0.0.0:*                                                uid:977 ino:1390 sk:8 cgroup:/system.slice/systemd-resolved.service <->                                                                                                                 
udp   UNCONN 0      0                               0.0.0.0:5355       0.0.0.0:*                                                uid:977 ino:1380 sk:9 cgroup:/system.slice/systemd-resolved.service <->                                                                                                                 
udp   UNCONN 0      0                                     *:60362            *:*    users:(("kdeconnectd",pid=1970,fd=22))      uid:1000 ino:71939 sk:a cgroup:/user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus\x2d:1.1\x2dorg.kde.kdeconnect.slice/dbus-:1.1-org.kde.kdeconnect@0.service v6only:0 <-> 
udp   UNCONN 0      0      [fe80::c4e8:c4e7:e6c3:9af4]%wlo1:123           [::]:*                                                uid:87 ino:25399 sk:b cgroup:/system.slice/ntpd.service v6only:1 <->                                                                                                                    
udp   UNCONN 0      0                                 [::1]:123           [::]:*                                                ino:6820 sk:c cgroup:/system.slice/ntpd.service v6only:1 <->                                                                                                                            
udp   UNCONN 0      0                                  [::]:123           [::]:*                                                ino:6811 sk:d cgroup:/system.slice/ntpd.service v6only:1 <->                                                                                                                            
udp   UNCONN 0      0                                     *:1716             *:*    users:(("kdeconnectd",pid=1970,fd=18))      uid:1000 ino:18061 sk:e cgroup:/user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus\x2d:1.1\x2dorg.kde.kdeconnect.slice/dbus-:1.1-org.kde.kdeconnect@0.service v6only:0 <-> 
udp   UNCONN 0      0                                  [::]:5353          [::]:*                                                uid:977 ino:1391 sk:f cgroup:/system.slice/systemd-resolved.service v6only:1 <->                                                                                                        
udp   UNCONN 0      0                                  [::]:5353          [::]:*                                                uid:975 ino:5833 sk:10 cgroup:/system.slice/avahi-daemon.service v6only:1 <->                                                                                                           
udp   UNCONN 0      0                                     *:5353             *:*    users:(("kdeconnectd",pid=1970,fd=20))      uid:1000 ino:18064 sk:11 cgroup:/user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus\x2d:1.1\x2dorg.kde.kdeconnect.slice/dbus-:1.1-org.kde.kdeconnect@0.service v6only:0 <->
udp   UNCONN 0      0                                  [::]:5355          [::]:*                                                uid:977 ino:1388 sk:12 cgroup:/system.slice/systemd-resolved.service v6only:1 <->                                                                                                       
tcp   LISTEN 0      4096                          127.0.0.1:46101      0.0.0.0:*                                                uid:43 ino:4952 sk:13 cgroup:/system.slice/tor.service <->                                                                                                                              
tcp   LISTEN 0      32                              0.0.0.0:4713       0.0.0.0:*    users:(("pipewire-pulse",pid=1256,fd=18))   uid:1000 ino:7017 sk:14 cgroup:/user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-pulse.service <->                                                                   
tcp   LISTEN 0      4096                            0.0.0.0:5355       0.0.0.0:*                                                uid:977 ino:1381 sk:15 cgroup:/system.slice/systemd-resolved.service <->                                                                                                                
tcp   LISTEN 0      4096                          127.0.0.1:11434      0.0.0.0:*                                                uid:951 ino:6008 sk:16 cgroup:/system.slice/ollama.service <->                                                                                                                          
tcp   LISTEN 0      80                              0.0.0.0:3306       0.0.0.0:*                                                uid:973 ino:7695 sk:17 cgroup:/system.slice/mariadb.service <->                                                                                                                         
tcp   LISTEN 0      511                             0.0.0.0:80         0.0.0.0:*                                                ino:6061 sk:18 cgroup:/system.slice/nginx.service <->                                                                                                                                   
tcp   LISTEN 0      128                             0.0.0.0:22         0.0.0.0:*                                                ino:6050 sk:19 cgroup:/system.slice/sshd.service <->                                                                                                                                    
tcp   LISTEN 0      4096                          127.0.0.1:9050       0.0.0.0:*                                                ino:6790 sk:1a cgroup:/system.slice/tor.service <->                                                                                                                                     
tcp   LISTEN 0      200                           127.0.0.1:5432       0.0.0.0:*                                                uid:947 ino:9082 sk:1b cgroup:/system.slice/postgresql.service <->                                                                                                                      
tcp   LISTEN 0      4096                         127.0.0.54:53         0.0.0.0:*                                                uid:977 ino:1399 sk:1c cgroup:/system.slice/systemd-resolved.service <->                                                                                                                
tcp   LISTEN 0      4096                          127.0.0.1:631        0.0.0.0:*                                                ino:9441 sk:1d cgroup:/system.slice/system-cups.slice/cups.service <->                                                                                                                  
tcp   LISTEN 0      4096                      127.0.0.53%lo:53         0.0.0.0:*                                                uid:977 ino:1397 sk:1e cgroup:/system.slice/systemd-resolved.service <->                                                                                                                
tcp   LISTEN 0      32                                 [::]:4713          [::]:*    users:(("pipewire-pulse",pid=1256,fd=19))   uid:1000 ino:7018 sk:1f cgroup:/user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-pulse.service v6only:1 <->                                                          
tcp   LISTEN 0      4096                               [::]:5355          [::]:*                                                uid:977 ino:1389 sk:20 cgroup:/system.slice/systemd-resolved.service v6only:1 <->                                                                                                       
tcp   LISTEN 0      80                                 [::]:3306          [::]:*                                                uid:973 ino:7696 sk:21 cgroup:/system.slice/mariadb.service v6only:1 <->                                                                                                                
tcp   LISTEN 0      511                                [::]:80            [::]:*                                                ino:6062 sk:22 cgroup:/system.slice/nginx.service v6only:1 <->                                                                                                                          
tcp   LISTEN 0      128                                [::]:22            [::]:*                                                ino:6052 sk:23 cgroup:/system.slice/sshd.service v6only:1 <->                                                                                                                           
tcp   LISTEN 0      50                                    *:1716             *:*    users:(("kdeconnectd",pid=1970,fd=19))      uid:1000 ino:18062 sk:24 cgroup:/user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus\x2d:1.1\x2dorg.kde.kdeconnect.slice/dbus-:1.1-org.kde.kdeconnect@0.service v6only:0 <->
tcp   LISTEN 0      4096                 [::ffff:127.0.0.1]:40525            *:*    users:(("jetbrains-toolb",pid=2079,fd=164)) uid:1000 ino:27529 sk:25 cgroup:/user.slice/user-1000.slice/user@1000.service/app.slice/app-jetbrains\x2dtoolbox@autostart.service v6only:0 <->                                         
tcp   LISTEN 0      50                   [::ffff:127.0.0.1]:8010             *:*                                                uid:61534 ino:10366 sk:26 cgroup:/system.slice/languagetool.service v6only:0 <->                                                                                                        
tcp   LISTEN 0      200                               [::1]:5432          [::]:*                                                uid:947 ino:9081 sk:27 cgroup:/system.slice/postgresql.service v6only:1 <->                                                                                                             
tcp   LISTEN 0      4096                              [::1]:631           [::]:*                                                ino:9440 sk:28 cgroup:/system.slice/system-cups.slice/cups.service v6only:1 <->                                                                                                         
tcp   LISTEN 0      50                   [::ffff:127.0.0.1]:52829            *:*    users:(("jetbrains-toolb",pid=2079,fd=181)) uid:1000 ino:28499 sk:29 cgroup:/user.slice/user-1000.slice/user@1000.service/app.slice/app-jetbrains\x2dtoolbox@autostart.service v6only:0 <->

seth wrote:

Your dirmngr log however shows a completely different problem

2025-09-15 18:01:40 dirmngr[50176.6] can't connect to 'keys.openpgp.org': Connection timed out
2025-09-15 18:01:40 dirmngr[50176.6] error connecting to 'https://keys.openpgp.org': Connection timed out
2025-09-15 18:01:40 dirmngr[50176.6] command 'KS_GET' failed: Connection timed out

Can you open https://keys.openpgp.org/ in a browser?

yes, I can. which is why it confuses me. though, my browser is not using my system dns. however, if I switch to using my system dns then I still can access it. I can also ping and curl it with no issue.

seth · 2025-09-19 20:08:04

Aaaaaad

tcp   LISTEN 0      4096                          127.0.0.1:9050       0.0.0.0:*                                                ino:6790 sk:1a cgroup:/system.slice/tor.service <->

we have a winner.

solonovamax · 2025-09-21 23:48:43

seth wrote:

Aaaaaad

tcp   LISTEN 0      4096                          127.0.0.1:9050       0.0.0.0:*                                                ino:6790 sk:1a cgroup:/system.slice/tor.service <->

we have a winner.

disabling the tor systemd service completely fixed the issue.
any idea why the tor systemd service would be messing with dirmngr?

seth · 2025-09-22 08:08:14

https://man.archlinux.org/man/dirmngr.8.en#use ?

Arch Linux

#1 2025-03-07 20:18:05