Sur Debian, Ubuntu ou une distribution basée sur APT, une mise à jour peut parfois échouer avec une erreur de clé publique manquante.
sudo apt update
Et APT répond avec ce genre de message :
The following signatures couldn't be verified because the public key is not available:
NO_PUBKEY 0123456789ABCDEF
Le problème est simple : APT connaît le dépôt, mais il ne possède pas la clé publique qui permet de vérifier sa signature. Sans cette clé, il refuse de faire confiance aux paquets. C’est agaçant, mais sain. Un gestionnaire de paquets trop confiant, c’est comme un videur de boîte qui laisse entrer tout le monde parce que “ça avait l’air sympa”.
Dans ce guide, nous allons corriger l’erreur NO_PUBKEY proprement, sans utiliser l’ancienne méthode apt-key adv. Aujourd’hui, la bonne pratique consiste à utiliser un fichier de clé dédié dans /etc/apt/keyrings, puis à le référencer avec signed-by dans la source APT.
Pourquoi apt affiche NO_PUBKEY ?
APT vérifie les dépôts avec des signatures cryptographiques. Chaque dépôt publie une signature, et votre système doit posséder la clé publique correspondante pour vérifier que les paquets viennent bien de la source attendue.
L’erreur NO_PUBKEY apparaît généralement dans ces cas :
- vous avez ajouté un dépôt tiers sans importer sa clé ;
- la clé du dépôt a changé ;
- la clé a expiré ;
- vous avez migré vers une version plus récente de Debian ou Ubuntu ;
- une ancienne configuration utilisait
apt-keyoutrusted.gpg; - un fichier
.listn’utilise pas encoresigned-by.
Les dépôts officiels Debian et Ubuntu sont normalement couverts par les paquets de clés de la distribution. Si l’erreur vient d’un dépôt officiel, il faut d’abord vérifier la date système, les sources APT et le paquet de keyring de la distribution. Pour un dépôt tiers, la correction consiste souvent à importer la bonne clé dans un keyring dédié.
Pourquoi ne plus utiliser apt-key adv ?
Vous trouverez encore beaucoup de vieux tutoriels avec cette commande :
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0123456789ABCDEFCode language: CSS (css)
Ne partez plus là-dessus pour une nouvelle configuration.
apt-key est déprécié. L’ancienne méthode ajoutait souvent des clés dans un trousseau global, ce qui signifiait qu’une clé pouvait valider trop largement des dépôts. La méthode moderne limite la confiance : une clé donnée doit valider un dépôt donné, via signed-by.
Concrètement, au lieu de jeter une clé dans le grand panier trusted.gpg, on la range dans un fichier dédié, puis on dit explicitement à APT : “ce dépôt doit être vérifié avec cette clé”. C’est plus propre, plus lisible, et beaucoup moins flou.
Méthode moderne : /etc/apt/keyrings + signed-by
Depuis APT 2.4, /etc/apt/keyrings est l’emplacement recommandé pour les clés locales qui ne sont pas gérées par un paquet système. Les clés fournies par des paquets peuvent plutôt vivre dans /usr/share/keyrings.
La forme moderne ressemble à ceci :
deb [signed-by=/etc/apt/keyrings/example.gpg] https://repo.example.com/debian stable mainCode language: JavaScript (javascript)
Ou, au format deb822 :
Types: deb
URIs: https://repo.example.com/debian
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/example.gpgCode language: HTTP (http)
Le format deb822 utilise des fichiers .sources dans /etc/apt/sources.list.d/. Debian le recommande désormais pour les configurations modernes, notamment parce qu’il est plus explicite et plus facile à lire que les longues lignes deb. :contentReference[oaicite:2]{index=2}
Étape 1 : identifier le dépôt qui pose problème
Lancez d’abord :
sudo apt update
Repérez la ligne qui mentionne NO_PUBKEY, mais aussi l’URL du dépôt concerné. Exemple :
Err: https://repo.example.com/debian stable InRelease
The following signatures couldn't be verified because the public key is not available:
NO_PUBKEY 0123456789ABCDEFCode language: PHP (php)
Ici, le dépôt concerné est :
https://repo.example.com/debianCode language: JavaScript (javascript)
Et la clé manquante est :
0123456789ABCDEF
Ensuite, cherchez le fichier de source correspondant :
Marre des agences qui sous-traitent ?
Avec moi, vous parlez directement au développeur qui fait le travail. Pas d'intermédiaire, pas de promesses creuses. Juste du code propre et un interlocuteur joignable.
Travaillons directement ensemble →grep -R "repo.example.com" /etc/apt/sources.list /etc/apt/sources.list.d/Code language: PHP (php)
Vous devez savoir exactement quel fichier vous allez corriger. Modifier toutes les sources au hasard, c’est efficace seulement pour fabriquer un nouveau problème.
Étape 2 : créer le dossier keyrings
Créez le dossier s’il n’existe pas :
sudo install -d -m 0755 /etc/apt/keyrings
Ce dossier contiendra les clés des dépôts tiers ajoutés localement.
Étape 3 : télécharger la clé officielle du dépôt
La partie importante : téléchargez la clé depuis la documentation officielle du dépôt concerné. Ne récupérez pas une clé au hasard sur un forum, un vieux gist ou une réponse Stack Overflow poussiéreuse.
Exemple avec une clé ASCII officielle :
curl -fsSL https://repo.example.com/key.asc \
| sudo gpg --dearmor -o /etc/apt/keyrings/example.gpgCode language: JavaScript (javascript)
Fixez ensuite les permissions :
sudo chmod 0644 /etc/apt/keyrings/example.gpg
Le fichier doit être lisible par APT. En revanche, il n’a pas besoin d’être modifiable par tout le monde.
Si le fournisseur publie déjà une clé binaire .gpg, vous pouvez la télécharger directement :
curl -fsSL https://repo.example.com/key.gpg \
| sudo tee /etc/apt/keyrings/example.gpg >/dev/null
sudo chmod 0644 /etc/apt/keyrings/example.gpgCode language: JavaScript (javascript)
APT accepte les clés ASCII avec l’extension .asc et les clés binaires avec l’extension .gpg. Pour une compatibilité large, beaucoup de guides convertissent les clés ASCII en .gpg avec gpg --dearmor.
Étape 4 : associer la clé au dépôt avec signed-by
Si votre dépôt est configuré dans un fichier .list, éditez-le :
sudo nano /etc/apt/sources.list.d/example.listCode language: PHP (php)
Ancienne forme :
deb https://repo.example.com/debian stable mainCode language: JavaScript (javascript)
Nouvelle forme :
deb [signed-by=/etc/apt/keyrings/example.gpg] https://repo.example.com/debian stable mainCode language: JavaScript (javascript)
Ensuite, mettez à jour :
sudo apt update
Si l’erreur disparaît, la clé est bien associée au dépôt.
Variante moderne : utiliser un fichier .sources deb822
Sur Debian et Ubuntu récents, vous pouvez aussi utiliser le format deb822 avec un fichier .sources. Il est plus verbeux, mais beaucoup plus lisible.
Créez le fichier :
sudo nano /etc/apt/sources.list.d/example.sourcesCode language: PHP (php)
Ajoutez :
Types: deb
URIs: https://repo.example.com/debian
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/example.gpgCode language: HTTP (http)
Si vous remplacez un ancien fichier .list, désactivez-le ou supprimez-le pour éviter les doublons :
sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabledCode language: PHP (php)
Puis relancez :
sudo apt update
Le format deb822 devient progressivement la voie la plus propre pour les sources APT. Sur Debian Trixie, il est recommandé pour les nouvelles configurations. :contentReference[oaicite:3]{index=3}
Cas pratique : corriger une ancienne source avec apt-key
Imaginons une ancienne documentation qui disait :
wget -qO- https://repo.example.com/key.asc | sudo apt-key add -
echo "deb https://repo.example.com/debian stable main" | sudo tee /etc/apt/sources.list.d/example.listCode language: PHP (php)
La version moderne devient :
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://repo.example.com/key.asc \
| sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
sudo chmod 0644 /etc/apt/keyrings/example.gpg
echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://repo.example.com/debian stable main" \
| sudo tee /etc/apt/sources.list.d/example.list >/dev/null
sudo apt updateCode language: PHP (php)
Cette version limite la clé au dépôt concerné. C’est la vraie amélioration par rapport à l’ancien modèle global.
Vérifier le contenu d’une clé APT
Pour inspecter une clé téléchargée :
gpg --show-keys --with-fingerprint /etc/apt/keyrings/example.gpgCode language: JavaScript (javascript)
Comparez l’empreinte affichée avec celle donnée par la documentation officielle du fournisseur. Ne vous contentez pas d’un ID court. Les IDs courts ont eu leur époque. Elle est finie, comme les fonds de page en gif animé.
Nettoyer les anciennes clés apt-key
Après migration vers signed-by, vous pouvez lister les anciennes clés globales :
sudo apt-key listCode language: PHP (php)
Cette commande peut afficher un avertissement de dépréciation. Ici, elle sert seulement à auditer l’existant.
Pour supprimer une clé obsolète du trousseau global, utilisez son identifiant complet :
sudo apt-key del 0123456789ABCDEF
Ne supprimez pas une clé si vous ne savez pas quel dépôt l’utilise encore. D’abord, migrez le dépôt vers signed-by. Ensuite seulement, nettoyez l’ancien trousseau.
Corriger les dépôts officiels Debian ou Ubuntu
Si l’erreur NO_PUBKEY concerne un dépôt officiel Debian ou Ubuntu, ne téléchargez pas une clé au hasard depuis un serveur de clés. Vérifiez d’abord les paquets de keyring officiels.
Sur Debian :
sudo apt install --reinstall debian-archive-keyring
sudo apt update
Sur Ubuntu :
sudo apt install --reinstall ubuntu-keyring
sudo apt update
Vérifiez aussi que la date système est correcte. Une horloge complètement fausse peut casser la validation TLS ou la validation des signatures.
timedatectl
Si nécessaire :
sudo timedatectl set-ntp trueCode language: JavaScript (javascript)
Désactiver temporairement un dépôt cassé
Si un dépôt tiers bloque toutes vos mises à jour et que vous n’en avez pas besoin immédiatement, vous pouvez le désactiver temporairement.
Avec un fichier .list :
sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt updateCode language: PHP (php)
Avec un fichier .sources, vous pouvez le renommer :
sudo mv /etc/apt/sources.list.d/example.sources /etc/apt/sources.list.d/example.sources.disabled
sudo apt updateCode language: PHP (php)
Ou modifier le fichier deb822 :
Enabled: noCode language: HTTP (http)
C’est souvent la bonne solution si un dépôt tiers abandonné casse vos mises à jour système. Un dépôt mort n’a pas besoin d’être réparé. Il a besoin d’être retiré proprement.
Erreur EXPKEYSIG : clé expirée
Une erreur proche peut ressembler à ceci :
EXPKEYSIG 0123456789ABCDEF Repository Signing Key
Ici, la clé existe, mais elle a expiré. La correction consiste à télécharger la nouvelle clé officielle du fournisseur, puis à remplacer le fichier dans /etc/apt/keyrings.
curl -fsSL https://repo.example.com/key.asc \
| sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
sudo chmod 0644 /etc/apt/keyrings/example.gpg
sudo apt updateCode language: JavaScript (javascript)
Si la source utilise déjà signed-by=/etc/apt/keyrings/example.gpg, vous n’avez normalement pas besoin de modifier le fichier de dépôt. Il suffit de remplacer la clé.
Erreur “Conflicting values set for option Signed-By”
Cette erreur apparaît souvent lorsqu’un même dépôt est déclaré deux fois avec deux clés différentes, ou une fois avec signed-by et une fois sans.
Cherchez les doublons :
grep -R "repo.example.com" /etc/apt/sources.list /etc/apt/sources.list.d/Code language: PHP (php)
Ensuite, gardez une seule source propre. Désactivez les anciennes :
sudo mv /etc/apt/sources.list.d/old-example.list /etc/apt/sources.list.d/old-example.list.disabledCode language: PHP (php)
Puis relancez :
sudo apt update
Script de diagnostic rapide
Voici un petit script pour repérer les sources APT et les fichiers qui contiennent une URL donnée.
#!/usr/bin/env bash
set -euo pipefail
SEARCH="${1:-}"
if [[ -z "${SEARCH}" ]]; then
echo "Usage: $0 <repo-domain-or-keyword>"
exit 1
fi
echo "Recherche dans les sources APT : ${SEARCH}"
echo
grep -Rni -- "${SEARCH}" /etc/apt/sources.list /etc/apt/sources.list.d/ || true
echo
echo "Fichiers keyrings locaux :"
find /etc/apt/keyrings /usr/share/keyrings -maxdepth 1 -type f 2>/dev/null | sortCode language: PHP (php)
Utilisation :
chmod +x apt-source-diagnose.sh
./apt-source-diagnose.sh repo.example.com
Ce script ne modifie rien. Il vous aide seulement à savoir où regarder.
Checklist de résolution
- Lancer
sudo apt updateet noter l’URL du dépôt en erreur. - Identifier le fichier source dans
/etc/apt/sources.list.d/. - Télécharger la clé officielle du dépôt.
- Placer la clé dans
/etc/apt/keyrings. - Référencer la clé avec
signed-byouSigned-By. - Désactiver les anciennes sources en double.
- Relancer
sudo apt update. - Nettoyer les anciennes clés globales seulement après migration.
Pour aller plus loin avec l’administration Linux
Si vous corrigez vos dépôts APT, ces guides complètent bien la maintenance d’un serveur Linux qui héberge des sites WordPress ou des services critiques.
- Mettre à jour Ubuntu vers la dernière version disponible
- Créer une clé SSH pour se connecter sans mot de passe
- Recevoir un email après le redémarrage d’un serveur Linux
- Mettre à jour WordPress en SSH avec WP-CLI
- Installer Nginx, PHP et MariaDB sur Debian
Besoin de remettre votre serveur Linux d’équerre ?
Je peux auditer votre serveur Debian ou Ubuntu, corriger vos dépôts APT, sécuriser vos services et fiabiliser la maintenance de vos sites WordPress ou WooCommerce.
- Audit des dépôts APT, clés GPG, sources
.listet fichiers.sources. - Correction des erreurs
NO_PUBKEY, clés expirées, dépôts cassés et mises à jour bloquées. - Maintenance serveur : SSH, firewall, systemd, logs, sauvegardes et monitoring.
- Administration WordPress avec WP-CLI, migrations, mises à jour et performance.
- Diagnostic Nginx, PHP-FPM, MariaDB, Postfix, DNS et certificats TLS.
Pour repartir sur une base serveur propre et maintenable, contactez-moi ici.
FAQ
Puis-je encore utiliser apt-key adv ?
Évitez-le pour toute nouvelle configuration. apt-key est déprécié. Utilisez plutôt une clé dans /etc/apt/keyrings avec signed-by dans la source APT.
Pourquoi APT refuse-t-il un dépôt sans clé ?
Parce qu’il ne peut pas vérifier l’origine des paquets. La clé publique permet de valider la signature du dépôt et de limiter les risques d’installation de paquets non fiables.
Où placer les clés APT aujourd’hui ?
Pour les clés locales de dépôts tiers, utilisez /etc/apt/keyrings. Pour les clés installées par des paquets système, on trouve souvent /usr/share/keyrings.
Quelle différence entre .list et .sources ?
Les fichiers .list utilisent l’ancien format sur une ligne. Les fichiers .sources utilisent le format deb822, plus lisible et plus explicite, avec des champs comme URIs, Suites, Components et Signed-By.
Que faire si la clé est expirée ?
Téléchargez la nouvelle clé officielle du dépôt, remplacez le fichier dans /etc/apt/keyrings, puis relancez sudo apt update.
Puis-je ignorer l’erreur NO_PUBKEY ?
Non. Si APT ne peut pas vérifier un dépôt, corrigez la clé ou désactivez le dépôt. Ne contournez pas la vérification des signatures pour gagner deux minutes.
Conclusion
L’erreur NO_PUBKEY indique qu’APT ne possède pas la clé publique nécessaire pour vérifier un dépôt. L’ancienne correction avec apt-key adv a fait son temps. Elle doit être remplacée par une configuration plus précise avec /etc/apt/keyrings et signed-by.
La bonne méthode est simple : identifier le dépôt, télécharger sa clé officielle, la placer dans un keyring dédié, associer cette clé à la source APT, puis relancer apt update.
APT est strict parce qu’il installe des logiciels avec des privilèges élevés. Quand il refuse une clé manquante, il ne fait pas son difficile. Il fait son travail.
Sources
Un projet WordPress en tête ?
Vous avez une idée claire de ce que vous voulez, mais pas les ressources en interne pour le faire bien. Je développe des sites et extensions WordPress sur-mesure — sans délais à rallonge ni mauvaises surprises.
Décrivez-moi votre projet →
Mise à jour de l’article avec le script Bash.