apt-oppdatering feilar med NO_PUBKEY etter at eit VPN-lager er lagt til

apt-kjelda til VPN-leverandøren din har øydelagt pakkehandsamaren, og rettinga er ei avgjerd, ikkje ein kommando. NO_PUBKEY, eller ei klage på at lageret ikkje har noko Release-fil, betyr at apt har nekta å stole på den kjelda, slik at kvar seinare pakkeoperasjon held fram med å skrive ut den same åtvaringa. Sjølve tunnelen er truleg uskuldig. Svar på tre spørsmål om du framleis vil ha den kjelda, og den rette reparasjonen følgjer nesten mekanisk.

Fyrst: set feilen i rett kategori

Ein tillitsfeil namngir kjeldepila og anten den manglande nøkkelen eller den fråverande Release-fila. Ein transportfeil ser annleis ut: TLS-sertifikatfeil, nekta tilkopling, tidsavbrot eller ein proxy som nektar CONNECT. Den skilnaden avgjer kva artikkel du les, fordi ein VPN som fangar TLS eller blokkerer verten til leverandøren, gjev transportfeil, ikkje signaturfeil.

Køyr sudo apt update åleine og les slutten, medan du ignorerer dei bufra treffa over. Linja som betyr noko, namngir /etc/apt/sources.list.d/ og fortel deg kva fil du skal opne.

Viss feilen følgjer at tunnelen kjem opp, test med tunnelen nede og med DNS slått opp via resolvaren til systemet. Ei kjelde som verkar utan VPN-en, er eit rutings- eller avlyttingsspørsmål, og inga mengd nøkkelhandsaming rettar det.

Tre spørsmål som vel vegen

Installerer eller oppgraderer du framleis pakkar frå denne kjelda? Viss klienten er i aktiv bruk, reparer tilliten. Viss du installerte klienten éin gong og no importerer ein vanleg profil i NetworkManager, er kjelda daud vekt, og fjerning er den ærlege rettinga.

For det andre: publiserer leverandøren ein nøkkel og eit fingeravtrykk du kan stadfeste utanfor kanalen? For det tredje: kven styrer nøklar på denne verten, distribusjonen eller du? Ei kjelde signert med ein nøkkel du ikkje kan stadfeste, er ei oppdateringsmyndigheit du ikkje bør gje.

Eit nei på det fyrste spørsmålet avsluttar analysen. Eit ja på alle tre punkta peikar på signed-by-reparasjonen, som er den einaste ordninga som både verkar og blir verifiserbar. Å blande dei to vegane, ved å halde kjelda og tvinge ho gjennom, er det einaste alternativet som er verdt å utelukke eksplisitt.

Kvifor trusted=yes ser ut som ei retting og ikkje er det

Sida i handboka for sources.list er direkte om det. Å setje valet Trusted til yes fortel apt å godta kjelda sjølv når ho ikkje greier autentisering, noko som slår av apt-secure for det lageret. Sida held det av for ein lokal kontekst, om det i det heile blir brukt.

Det er ikkje ein trongare versjon av å stole på leverandøren. Det fjernar spørsmålet om kven som signerte indeksen, slik at kven som helst som kan svare for det vertsnamnet, kan gje maskina di pakkar som blir installerte som root.

Reparasjonsveg: hent nøkkelen, og fest han deretter

Hent nøkkelen frå staden leverandøren dokumenterer, og pakk han ut i ein nøkkelring som administratoren styrer, og peik deretter lagerlinja mot den fila slik at tilliten ikkje kan drive.

1. Les linja som feilar for å få nøkkel-ID-en og namnet på kjeldepila.
2. Last ned den ASCII-pansra nøkkelen til leverandøren og køyr gpg --dearmor inn i /etc/apt/keyrings/vendor-name.gpg.
3. Legg til [signed-by=/etc/apt/keyrings/vendor-name.gpg] i oppføringa i .list-fila til den leverandøren.
4. Køyr sudo apt update og stadfest at kjelda hentar ein indeks i staden for å gjenta signaturadvaringa.

Føretrekk /usr/share/keyrings for nøklar som kjem med ein pakke, og /etc/apt/keyrings for nøklar du legg inn sjølv. Inndelinga er ikkje kosmetisk: ho fortel den neste administratoren kva nøklar som overlever ein pakkeoppgradering, og kva som treng eit menneske.

Stadfest fingeravtrykket mot den publiserte verdien til leverandøren før du stolar på det. Ein nøkkel-ID lima inn frå eit foruminnlegg er måten ei maskin byrjar å stole på ei oppdateringsmyndigheit som ingen kan namngje.

Fjerningsveg, og kvifor feilen kan kome tilbake

Sjå på kva installasjonsprogrammet faktisk skreiv, fordi fleire filer kan nemne den same leverandøren, og éi av dei er vanlegvis ein restkopi.

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

apt les berre .list og .sources-filer frå den katalogen, så ein .save eller .distUpgrade-kopi blir alt ignorert; å slette han likevel hindrar ein seinare lesar i å gjenopprette han ved eit uhell. Å fjerne kjelda avinstallerer ingenting, og apt kan deretter skildre den installerte VPN-pakken som lokalt installert eller ikkje lenger tilgjengeleg, noko som er ei pakketilstandsmelding og ikkje at tillitsfeilen kjem tilbake.

Det tilbakevendande tilfellet er eldre rettleiing som installerte nøklar med apt-key i den globale betrudde ringen. Den vegen er utdatert, og ein utgivingsopgradering kan la nøkkelen bli droppa eller rett og slett ikkje konsultert, og det er nettopp difor ein feil som var stille i eit år, dukkar opp i veka du oppgraderer. Sjekk /etc/apt/trusted.gpg.d/, og flytt deretter tillitsavgjerda inn i lagerlinja der ho høyrer heime. Viss leverandøren framleis skriv ut apt-key-instruksjonar, bruk signed-by likevel; det er ordninga handboka dokumenterer, og den som overlever ein oppgradering.