--refresh-keys my gpg key-chain, but gpg doesn't let me.
$ gpg --refresh-keys gpg: refreshing 42 keys from hkp://keys.gnupg.net gpg: keyserver refresh failed: No keyserver available
- The Arch Linux Wiki page on gpg mentioned that killing
dirmngrbefore trying again might work out, but to no avail.
- Upgrading all packages
sudo pacman -Syudid not help
- Rebooting did not help
- Specifying a keyserver manually
gpg --refresh-keys --keyserver keyserver.ubuntu.com:80doesn't change a thing
Maybe my firewall log can give me some hints.
$ gpg --refresh-keys 2> /dev/null # journalctl --since "30 seconds ago" Mar 01 14:33:55 user kernel: [UFW AUDIT] IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=37191 DF PROTO=TCP SPT=50354 DPT=9050 WINDOW=43690 RES=0x00 SYN URGP=0 Mar 01 14:33:55 user kernel: [UFW AUDIT] IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=37186 DF PROTO=TCP SPT=35828 DPT=9150 WINDOW=43690 RES=0x00 SYN URGP=0
Every time I run the command, something tries to connect to 127.0.0.1 on port 9050, then 9150. Looking up those ports on Wikipedia tells me these two ports are used by Tor.
~/.gnupg/dirmngr.conf specifies a .onion address as a
keyserver, so this makes sense now. Moving on!
# My ~/.gnupg/dirmngr.conf keyserver hkp://jirk5u4osbsr34t5.onion keyserver hkp://keys.gnupg.net
Debug the dirmngr program
Killing off existing instances
pkill dirmngr. Then starting
--debug to get some verbose output.
$ gpg --debug 1024 --refresh gpg: reading options from '/home/user/.gnupg/gpg.conf' gpg: enabled debug flags: ipc gpg: DBG: chan_3 <- # Home: /home/user/.gnupg gpg: DBG: chan_3 <- # Config: /home/user/.gnupg/dirmngr.conf gpg: DBG: chan_3 <- OK Dirmngr 2.1.19 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.1.19 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER gpg: DBG: chan_3 <- S KEYSERVER hkp://keys.gnupg.net gpg: DBG: chan_3 <- OK gpg: refreshing 11 keys from hkp://keys.gnupg.net gpg: DBG: chan_3 -> KS_GET -- <a list of keys> gpg: DBG: chan_3 <- ERR 167772379 Server indicated a failure <Dirmngr> gpg: keyserver refresh failed: Server indicated a failure gpg: DBG: chan_3 -> BYE gpg: secmem usage: 0/32768 bytes in 0 blocks
After searching around for the number after
ERR 167772379 and gpg, I came to [a bug posted to Arch Linux][arch] describing
a proposed work-around to start
--standard-resolver This option forces the use of the system's standard DNS resolver code.
echo "standard-resolver" >> ~/.gnupg/dirmngr.conf
dirmngr process if it's running to make sure new config is used
$ pkill dirmngr
$ pkill dirmngr $ gpg --refresh-keys gpg: refreshing 42 keys from hkp://keys.gnupg.net [output redacted] gpg: Total number processed: 42 gpg: unchanged: 21
I suspect this problem may be due to [my strict iptables] rules as well. Will maybe get back to this in the future with a different fix.