apt-Update scheitert mit NO_PUBKEY nach dem Hinzufügen eines VPN-Repositorys

Die apt-Quelle Ihres VPN-Anbieters hat Ihren Paketmanager beschädigt, und die Reparatur ist eine Entscheidung, kein Befehl. NO_PUBKEY, oder die Beschwerde, das Repository habe keine Release-Datei, bedeutet, dass apt es abgelehnt hat, dieser Quelle zu vertrauen, sodass jede spätere Paketoperation dieselbe Warnung weiter ausgibt. Der Tunnel selbst ist wahrscheinlich unschuldig. Beantworten Sie drei Fragen dazu, ob Sie diese Quelle noch wollen, und die richtige Reparatur folgt fast mechanisch.

Erstens: Ordnen Sie den Fehler dem richtigen Bereich zu

Ein Vertrauensfehler nennt die Quelldatei und entweder den fehlenden Schlüssel oder die fehlende Release-Datei. Ein Transportfehler sieht anders aus: TLS-Zertifikatsfehler, verweigerte Verbindung, Zeitüberschreitungen oder ein Proxy, der CONNECT verweigert. Diese Unterscheidung entscheidet, welchen Artikel Sie lesen, denn ein VPN, das TLS abfängt oder den Host des Anbieters blockiert, erzeugt Transportfehler, keine Signaturfehler.

Führen Sie sudo apt update allein aus und lesen Sie das Ende, wobei Sie die zwischengespeicherten Treffer darüber ignorieren. Die entscheidende Zeile nennt /etc/apt/sources.list.d/ und sagt Ihnen, welche Datei Sie öffnen müssen.

Wenn der Fehler dem Hochfahren des Tunnels folgt, testen Sie bei abgeschaltetem Tunnel und mit DNS-Auflösung über den System-Resolver. Eine Quelle, die ohne das VPN funktioniert, ist eine Routing- oder Abfangfrage, und keine Schlüsselverwaltung behebt das.

Drei Fragen, die den Weg wählen

Installieren oder aktualisieren Sie noch Pakete aus dieser Quelle? Wenn der Client aktiv genutzt wird, reparieren Sie das Vertrauen. Wenn Sie den Client einmal installiert haben und jetzt ein einfaches Profil in NetworkManager importieren, ist die Quelle Ballast, und das Entfernen ist die ehrliche Reparatur.

Zweitens: Veröffentlicht der Anbieter einen Schlüssel und einen Fingerabdruck, den Sie außerhalb des Kanals prüfen können? Drittens: Wer verwaltet Schlüssel auf diesem Host, die Distribution oder Sie? Eine Quelle, die mit einem Schlüssel signiert ist, den Sie nicht prüfen können, ist eine Update-Autorität, die Sie nicht erteilen sollten.

Ein Nein auf die erste Frage beendet die Analyse. Ein Ja auf alle drei Punkte weist auf die Reparatur per signed-by, die einzige Anordnung, die sowohl funktioniert als auch prüfbar bleibt. Beide Wege zu vermischen, indem man die Quelle behält und sie durchzwingt, ist die eine Option, die man ausdrücklich ausschließen sollte.

Warum trusted=yes wie eine Reparatur aussieht und keine ist

Die Handbuchseite zu sources.list ist darin direkt. Die Option Trusted auf yes zu setzen sagt apt, die Quelle auch dann zu akzeptieren, wenn sie die Authentifizierung nicht besteht, was apt-secure für dieses Repository abschaltet. Die Seite behält das einem lokalen Kontext vor, wenn es überhaupt genutzt wird.

Das ist keine engere Variante des Vertrauens in den Anbieter. Es entfernt die Frage, wer den Index signiert hat, sodass jeder, der für diesen Hostnamen antworten kann, Ihrer Maschine Pakete geben kann, die sich als root installieren.

Reparaturweg: Schlüssel holen, dann festnageln

Holen Sie den Schlüssel von der vom Anbieter dokumentierten Stelle und entschärfen Sie ihn in einen vom Administrator verwalteten Schlüsselbund, dann richten Sie die Repository-Zeile auf diese Datei, damit das Vertrauen nicht wandern kann.

1. Lesen Sie die fehlschlagende Zeile, um die Schlüssel-ID und den Namen der Quelldatei zu erhalten.
2. Laden Sie den ASCII-gepanzerten Schlüssel des Anbieters herunter und führen Sie gpg --dearmor nach /etc/apt/keyrings/vendor-name.gpg aus.
3. Fügen Sie [signed-by=/etc/apt/keyrings/vendor-name.gpg] zum Eintrag in der .list-Datei dieses Anbieters hinzu.
4. Führen Sie sudo apt update aus und bestätigen Sie, dass die Quelle einen Index holt, statt die Signaturwarnung zu wiederholen.

Bevorzugen Sie /usr/share/keyrings für Schlüssel, die mit einem Paket kommen, und /etc/apt/keyrings für Schlüssel, die Sie von Hand ablegen. Die Trennung ist nicht kosmetisch: Sie sagt dem nächsten Administrator, welche Schlüssel ein Paket-Upgrade überleben und welche einen Menschen brauchen.

Prüfen Sie den Fingerabdruck gegen den veröffentlichten Wert des Anbieters, bevor Sie ihm vertrauen. Eine aus einem Forenbeitrag kopierte Schlüssel-ID ist der Weg, auf dem eine Maschine anfängt, einer Update-Autorität zu vertrauen, die niemand benennen kann.

Entfernungsweg und warum der Fehler zurückkommen kann

Sehen Sie nach, was der Installer tatsächlich geschrieben hat, denn mehrere Dateien können denselben Anbieter nennen, und eine davon ist meist eine übrig gebliebene Kopie.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt liest aus diesem Verzeichnis nur .list und .sources-Dateien, eine .save oder .distUpgrade-Kopie wird also ohnehin ignoriert; sie trotzdem zu löschen hindert einen späteren Leser daran, sie versehentlich wiederherzustellen. Das Entfernen der Quelle deinstalliert nichts, und apt kann das installierte VPN-Paket danach als lokal installiert oder nicht mehr verfügbar beschreiben, was eine Paketzustandsmeldung ist und nicht die Rückkehr des Vertrauensfehlers.

Der wiederkehrende Fall ist ältere Anleitung, die Schlüssel mit apt-key in den globalen Vertrauensring installierte. Dieser Weg ist veraltet, und ein Release-Upgrade kann den Schlüssel fallen lassen oder einfach unbeachtet lassen, und genau deshalb erscheint ein Fehler, der ein Jahr lang still war, in der Woche Ihres Upgrades. Prüfen Sie /etc/apt/trusted.gpg.d/, und verschieben Sie dann die Vertrauensentscheidung in die Repository-Zeile, wo sie hingehört. Wenn der Anbieter immer noch apt-key-Anweisungen ausgibt, nutzen Sie trotzdem signed-by; es ist die Anordnung, die das Handbuch dokumentiert, und die, die ein Upgrade übersteht.