apt-uppdateringen misslyckas med NO_PUBKEY efter att ett VPN-arkiv lagts till

NO_PUBKEY och en saknad Release-fil är tillitsfel, inte nätverksfel. Bestäm om du ska fästa leverantörens nyckel med signed-by eller ta bort källan.

apt-källan från din VPN-leverantör har förstört pakethanteraren, och åtgärden är ett beslut, inte ett kommando. NO_PUBKEY, eller ett klagomål på att arkivet saknar Release-fil, betyder att apt har vägrat lita på den källan, så varje senare paketoperation fortsätter att skriva ut samma varning. Själva tunneln är förmodligen oskyldig. Svara på tre frågor om du fortfarande vill ha källan, och den korrekta reparationen följer nästan mekaniskt.

Först: placera felet i rätt kategori

Ett tillitsfel namnger källfilen och antingen den saknade nyckeln eller den saknade Release-filen. Ett transportfel ser annorlunda ut: TLS-certifikatfel, nekad anslutning, tidsgränser eller en proxy som nekar CONNECT. Den skillnaden avgör vilken artikel du läser, eftersom en VPN som fångar TLS eller blockerar leverantörens värd ger transportfel, inte signaturfel.

Kör sudo apt update ensamt och läs slutet, medan du ignorerar de cachade träffarna ovanför. Raden som spelar roll namnger /etc/apt/sources.list.d/ och talar om vilken fil du ska öppna.

Om felet följer på att tunneln kommer upp, testa med tunneln nere och med DNS löst via systemets resolver. En källa som fungerar utan VPN är en fråga om routning eller avlyssning, och ingen mängd nyckelhantering åtgärdar det.

Tre frågor som väljer vägen

Installerar eller uppgraderar du fortfarande paket från den här källan? Om klienten används aktivt, reparera tilliten. Om du installerade klienten en gång och nu importerar en vanlig profil i NetworkManager, är källan död vikt och borttagning är den ärliga reparationen.

För det andra: publicerar leverantören en nyckel och ett fingeravtryck som du kan verifiera utanför kanalen? För det tredje: vem hanterar nycklar på den här värden, distributionen eller du? En källa signerad med en nyckel du inte kan verifiera är en uppdateringsbehörighet du inte bör ge.

Ett nej på den första frågan avslutar analysen. Ett ja på alla tre punkter pekar på signed-by-reparationen, den enda ordning som både fungerar och förblir granskningsbar. Att blanda de två vägarna, genom att behålla källan och tvinga igenom den, är det enda alternativet som är värt att utesluta uttryckligen.

Varför trusted=yes ser ut som en åtgärd och inte är det

Sidan i handboken för sources.list är direkt om saken. Att sätta alternativet Trusted till yes säger åt apt att acceptera källan även när den inte klarar autentiseringen, vilket stänger av apt-secure för det arkivet. Sidan förbehåller det för en lokal kontext, om det används alls.

Det är inte en snävare version av att lita på leverantören. Det tar bort frågan om vem som signerade indexet, så vem som helst som kan svara för det värdnamnet kan ge din maskin paket som installeras som root.

Reparationsväg: hämta nyckeln och fäst den sedan

Hämta nyckeln från platsen som leverantören dokumenterar och packa upp den i en nyckelring som administratören hanterar, och peka sedan arkivraden mot den filen så att tilliten inte kan glida.

  1. Läs raden som misslyckas för att få nyckel-ID och namn på källfilen.
  2. Ladda ner leverantörens ASCII-pansarade nyckel och kör gpg --dearmor till /etc/apt/keyrings/vendor-name.gpg.
  3. Lägg till [signed-by=/etc/apt/keyrings/vendor-name.gpg] i posten i .list-filen för den leverantören.
  4. Kör sudo apt update och bekräfta att källan hämtar ett index i stället för att upprepa signaturvarningen.

Föredra /usr/share/keyrings för nycklar som kommer med ett paket och /etc/apt/keyrings för nycklar som du lägger in själv. Uppdelningen är inte kosmetisk: den talar om för nästa administratör vilka nycklar som överlever en paketuppgradering och vilka som behöver en människa.

Verifiera fingeravtrycket mot leverantörens publicerade värde innan du litar på det. Ett nyckel-ID som klistrats in från ett foruminlägg är hur en maskin börjar lita på en uppdateringsbehörighet som ingen kan namnge.

Borttagningsväg, och varför felet kan komma tillbaka

Titta på vad installationsprogrammet faktiskt skrev, eftersom flera filer kan nämna samma leverantör och en av dem är oftast en kvarbliven kopia.

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

apt läser bara .list och .sources-filer från den katalogen, så en .save eller .distUpgrade-kopia ignoreras redan; att radera den ändå hindrar en senare läsare från att återställa den av misstag. Att ta bort källan avinstallerar ingenting, och apt kan därefter beskriva det installerade VPN-paketet som lokalt installerat eller inte längre tillgängligt, vilket är ett paketstatusmeddelande och inte att tillitsfelet återkommer.

Det återkommande fallet är äldre vägledning som installerade nycklar med apt-key i den globala betrodda ringen. Den vägen är föråldrad, och en utgivningsuppgradering kan lämna nyckeln droppad eller helt enkelt okonsulterad, och det är just därför ett fel som var tyst i ett år dyker upp i veckan du uppgraderar. Kontrollera /etc/apt/trusted.gpg.d/, och flytta sedan tillitsbeslutet till arkivraden där det hör hemma. Om leverantören fortfarande skriver ut apt-key-instruktioner, använd signed-by ändå; det är den ordning som handboken dokumenterar, och den som överlever en uppgradering.

Relaterade artiklar