| View previous topic :: View next topic |
| Author |
Message |
HeXiLeD
Veteran
Joined: 20 Aug 2005
Posts: 1159
Location: Online
|
 Posted: Wed Feb 19, 2020 6:52 pm Post subject: keyserver refresh failed: Permission denied [SOLVED] |
 |
|
Problem:
# eix-sync or emerge –sync gpg: keyserver refresh failed: Permission denied
| Code: | * Running emerge --sync
>>> Syncing repository 'gentoo' into '/home/mike/HD3/portage/ebuilds'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
* Refreshing keys via WKD ... [ !! ]
* Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: keyserver refresh failed: Permission denied
OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: keyserver refresh failed: Permission denied |
Environment:
1: Fresh new gentoo LUKS install (no lvm)
1: Old gentoo install (no luks)
Relevant urls:
https://keys.gentoo.org
https://wiki.gentoo.org/wiki/Project:Gentoo-keys
https://wiki.gentoo.org/wiki/Project:Gentoo-keys
https://www.gentoo.org/downloads/signatures
https://wiki.gentoo.org/wiki/Portage_Security
https://wiki.gentoo.org/wiki/Project:Gentoo-keys/gkeys
https://sks-keyservers.net/overview-of-pools.php
Seems that lots of people have similar problems which may or many not be related to my problem.
My problem was different
Archives
https://archives.gentoo.org/gentoo-user/message/51a656a9ba2e35b4278814869f23f535
Refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
https://forums.gentoo.org/viewtopic-t-1082756.html
Portage refreshing keys
https://forums.gentoo.org/viewtopic-t-1084760.html
This type of problem seems to happen to a lot of people.
If you suspect .gnupg -ld is not owned by root
| Code: | | drwx------ 3 root root 4096 Feb 19 11:39 /root/.gnupg |
In addition you can always:
| Code: | | # rm -rf /root/.gnupg |
Other questions:
| Quote: | | iamben: Does "gpg --refresh-keys" on command-line give errors? |
I my case no output.
If you suspect the clock
https://wiki.gentoo.org/wiki/System_time
# date
| Code: | | Wed 19 Feb 2020 12:53:29 PM EST |
# date -u
| Code: | | Wed 19 Feb 2020 05:53:31 PM UTC |
# hwclock
| Code: | | 2020-02-19 12:53:39.323699-05:00 |
# cat /etc/conf.d/hwclock
| Code: | clock="local"
clock_hctosys="YES"
clock_systohc="YES"
clock_args="" |
If you suspect from your ip/connection:
For a moment I though that maybe my ip was blacklisted.
I tried
| Code: | - Paid vpns
- Private vpn
- Tor
- Public network wifi |
If you suspect from the keyservers do some trouble shooting and try to sync individual keys:
https://www.gentoo.org/downloads/signatures
| Code: | | gpg --keyserver hkps://keys.gentoo.org --recv-keys 18F703D702B1B9591373148C55D3238EC050396E |
Still no answers?
Add verbose to it and debug:
# gpg -v --debug-level=10 --keyserver hkps://keys.gentoo.org --recv-keys 2C13823B8237310FA213034930D132FF0FF50EEB
| Code: | gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /root/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.2.17 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.2.17
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://keys.gentoo.org
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0x2C13823B8237310FA213034930D132FF0FF50EEB
gpg: DBG: chan_3 <- ERR 167804929 Permission denied <Dirmngr>
gpg: keyserver receive failed: Permission denied
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] 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: 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/65536 bytes in 0 blocks
|
gpg: DBG: chan_3 <- ERR 167804929 Permission denied <Dirmngr>
If you suspect from your home network connection and or operating system I tried:
- Debian inside virtualbox hosted on gentoo and was able to import keys. Therefore, the problem was not with my network:
# gpg --keyserver hkps://keys.gentoo.org --recv-keys 18F703D702B1B9591373148C55D3238EC050396E
| Code: | gpg: key 55D3238EC050396E: "Gentoo Authority Key L2 for Services <openpgp-auth+l2-srv@gentoo.org>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1 |
If you suspect problems with the keyserver you can check other distro and or keyservers:
| Code: | # gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 94558F59[/b]
gpg: key 082CCEDF94558F59: "Spotify Public Repository Signing Key <operations@spotify.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1 |
[b]# gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 94558F59
If you suspect problems with the keyserver url port (80 vs 443) change the port and try. However in my case the port was not that relevant.
443 worked with virtual box debian but not the gentoo host which was weird
| Code: | gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 94558F59
gpg --keyserver hkp://keyserver.ubuntu.com:443 --recv-keys 94558F59
gpg --keyserver hkps://keys.gentoo.org:80 --recv-keys 18F703D702B1B9591373148C55D3238EC050396E
gpg --keyserver hkps://keys.gentoo.org:443 --recv-keys 18F703D702B1B9591373148C55D3238EC050396E
gpg: WARNING: Tor is not properly configured
gpg: keyserver receive failed: Permission denied
|
TOR?
WHY? Is tor even being pulled here?
| Quote: | Cy1: Could there be something like an LD_PRELOAD trying to transparently pipe everything through Tor?
Tor was were my problem was. |
My connection was failing on port 443.
| Quote: | | spare | if your connection fails out of port 443 gnupg defaults to 127.0.0.1 9050 |
Why was gpg using tor? To prevent what?
| Quote: | | Spare: anyone that has any incentive or gain to doxx private communications the list is pretty long |
# torsocks off
| Code: | | Tor mode deactivated. Command will NOT go through Tor anymore. |
Problem remained the same.
Then I tailed my tor log:
# tail -f /var/log/tor/tor_relay.log
| Code: | [warn] Your application (using socks5 to port 53) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see https://wiki.torproject.org/TheOnionRouter/TorFAQ#SOCKSAndDNS. Rejecting.
|
Dirmngr was getting Permission denied because of it’s insecure tor usage.
https://trac.torproject.org/projects/tor/wiki/doc/Preventing_Tor_DNS_Leaks
https://2019.www.torproject.org/docs/faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks
Problem was found
https://2019.www.torproject.org/docs/faq.html.en#SocksAndDNS
# cat /etc/tor/torrc| grep Socks
| Code: | SafeSocks 1
TestSocks 1
SocksPort 9050 |
WHY? Are we using tor by default, WITHOUT any configuration that we can edit to change options?? WHY are we using TOR without any information about using TOR and which gremlin thought that is is a good idea to use gpg through TOR in a way that may leak information?  
I spent hours trying to solve this problem as well as other people.
I am all up to support and use TOR everywhere but PROPERLY.
Why are we doing this type of stuff? What is the logical and rational explanation to do these ideas?
Turning SafeSocks 1 to 0 SOLVED my problem but this is not desirable..
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244 |
|
| Back to top |
|
 |
freke
l33t
Joined: 23 Jan 2003
Posts: 992
Location: Somewhere in Denmark
|
| Posted: Wed Feb 19, 2020 7:20 pm Post subject: |
|
|
| I don't know why it uses Tor for you - it doesn't seem to on my system with net-vpn/tor-0.4.2.5 |
|
| Back to top |
|
|
HeXiLeD
Veteran
Joined: 20 Aug 2005
Posts: 1159
Location: Online
|
| Posted: Wed Feb 19, 2020 8:03 pm Post subject: |
|
|
If it is relevant i did a few more tests and I can for sure say that I never set 'use-tor' in the dirmngr.conf
https://wiki.gentoo.org/wiki/Tor#app-crypt.2Fgnupg
| Code: | | rm /var/lib/gentoo/gkeys/keyrings/gentoo/release/dirmngr.conf |
| Code: | | touch /var/lib/gentoo/gkeys/keyrings/gentoo/release/dirmngr.conf |
File is empty. There is no 'use-tor' to the dirmngr.conf
# cat /etc/tor/torrc
#
| Code: | # Minimal torrc so tor will work out of the box
#
RunAsDaemon 1
User tor
PIDFile /run/tor/tor.pid
Log notice file /var/log/tor/tor_relay.log
DataDirectory /var/lib/tor/data
DataDirectoryGroupReadable 0
SafeSocks 1
TestSocks 1
SocksPort 9050
NumCPUs 12 |
# tail -f /var/log/tor/tor_relay.log
| Code: | | [warn] Your application (using socks5 to port 53) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see https://wiki.torproject.org/TheOnionRouter/TorFAQ#SOCKSAndDNS. Rejecting. |
More details:
man dirmngr.conf
| Quote: | --use-tor
--no-use-tor
The option --use-tor switches Dirmngr and thus GnuPG into ``Tor mode'' to route all network access via Tor (an anonymity network). Certain other features are disabled in this mode.
The effect of --use-tor cannot be overridden by any other command or even by reloading dirmngr. The use of --no-use-tor disables the use of Tor. The default is to use Tor if it is
available on startup or after reloading dirmngr. |
The default is to use Tor if it is available on startup or after reloading dirmngr. and if torrc uses safesocks 1, then we have the source of this issue.
Anyway, the problem is SOLVED, but if it is going to use tor, then it should use it with safesocks
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
Last edited by HeXiLeD on Sat Feb 22, 2020 3:18 am; edited 1 time in total |
|
| Back to top |
|
|
HeXiLeD
Veteran
Joined: 20 Aug 2005
Posts: 1159
Location: Online
|
| Posted: Sat Feb 22, 2020 3:16 am Post subject: |
|
|
After more testing:
| Quote: | --use-tor
--no-use-tor
The option --use-tor switches Dirmngr and thus GnuPG into ``Tor mode'' to route all network access via Tor (an anonymity network). Certain other features are disabled in this mode.
The effect of --use-tor cannot be overridden by any other command or even by reloading dirmngr. The use of --no-use-tor disables the use of Tor. The default is to use Tor if it is available on startup or after reloading dirmngr. mode.
|
# cat /etc/tor/torrc| grep Socks
| Code: | SafeSocks 1
TestSocks 1
SocksPort 9050 |
killall -9 dirmngr
# ps aux | grep dirmngr
| Code: | | root 27948 0.0 0.0 7928 836 pts/2 S+ 22:08 0:00 grep --colour=auto dirmngr |
With empty file:
| Code: | | /var/lib/gentoo/gkeys/keyrings/gentoo/release/dirmngr.conf |
With --no-use-tor or no-use-tor inside:
# cat /var/lib/gentoo/gkeys/keyrings/gentoo/release/dirmngr.conf
# cat /var/lib/gentoo/gkeys/keyrings/gentoo/release/dirmngr.conf
Result:
# gpg --keyserver hkps://keys.gentoo.org:80 --recv-keys 18F703D702B1B9591373148C55D3238EC050396E
| Code: | gpg: WARNING: Tor is not properly configured
gpg: keyserver receive failed: Permission denied
|
# gpg --keyserver hkps://keys.gentoo.org:443 --recv-keys 18F703D702B1B9591373148C55D3238EC050396E
| Code: | gpg: WARNING: Tor is not properly configured
gpg: keyserver receive failed: Permission denied |
It always default to try to use tor.
This needs to be fixed!
app-crypt/gnupg 2.2.17 and 2.2.19
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244 |
|
| Back to top |
|
|
Zwisel
n00b
Joined: 17 Sep 2005
Posts: 24
Location: switzerland
|
| Posted: Fri Aug 14, 2020 7:25 pm Post subject: |
|
|
as of today, I have the same issue when using eix-sync:
* Starte emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
* Refreshing keys via WKD ... [ !! ]
* Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP keyring refresh failed:
gpg: 4 Schlüssel werden per hkps://keys.gentoo.org aktualisiert
gpg: Refresh vom Schlüsselserver fehlgeschlagen: Kein Schlüsselserver verfügbar
OpenPGP keyring refresh failed:
gpg: 4 Schlüssel werden per hkps://keys.gentoo.org aktualisiert
gpg: Refresh vom Schlüsselserver fehlgeschlagen: Kein Schlüsselserver verfügbar
etc etc
Is there a solution? |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Sun Nov 29, 2020 12:02 pm Post subject: |
|
|
Hello!
I have this issue too right now on all my systems and do not know the cause. And i will not end up to disable the Tree Verification without a key. Because it is more likely to spread ransomware on the systems over local mirror or poisoned tree.
Here are my thoughts, just because i do not know what can solved this. If i know i will update my post the next days. Will not Sync to often to prevent a time ban.
My Systemd is over 238 and i rebuild gnutls and this did not work for me.
Since i have an old Gentoo, i updated the Portage location to the mid 2019th default one: /var/db/repos/gentoo on some systems. And when you done that too take care to configure /etc/portage/repos.conf/gentoo.conf too.
But for a clean cut, i followed the Portage Secure Wiki, and install
app-crypt/openpgp-keys-gentoo-release and clean my Porage files/directory to sync a fresh one.
The Gentoo Wiki (Portage Sync) suggest to copy the example gentoo.conf from /usr/share/portage/config/repos.conf
Just have a Look at the file:
| Code: | $ cat /usr/share/portage/config/repos.conf
[DEFAULT]
main-repo = gentoo
[gentoo]
location = /usr/portage
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
auto-sync = yes
sync-rsync-verify-jobs = 1
sync-rsync-verify-metamanifest = yes
sync-rsync-verify-max-age = 24
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
sync-openpgp-keyserver = hkps://keys.gentoo.org
sync-openpgp-key-refresh-retry-count = 40
sync-openpgp-key-refresh-retry-overall-timeout = 1200
sync-openpgp-key-refresh-retry-delay-exp-base = 2
sync-openpgp-key-refresh-retry-delay-max = 60
sync-openpgp-key-refresh-retry-delay-mult = 4
sync-webrsync-verify-signature = yes |
This is on my system i did not moved away from /usr/portage to /var/db/repos/gentoo and maybe the Line:
| Code: | | location = /usr/portage |
is different.
You can easy ask portage for your location:
| Code: | | $ portageq get_repo_path / gentoo |
I think that my portage got this error...
| Code: | OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: keyserver refresh failed: General error |
because i updated /etc/portage/repos.conf/gentoo.conf and had a wrong location setting. First because on different Systems i use different locations for my portage (on different systems) and after the portage update, and python update, i done some copy config files from the internet/this forum. Which made it worse. ;D
It may be that the verification process got broken due to gnutls or python update in the time between too. However after the migration to python 3.7 i still had this issue and i suppose it was a misconfiguration.
Now this works fine:
| Code: | | # gemato verify -K /usr/share/openpgp-keys/gentoo-release.asc $(portageq get_repo_path / gentoo) |
I am not sure right know but i think the issue for some General error Key refresh is, that the emerge --sync command will look for the default location, and do not find the portage files to compare the signatures?
Now it is working again on one system:
| Code: | # gemato verify -K /usr/share/openpgp-keys/gentoo-release.asc $(portageq get_repo_path / gentoo)
INFO:root:Refreshing keys...
INFO:root:Keys refreshed.
INFO:root:Manifest timestamp: 2020-11-29 08:38:42 UTC
INFO:root:Valid OpenPGP signature found:
INFO:root:- primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
INFO:root:- subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
INFO:root:- timestamp: 2020-11-29 08:38:42 UTC
INFO:root:Verifying /usr/portage...
INFO:root:/usr/portage verified in 11.46 seconds |
Edit: No, did not work. This yes...
| Code: | # gemato verify -K /usr/share/openpgp-keys/gentoo-release.asc $(portageq get_repo_path / gentoo)
INFO:root:Refreshing keys...
INFO:root:Keys refreshed.
INFO:root:Manifest timestamp: 2020-11-29 08:38:42 UTC
INFO:root:Valid OpenPGP signature found:
INFO:root:- primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
INFO:root:- subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
INFO:root:- timestamp: 2020-11-29 08:38:42 UTC
INFO:root:Verifying /usr/portage...
INFO:root:/usr/portage verified in 12.02 seconds |
and this too:
| Code: | | gpg --keyserver hkps://keys.gentoo.org --search-keys "Gentoo Portage Snapshot Signing Key" |
But not this:
| Code: | # emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
* Refreshing keys via WKD ... [ !! ]
* Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: keyserver refresh failed: No data |
So i will stay with gemato after every syncronisation and without active sync-rsync-verify-metamanifest. |
|
| Back to top |
|
|
|
Portage & Programming
