Corriger l’erreur APT NO_PUBKEY sans apt-key

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-key ou trusted.gpg ;
  • un fichier .list n’utilise pas encore signed-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 :

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 update et 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-by ou Signed-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.

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 .list et 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

Demandez à l'IA son opinion
Gravatar for Matt Biscay

Je suis Matt Biscay, développeur WordPress & WooCommerce certifié chez Codeable, administrateur système et enseignant.

J’aide les entreprises à créer, optimiser et fiabiliser leurs sites WordPress avec une approche technique propre : performance, sécurité, maintenance, développement sur mesure et résolution de problèmes complexes.

Sur Skyminds, je partage des tutoriels WordPress, WooCommerce, Linux et administration système, avec des solutions testées sur des cas réels et pensées pour durer.

Découvrez mes services WordPress et WooCommerce.

1 pensée sur “Corriger l’erreur APT NO_PUBKEY sans apt-key”

Opinions