Suport technique et veille technologique

Just Another GNU/Linux User’s Blog  -  Gestion de paquets avec APT : Récupérer une clé manquante sur un réseau filtré

 -  Septembre 2016 - 

Introduction

Par défaut, APT (Advanced Packaging Tool) essaye de vérifier la signature des paquets en utilisant des clés GPG, la plupart du temps ça fonctionne très bien, mais parfois il manque certaines clés

Les différents paquets GNU/Linux disponibles dans les dépôts sont cryptographiquement signés et on doit récupérer les clés publiques pour les différents dépôts/projets afin de vérifier les signatures (et donc l’intégrité, tant que la clé est fiable) des paquets GNU/Linux, ici Debian. Tout ça se passe grosso modo de façon similaire à la vérification de les signatures cryptographiques pour les email (OpenPGP), à savoir le paquet est signé avec une clé PGP privée, et la clé publique liée à cette clé privée permet de vérifier si la signature matche ou pas, sauf que pour les paquets GNU/Linux (qui sont signés), la vérification est totalement automatisée par APT, enfin presque… parfois il faut une intervention humaine quand même, et généralement ça veut dire qu’il y a un problème… le cas le plus commun étant la clé manquante

En lançant une re-synchronisation du fichier d’index des paquets disponibles, avec apt[-get] update [1], on obtient par fois l’erreur ci-dessous, ce qui arrive par exemple quand on rajoute un dépôt sans récupérer la clé correspondante, ou qu’on installe un paquet par un fichier packagename.deb avec dpkg -i, et que ce paquet signé, rajoute ses propres dépôts dans /etc/apt/sources.list.d/<whatever>.

W: GPG error: <repo_url> <some Realease>: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY <LongID>
W: There is no public key available for the following key IDs: <LongID>

Ces warnings sont dûs au fait qu’un (ou plusieurs) des paquets disponibles dans les dépôts, a (ont) une signature qui ne peut pas être vérifiée, car la clé publique permettant de vérifier cette signature n’a pas été ajoutée au système, le système considère donc qu’il ne peut pas faire confiance à ce paquet, sauf si l’adminsys importe la clé permettant de vérifier la signature. Importer une clé revient à dire au système « Je fais confiance au détenteur de cette clé », ce qu’il veut bien sur dire qu’il faut pas importer les clés au hasard ou de sources douteuses (pareil pour les dépôts de paquets bien entendu… )

Ces warnings donnent 3 informations utiles pour qu’on puisse débugger l’erreur
– <repo_url> soit l’adresse du dépôt du est issue le paquet
– <some Release> pour identifier la version de distro à la quelle est destiné le paquet, ça peut par exemple être “testing Release” dans le cas de Debian Testing
– <LongID> soit l’identifiant de la clé GPG au format long, tel que c’est affiché dans les WARNINGS d’APT (16 caractères en hexadécimal), la syntaxe en ShortID (8 caractères) à bannir pour des raisons de sécurité (ID usurpable)

Mais pour l’objet de cet article, on va surtout se concentrer <LongID> qui nous permettra d’importer la bonne clé, normalement on résout le problème avec la commande suivante

$ sudo apt-key adv --keyserver <keyserverdomainname.tld> --recv-key <LongID>
[sudo] password for $USER:

Où <keyserverdomainname.tld> est est l’adresse du serveur interrogé pour chercher la clé, et <LongID> est un est identifiant de la clé GPG manquante (qui sera indiqué dans le message d’erreur de APT). Les options utilisés dans cette commande sont
– adv pour transmettre des options à GPG pour récupérer
la clé depuis un serveur de clés publiques OpenPGP
– –keyserver pour indiquer l’adresse du serveur de clés à interroger, sachant que normalement, une clé publique PGP, une fois publiée sur un serveur de clés, est dupliquée sur tous les serveurs de clés OpenPGP
– –recv-key qui permet de récupérer la clé

Ce qui donnerai, en prenant le Long ID de ma propre clé GPG [2], la commande ci-dessous

$ sudo apt-key adv --keyserver keys.gnupg.net --recv-key FB29EFFE356CDCDE

Oui, mais c’est pas passe-partout

Le problème, c’est que sur certains réseaux, notamment dans les établissements scolaires, en entreprise, ou encore sur les AP WiFi publics et sur l’accès minitel 2.0 mobile (UMTS/HSPA/HSPA+/LTE…), beaucoup de ports sont filtrés, on peut généralement sortir qu’en port 80, et éventuellement le port 443 (plus quelques autres ports, comme ceux utilisés par IRC et/ou XMPP, selon le réseau)

Dans ce cas, ça va juste coincer, on a généralement droit à un temps de chargement très long, jusqu’au timeout, car le protocole de récupération de clés OpenPGP utilise le port 11371.

$ cat /etc/services | grep 11371
hkp        11371/tcp     # OpenPGP HTTP Keyserver
hkp        11371/udp

Et même s’il existe des exceptions (permissions spécifiques sur les réseaux d’établissement scolaires/en entreprises en fonction de la catégorie des utilisateurs), ça concerne en général que des services/ports moins obscures que hkp/le port 11371 (par exemple git), donc dans tous les cas, il faudrai trouver une autre solution.

La solution

Certains serveurs de clés publiques peuvent aussi utiliser le port 80, donc on peut tenter la commande précédente en rajoutant :80 à la fin de l’URL du dépôt pour préciser qu’on veut se connecter sur le port 80, la commande devient

$ sudo apt-key adv --keyserver <keyserverdomainname.tld>:80 --recv-key <LongID>

Soit par exemple (en prenant toujours le Long ID de ma clé GPG)

$ sudo apt-key adv --keyserver keys.gnupg.net:80 --recv-key FB29EFFE356CDCDE

Mais là aussi, ça fonctionne pas à tous les coups, la solution ultime consiste à aller chercher la clé en passant par une interface web, par exemple sur pgp.mit.edu ou keys.gnupg.net, il suffit d’entrer 0x<LongID> dans le champs de recherche, toujours en remplaçant <LongID> par l’ID (16 caractères) de la clé recherchée, par exemple 0xFB29EFFE356CDCDE, afin de récupérer le format ascii-armored de la clé, qu’on va copier dans un fichier texte, par exemple key.asc ou key.txt

Pour obtenir le format ascii-armored
– Sur keys.gnupg.net, on peut directement choisir “Retrieve ascii-armored keys” avant de lancer la recherche
– Sur pgp.mit.edu, une fois la recherche lancée, on clique sur l’ID, pas sur le nom de la clé (pour accéder au format ascii-armored directement (plusieurs clés avec des ID différents peuvent avoir le même nom et faire partie  du même porte clé donc autant aller au plus direct/simple)

Il suffit de tout sélectionner et de faire un click milieu dans son éditeur de texte favoris (pour rappel sélection = copier et click du milieu = coller)

Puis on importe la clé avec l’une des deux commandes suivantes (en fonction du nom du fichier qui contient la clé)

$ sudo apt-key add key.asc

$ sudo apt-key add key.txt

On relance une re-synchronisation du fichier d’index, et la il y a plus les Warnings liés aux clés GPG manquantes

$ apt[-get] update

Enjoy

Notes
[1] : apt est la nouvelle syntaxe d’apt-{get|cache}, l’unification des deux commandes est en cours, mais la nouvelle syntaxe n’a pas encore totalement remplacée l’ancienne, par exemple on passe encore par “apt-cache policy” pour vérifier la priorité des sources, car il n’y pas de “apt policy”… mais il faut savoir qu’une nouvelle syntaxe simplifiée/raccourcie, existe
[2] : J’ai utilisé l’ID de ma clé GPG juste à titre d’exemple, pour clarifier la syntaxe. Cette clé sert a chiffrer les emails qui me sont adressés, pas signer des paquets GNU/Linux

par /dev/null