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

apt-kilden til VPN-leverandøren din har ødelagt pakkebehandlingen, og rettelsen er en beslutning, ikke en kommando. NO_PUBKEY, eller en klage på at lageret ikke har noen Release-fil, betyr at apt har nektet å stole på den kilden, slik at enhver senere pakkeoperasjon fortsetter å skrive ut den samme advarselen. Selve tunnelen er sannsynligvis uskyldig. Svar på tre spørsmål om du fortsatt vil ha den kilden, og den riktige reparasjonen følger nesten mekanisk.

Først: sett feilen i riktig kategori

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

Kjør sudo apt update alene og les slutten, mens du ignorerer de bufrede treffene over. Linjen som betyr noe, navngir /etc/apt/sources.list.d/ og forteller deg hvilken fil du skal åpne.

Hvis feilen følger at tunnelen kommer opp, test med tunnelen nede og med DNS slått opp via systemets resolver. En kilde som virker uten VPN-en, er et ruting- eller avlyttingsspørsmål, og ingen mengde nøkkeladministrasjon retter det.

Tre spørsmål som velger veien

Installerer eller oppgraderer du fortsatt pakker fra denne kilden? Hvis klienten er i aktiv bruk, reparer tilliten. Hvis du installerte 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 du kan verifisere utenfor kanalen? For det tredje: hvem administrerer nøkler på denne verten, distribusjonen eller du? En kilde 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 på 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 eksplisitt.

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

Siden i håndboken for sources.list er direkte om det. Å sette alternativet Trusted til yes forteller apt å godta kilden selv når den ikke består autentisering, noe som slår av apt-secure for det lageret. Siden forbeholder det for en lokal kontekst, hvis det i det hele tatt brukes.

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

Reparasjonsvei: hent nøkkelen, og fest den deretter

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

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 den 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 kommer med en pakke, og /etc/apt/keyrings for nøkler du legger inn selv. 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 leverandørens publiserte verdi før du stoler på det. En nøkkel-ID 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 restkopi.

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

apt leser bare .list og .sources-filer fra den katalogen, så en .save eller .distUpgrade-kopi ignoreres allerede; å 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 pakketilstandsbeskjed og ikke at tillitsfeilen kommer tilbake.

Det tilbakevendende tilfellet er eldre veiledning som installerte nøkler med apt-key i den globale betrodde ringen. Den 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 tillitsbeslutningen 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.