apt-oppdatering feiler med NO_PUBKEY etter at et VPN-lager er lagt til

apt-kilden til VPN-leverandøren din har ødelagt pakkeadministrasjonen din, og rettelsen er en avgjørelse, ikke en kommando. NO_PUBKEY, eller en klage på at lageret ikke har noen Release-fil, betyr at apt har nektet å stole på denne kilden, slik at enhver senere pakkeoperasjon fortsetter å skrive ut den samme advarselen. Selve tunnelen er trolig uskyldig. Besvar tre spørsmål om du fortsatt vil ha denne kilden, og den korrekte reparasjonen følger nesten av seg selv.

Først: plasser feilen i riktig kategori

En tillitsfeil oppgir kildefilen og enten den manglende nøkkelen eller den fraværende Release-filen. En transportfeil ser annerledes ut: TLS-sertifikatfeil, nektet tilkobling, tidsavbrudd eller en proxy som nekter CONNECT. Denne forskjellen avgjør hvilken artikkel du leser, fordi en VPN som avlytter TLS eller blokkerer leverandørens vert gir transportfeil, ikke signaturfeil.

Kjør sudo apt update på egen hånd og les slutten, mens du ser bort fra de bufrede treffene over. Linjen som er viktig, oppgir /etc/apt/sources.list.d/ og forteller deg hvilken fil du skal åpne.

Hvis feilen kommer etter at tunnelen er oppe, test med tunnelen nede og med DNS slått opp gjennom systemets resolver. En kilde som virker uten VPN-en, er et spørsmål om ruting eller avlytting, og ingen mengde nøkkeladministrasjon retter på det.

Tre spørsmål som avgjør veien

Installerer eller oppgraderer du fortsatt pakker fra denne kilden? Er klienten i aktiv bruk, reparer tilliten. Har du installert klienten én gang og nå importerer en vanlig profil i NetworkManager, er kilden død vekt, og fjerning er den ærlige rettelsen.

For det andre: publiserer leverandøren en nøkkel og et fingeravtrykk som du kan verifisere utenfor kanalen? For det tredje: hvem administrerer nøkler på denne verten, distribusjonen eller du? En kilde som er signert med en nøkkel du ikke kan verifisere, er en oppdateringsmyndighet du ikke bør gi.

Et nei på det første spørsmålet avslutter analysen. Et ja på alle tre punktene peker mot signed-by-reparasjonen, som er den eneste ordningen som både virker og forblir reviderbar. Å blande de to veiene, ved å beholde kilden og tvinge den gjennom, er det eneste alternativet som er verdt å utelukke uttrykkelig.

Hvorfor trusted=yes ser ut som en rettelse, men ikke er det

Siden i håndboken for sources.list er tydelig på dette. Å sette alternativet Trusted til yes forteller apt at kilden skal godtas selv når autentiseringen mislykkes, noe som slår av apt-secure for dette lageret. Siden forbeholder dette for en lokal sammenheng, hvis det brukes i det hele tatt.

Dette er ikke en snevrere variant av å stole på leverandøren. Det fjerner spørsmålet om hvem som signerte indeksen, slik at den som kan svare for dette vertsnavnet, kan gi maskinen din pakker som installeres som root.

Reparasjonsvei: hent nøkkelen, og fest den etterpå

Hent nøkkelen fra stedet som leverandøren dokumenterer, og pakk den ut i en nøkkelring som administratoren styrer, og pek deretter lagerlinjen mot denne filen slik at tilliten ikke kan forskyve seg.

1. Les linjen som feiler, for å få nøkkel-ID-en og navnet på kildefilen.
2. Last ned leverandørens ASCII-pansrede nøkkel og kjør gpg --dearmor inn i /etc/apt/keyrings/vendor-name.gpg.
3. Legg til [signed-by=/etc/apt/keyrings/vendor-name.gpg] i oppføringen i .list-filen til denne leverandøren.
4. Kjør sudo apt update og bekreft at kilden henter en indeks i stedet for å gjenta signaturadvarselen.

Foretrekk /usr/share/keyrings for nøkler som følger med en pakke, og /etc/apt/keyrings for nøkler som du legger inn selv. Denne inndelingen er ikke kosmetisk: den forteller den neste administratoren hvilke nøkler som overlever en pakkeoppgradering, og hvilke som trenger et menneske.

Verifiser fingeravtrykket mot den publiserte verdien til leverandøren før du stoler på det. En nøkkel-ID som er limt inn fra et foruminnlegg, er måten en maskin begynner å stole på en oppdateringsmyndighet som ingen kan navngi.

Fjerningsvei, og hvorfor feilen kan komme tilbake

Se på hva installasjonsprogrammet faktisk skrev, fordi flere filer kan nevne den samme leverandøren, og én av dem er vanligvis en gjenværende kopi.

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

apt leser bare .list og .sources-filer fra denne katalogen, så en .save eller .distUpgrade-kopi blir allerede ignorert; å slette den likevel hindrer en senere leser i å gjenopprette den ved et uhell. Å fjerne kilden avinstallerer ingenting, og apt kan deretter beskrive den installerte VPN-pakken som lokalt installert eller ikke lenger tilgjengelig, noe som er en melding om pakkestatus og ikke at tillitsfeilen kommer tilbake.

Det tilbakevendende tilfellet er eldre veiledning som installerte nøkler med apt-key i den globale betrodde ringen. Denne veien er utdatert, og en utgivelsesoppgradering kan la nøkkelen bli droppet eller rett og slett ikke konsultert, og det er nettopp derfor en feil som var stille i et år, dukker opp i uken du oppgraderer. Sjekk /etc/apt/trusted.gpg.d/, og flytt deretter tillitsavgjørelsen inn i lagerlinjen der den hører hjemme. Hvis leverandøren fortsatt skriver ut apt-key-instruksjoner, bruk signed-by likevel; det er ordningen håndboken dokumenterer, og den som overlever en oppgradering.