gpg: le serveur de clés a échoué: le serveur a indiqué un échec

20

Cette erreur s'est produite lorsque j'ajoute un référentiel gns et que j'essaie d'utiliser cette commande:

#sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F88F6D313016330404F710FC9A2FD067A2E3EF7B

l'erreur est:

gpg: keyserver receive failed: Server indicated a failure

debian apt gpg

— Govinda Chaulagain
source

comme je l'ai expliqué dans ma réponse et mon commentaire sur les downvotes, il est lié au DNS et à la façon dont dirmngr dans la version 2.1.6 a inversé le DNS qui a été supprimé dans la version 2.1.8 je me souviens, mais 2.2.x j'ai installé à partir de Debian testing / unstable (Debian 9 actuelle au moment de l'écriture) a également corrigé ce problème.

— Hvisage

26

Derrière un pare-feu, vous devez utiliser le port 80 au lieu du port par défaut 11371:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9A2FD067A2E3EF7B

Exemple de sortie:

Executing: /tmp/apt-key-gpghome.mTGQWBR2AG/gpg.1.sh --keyserver hkp://keyserver.ubuntu.com:80 --recv 9A2FD067A2E3EF7B
gpg: key 9A2FD067A2E3EF7B: "Launchpad PPA for GNS3" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

— GAD3R
source

Pas le port 11371 ou 80 lié derrière le pare-feu. semble être plutôt lié à la résolution DNS lorsque vous commencez à rechercher sur le net ... '' `` Exécution: /tmp/apt-key-gpghome.imkAGGXMO8/gpg.1.sh --receive-keys --debug-all - vvv --keyserver hkp: //sks1.cryptokeys.org.za: 80 gpg: DBG: chan_3 -> KEYSERVER --clear hkp: //sks1.cryptokeys.org.za: 80 gpg: DBG: chan_3 <- OK gpg : DBG: chan_3 -> KS_GET - 0x9C1384B1168FD423 gpg: DBG: chan_3 <- ERR 167772379 Le serveur a indiqué un échec <Dirmngr> `` `

— Hvisage

7

J'obtiens la même erreur en utilisant dirmngr 2.2.5, et en ajoutant hkp://et :80résolu le problème

— david.libremone

5

Cela a à voir avec DNS et ce que votre serveur DNS fait ou retourne pour dirmngr; (Il a été introduit depuis 2.1.16 avec dirmngr, et j'ai moi-même cherché une solution sur 2.1.6 avec les paquets par défaut de Debian.; (

La bonne réponse est: mise à niveau vers la version 2.2.x ou ultérieure qui a résolu ce problème la première fois.

— Hvisage
source

@StephenKitt ce n'était pas une réponse différente, j'ai donné la raison pour laquelle elle s'est cassée, car l'autre réponse était une réponse totalement inadéquate avec toutes les mauvaises raisons pour lesquelles elle échouait après avoir étudié les versions 2.1.6 sur Debian. Il n'y avait pas vraiment d'autre solution que d'obtenir la dernière version à partir d'une branche testing / unstable pour résoudre ce problème, qui n'était pas lié à HTTP / pare-feu, mais au problème DNS

— Hvisage

Désolé, le commentaire ci-dessus est un commentaire en conserve qui n'était pas tout à fait approprié. Votre réponse modifiée répond effectivement à la question, merci.

— Stephen Kitt

4

Ce problème était vraiment bien pour moi, aucune des solutions proposées ne fonctionnait pour moi jusqu'à ce que je trouve ce post sur reddit. Je suis juste allé ajouter cette ligne à/etc/resolv.conf

serveur de noms 8.8.8.8 # Google dns

vous pouvez essayer n'importe quel autre DNS et voir celui qui vous convient.

— Nafaa Boutefer
source

2

Rencontré le même problème sur Ubuntu 18.04, exécutant dirmngr 2.2.4. Je suis allé avec l'option de vérifier mes paramètres DNS et j'ai ajouté le "nameserver 1.1.1.1" de mon serveur DNS local et le "nameserver 8.8.8.8" de Google. Ensuite, cela a fonctionné.

— user320161
source

La spécification de serveurs DNS explicites dans ma configuration réseau l'a résolu pour moi. Gentoo, en utilisant NetworkManager.

— Pistos

N'oubliez pas non plus Quad9 (9.9.9.9) pour avoir aidé à filtrer les logiciels malveillants / etc. d'une manière de défense de la vie privée;)

— Hvisage

Où ajouter ??? Je viens de passer à DNS 1.1.1.1 et je reçois ce problème

— Trees4theForest

2

Ajoutez 0xavant la clé, pour qu'elle tourne 0xF88F6D313016330404F710FC9A2FD067A2E3EF7B.

Cette réponse de GAD3R l'a résolu pour moi.

— skilowatt
source