You are not logged in.
Pages: 1
Topic closed
TL;DR Solution: systemctl to stop, kill, re-enable the avahi daemon and dnsconfig service. No clue why it only affected key servers, everything else was resolving fine.
This started out of nowhere earlier this morning after a fresh install on this PC, I did no updates prior to this happening. When I tried to install RVM via the rvm.io site, following their instructions, I used
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3and got
gpg: keyserver receive failed: Network is unreachableI now get
gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net:80
gpg: keyserver refresh failed: Server indicated a failurewhen I try to refresh my own personal key or any key outside of pacman-key. I cannot update, add, or import keys. The key I am trying to refresh in the error output is my own, I know it is valid. When I try to add public keys from GitHub trusted users or an AUR user I trust, I get the same timeout errors. Again, pacman-key works fine for whatever reason, but manually importing a key does not work. I do not know if this is a db issue, a file permission mistake somewhere, a change in how gnupg works, or something else. Here's what I've done:
Wiped gnupg completely, for both root and user, uninstalled it completely with pacman, then manually and forceably removed all remaining conf files and directories, including /etc/gnupg2/ and the hidden /home/.gnupg directories of both myself and root. I then reinstalled using pacman, reinitialized pacman-key, etc. This solution worked for many Arch users.
Used "dirmngr </dev/null" to wipe and reset root and myself, then corrected this error:
error opening '/root/.gnupg/dirmngr_ldapservers.conf': No such file or directoryby creating an empty .conf file for both root and myself.
Downgraded gnupg to 2.1.20-2 (previous version before latest upgrade)
Manually added and tried various keyservers, found in the Arch Wiki and notably within
https://wiki.archlinux.org/index.php/Gn … tion_files (I also added a completely outside one with hkp://pgp.mit.edu, thanks to RVM's suggestion.
Added myself to adm, sys, lock, bin, and several other groups, just to eliminate that. Yes, I re-removed myself from those after and between reboots.
Reinstalled anything remotely connected to pgp, GnuPG, Seahorse, nemo-seahorse-nonautilus, policykit-helper, etc. I did this because I started thinking this is a permission or ownership problem somewhere.
Re-initialized pacman-key, re-populated, refreshed, updated trust db. That works fine. It's when I try to add any key from the public that I get errors.
Here is my current gpg version information and gpgconf output:
gpg (GnuPG) 2.1.21
libgcrypt 1.7.7
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: *redactedusernamed*/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
--------------------
gpg:OpenPGP:/usr/bin/gpg2
gpg-agent:Private Keys:/usr/bin/gpg-agent
scdaemon:Smartcards:/usr/lib/gnupg/scdaemon
gpgsm:S/MIME:/usr/bin/gpgsm
dirmngr:Network:/usr/bin/dirmngr
pinentry:Passphrase Entry:/usr/bin/pinentryHere is the verbose output of my command:
sudo gpg --keyserver hkp://keys.gnupg.net --recv-keys --verbose 409B6B1796C275462A1703113804BB82D39DC0E3
gpg: no running Dirmngr - starting '/usr/bin/dirmngr'
gpg: waiting for the dirmngr to come up ... (5s)
gpg: connection to the dirmngr established
gpg: keyserver receive failed: Server indicated a failureThis same error is produced no matter which keyserver. I'm not smart enough to know if this is dirmngr feeding me the bullshit or gpg itself in this instance, because it seems like Dirmngr is reporting the failure back to pgp, who then reported to me, but that might be wrong.
Interestingly, here's a journal -x | grep snippet of pacman-key hitting the mit.edu keyserver and getting 404'd, which isn't reflected anywhere else in my system, at least not in my network or router or firewall. However I can ping pgp.mit.edu just fine, it's up.
Jun 10 06:09:42 hostname sudo[3176]: root : TTY=pts/0 ; PWD=/usr/share/gnupg ; USER=root ; COMMAND=/usr/bin/pacman-key --keyserver hkp://pgp.mit.edu --refresh-keys
Jun 10 07:06:53 hostname dirmngr[863]: resolve_dns_addr for 'pgp.mit.edu': 'pgp.mit.edu' [already known]
Jun 10 07:06:54 hostname dirmngr[863]: error accessing 'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x4A8BD79A8D3880FA09D5DAF1D7C222E6B2E5008A': http status 404
Jun 10 07:11:25 hostname dirmngr[863]: error accessing 'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x4A8BD79A8D3880FA09D5DAF1D7C222E6B2E5008A': http status 404I've honestly spent more time on this at this point than it would take to reinstall the whole goddamn system. Bit frustrating. I think I can actually pinpoint the exact time that this started, using the journal. It was right around 5:09AM PST that I was able to import public keys (a specific key needed for a AUR package I've used on every PC I've setup) only to have it completely stop working when I tried to import another key, right around when I went to the RVM .io site and pulled their source and tried to add that pub key. I also am now getting errors from Seahorse when I try to do this manually with a GUI, but it won't specify the error. It just says it cannot complete.
Edit: Among the dozen or so Arch threads related to this that I read, I used this for reference: https://bbs.archlinux.org/viewtopic.php?id=190380
Last edited by nannerpussy (2017-06-10 18:33:10)
Offline
I had a similar problem the other day with a fresh install and fixed it via this .
Namely creating the homedir in tmp and then moving it to your home as the seventh comment suggests.
So it would be something like this for you
gpg --homedir /tmp --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3Offline
I had a similar problem the other day with a fresh install and fixed it via this .
Namely creating the homedir in tmp and then moving it to your home as the seventh comment suggests.
So it would be something like this for yougpg --homedir /tmp --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
Not a bad thought, but no dice. However, I think I've narrowed this down to some kind of DNS resolution issue. I'm wondering if the latest update changed something with how Dirmngr attempts to connect. I also noticed that in the logs, it is trying to resolve an http address, not hkp or https. Not sure if that's standard or not.
Offline
Have you tried using the IP address of the key server? That might get around the DNS issue.
Offline
Have you tried using the IP address of the key server? That might get around the DNS issue.
No, but I fixed it:
gpg: key 3804BB82D39DC0E3: public key "Michal Papis (RVM signing) <mpapis@gmail.com>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
It was a DNS error and avahi was behind it, but I still don't know how. I use Avahi systemd DNS services on this home network and it has always started and enabled and never given me grief EVER, until today. Killing it and re-enabling, then logging into my router and kicking/clearing myself and rebooting seems to have done it. What's weird though is I didn't have any issues with anything other than keyservers. I could resolve fine, I have DLNA running locally to share to my phone, I could ping and visit the keyservers outward facing web pages, etc. I wish I knew more about how DNS was being translated and used via Avahi at a lower level, but there must have been a corrupt entry somewhere.
Edit: see my final post here, several of the suspect packages were just updated a few hours after I posted this.
Last edited by nannerpussy (2017-06-11 01:27:18)
Offline
Sorry to bump this, but I just had
p11-kit-0.23.7-1-x86_64
ca-certificates-mozilla-3.31-3-x86_64
glib2-2.52.2+9+g3245eba16-1-x86_64
glib2-docs-2.52.2+9+g3245eba16-1-x86_64
gnupg-2.1.21-3-x86_64
nspr-4.15-1-x86_64
nss-3.31-3-x86_64Come down in an update 10 minutes ago. I'm not the sharpest knife, but my keen intuition tells me that this was a larger problem than just me and that there was an upstream issue somewhere that affected policy handling. Or I'm just an idiot and for some reason these packages were held back by something I did locally and I didn't get an error about it. I can't say why resetting Avahi's DNS service fixed this for me, but in trying to fix this I was checking and tweaking and reinstalling four of those packages that just got updated because that's where the problem seemed to be. If you are also having weird issues with key server DNS resolution or Dirmngr network failures or anything with gpg or policykit, you might try updating these packages before doing anything else.
Last edited by nannerpussy (2017-06-11 01:28:47)
Offline
Sorry for the necropost, but I wanted to share that I've been having a similar issue today and stopping, killing, disabling, re-enabling, and restarting the avahi-daemon.service did the trick.
For anyone who's yay installation just started spitting out "gpg: keyserver receive failed: Server indicated a failure problem importing keys" errors, start by attempting the above solution (rebooting the router and the other service mentioned was unnecessary for me). If the problem persists you can start getting deeper into your DNS setup, but restarting a service is a quick thing to test, and low risk if you're trying to debug this with only one internet enabled device.
Confusion is always the most honest response, and I'm a very honest person
Offline
Closing this old thread.
Offline
Pages: 1
Topic closed