apt-update mislukt met NO_PUBKEY na het toevoegen van een VPN-repository

De apt-bron van uw VPN-leverancier heeft uw pakketbeheerder stukgemaakt, en de oplossing is een beslissing, geen commando. NO_PUBKEY, of een klacht dat de repository geen Release-bestand heeft, betekent dat apt heeft geweigerd die bron te vertrouwen, zodat elke latere pakketbewerking dezelfde waarschuwing blijft afdrukken. De tunnel zelf is vermoedelijk onschuldig. Beantwoord drie vragen over of u die bron nog wilt, en de juiste reparatie volgt bijna mechanisch.

Ten eerste: plaats de fout in de juiste categorie

Een vertrouwensfout noemt het bronbestand en ofwel de ontbrekende sleutel ofwel het ontbrekende Release-bestand. Een transportfout ziet er anders uit: TLS-certificaaffouten, geweigerde verbinding, time-outs of een proxy die CONNECT weigert. Dat onderscheid bepaalt welk artikel u leest, want een VPN die TLS onderschept of de host van de leverancier blokkeert, levert transportfouten op, geen handtekeningfouten.

Voer sudo apt update alleen uit en lees het einde, terwijl u de gecachte treffers erboven negeert. De regel die ertoe doet, noemt /etc/apt/sources.list.d/ en vertelt u welk bestand u moet openen.

Als de fout volgt op het opkomen van de tunnel, test dan met de tunnel neer en met DNS opgelost via de resolver van het systeem. Een bron die zonder de VPN werkt, is een routerings- of onderscheppingsvraag, en geen enkele sleutelbeheer lost dat op.

Drie vragen die het pad kiezen

Installeert of upgradet u nog pakketten uit deze bron? Als de client actief wordt gebruikt, repareer dan het vertrouwen. Als u de client één keer hebt geïnstalleerd en nu een gewoon profiel in NetworkManager importeert, is de bron dode last en is verwijderen de eerlijke reparatie.

Ten tweede: publiceert de leverancier een sleutel en een vingerafdruk die u buiten het kanaal kunt verifiëren? Ten derde: wie beheert sleutels op deze host, de distributie of u? Een bron die is ondertekend met een sleutel die u niet kunt verifiëren, is een updatedwang die u niet zou moeten geven.

Nee op de eerste vraag beëindigt de analyse. Ja op alle drie de punten wijst op de signed-by-reparatie, de enige regeling die zowel werkt als controleerbaar blijft. De twee wegen vermengen, door de bron te houden en erdoorheen te dwingen, is de enige optie die het waard is om uitdrukkelijk uit te sluiten.

Waarom trusted=yes op een oplossing lijkt en het niet is

De pagina in de handleiding van sources.list is er direct over. De optie Trusted op yes zetten zegt apt de bron te accepteren ook als de authenticatie mislukt, wat apt-secure voor die repository uitschakelt. De pagina houdt dat voor een lokale context, als het al wordt gebruikt.

Dat is geen engere versie van vertrouwen in de leverancier. Het haalt de vraag weg wie de index heeft ondertekend, dus iedereen die voor die hostnaam kan antwoorden, kan uw machine pakketten geven die als root worden geïnstalleerd.

Reparatieroute: haal de sleutel en zet hem dan vast

Haal de sleutel op de plek die de leverancier documenteert en pak hem uit in een sleutelbos die door de beheerder wordt beheerd, en wijs dan de repository-regel naar dat bestand zodat het vertrouwen niet kan afdrijven.

1. Lees de regel die mislukt om de sleutel-ID en de naam van het bronbestand te krijgen.
2. Download de ASCII-gepantserde sleutel van de leverancier en voer gpg --dearmor uit naar /etc/apt/keyrings/vendor-name.gpg.
3. Voeg [signed-by=/etc/apt/keyrings/vendor-name.gpg] toe aan de vermelding in het .list-bestand van die leverancier.
4. Voer sudo apt update uit en bevestig dat de bron een index ophaalt in plaats van de handtekeningwaarschuwing te herhalen.

Geef de voorkeur aan /usr/share/keyrings voor sleutels die met een pakket meekomen en /etc/apt/keyrings voor sleutels die u zelf plaatst. De splitsing is niet cosmetisch: ze vertelt de volgende beheerder welke sleutels een pakketupgrade overleven en welke een mens nodig hebben.

Verifieer de vingerafdruk tegen de gepubliceerde waarde van de leverancier voordat u erop vertrouwt. Een sleutel-ID die uit een forumbericht is geplakt, is de manier waarop een machine een updatedwang gaat vertrouwen die niemand kan benoemen.

Verwijdertraject, en waarom de fout kan terugkomen

Kijk wat het installatieprogramma werkelijk heeft geschreven, want meerdere bestanden kunnen dezelfde leverancier noemen en een daarvan is meestal een achtergebleven kopie.

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

apt leest uit die map alleen .list en .sources-bestanden, dus een .save of .distUpgrade-kopie wordt al genegeerd; hem toch verwijderen voorkomt dat een latere lezer hem per ongeluk herstelt. De bron verwijderen deinstalleert niets, en apt kan het geïnstalleerde VPN-pakket daarna beschrijven als lokaal geïnstalleerd of niet meer beschikbaar, wat een pakketstatusmelding is en niet de terugkeer van de vertrouwensfout.

Het terugkerende geval is oudere aanwijzing die sleutels met apt-key in de globale vertrouwensring installeerde. Dat pad is verouderd, en een release-upgrade kan de sleutel laten vallen of simpelweg ongeraadpleegd laten, en dat is precies waarom een fout die een jaar stil was, verschijnt in de week dat u upgradet. Controleer /etc/apt/trusted.gpg.d/, en verplaats dan de vertrouwensbeslissing naar de repository-regel waar die hoort. Als de leverancier nog steeds apt-key-instructies afdrukt, gebruik dan toch signed-by; het is de regeling die de handleiding documenteert, en degene die een upgrade overleeft.