apt-päivitys epäonnistuu NO_PUBKEY-virheellä VPN-lähteen lisäämisen jälkeen
NO_PUBKEY ja puuttuva Release-tiedosto ovat luottamusvirheitä, eivät verkkovikoja. Päätä, kiinnitätkö toimittajan avaimen signed-bylla vai poistatko lähteen.
VPN-toimittajasi apt-lähde rikkoi paketinhallintasi, ja korjaus on päätös, ei komento. NO_PUBKEY, tai valitus siitä, ettei varastossa ole Release-tiedostoa, tarkoittaa, että apt kieltäytyi luottamasta kyseiseen lähteeseen, joten jokainen myöhempi pakettitoimenpide tulostaa saman varoituksen. Itse tunneli on luultavasti syytön. Vastaa kolmeen kysymykseen siitä, haluatko yhä tämän lähteen, ja oikea korjaus seuraa lähes mekaanisesti.
Ensin: laita vika oikeaan luokkaan
Luottamusvirhe nimeää lähdetiedoston ja joko puuttuvan avaimen tai puuttuvan Release-tiedoston. Siirtovirhe näyttää erilaiselta: TLS-varmenteen virheet, hylätty yhteys, aikakatkaisut tai välityspalvelin, joka hylkää CONNECTin. Tämä ero ratkaisee, mitä artikkelia luet, koska TLS-liikennettä sieppaava tai toimittajan isäntää estävä VPN tuottaa siirtovirheitä, ei allekirjoitusvirheitä.
Aja sudo apt update yksin ja lue loppu, jättäen yllä olevat välimuistiin tallennetut osumat huomiotta. Ratkaiseva rivi nimeää /etc/apt/sources.list.d/ ja kertoo, minkä tiedoston avaat.
Jos vika seuraa tunnelin nousua, testaa tunneli alhaalla ja DNS järjestelmän resolverin kautta ratkaistuna. Lähde, joka toimii ilman VPN:ää, on reititys- tai sieppauskysymys, eikä mikään avainten hallinta korjaa sitä.
Kolme kysymystä, jotka valitsevat polun
Asennatko tai päivitätkö yhä paketteja tästä lähteestä? Jos asiakas on aktiivisessa käytössä, korjaa luottamus. Jos asensit asiakkaan kerran ja tuot nyt tavallista profiilia NetworkManageriin, lähde on kuollutta painoa ja poistaminen on rehellinen korjaus.
Toiseksi: julkaiseeko toimittaja avaimen ja sormenjäljen, jonka voit varmistaa kanavan ulkopuolelta? Kolmanneksi: kuka hallinnoi avaimia tällä isännällä, jakelu vai sinä? Lähde, joka on allekirjoitettu avaimella, jota et voi varmistaa, on päivitysvaltuus, jota sinun ei pitäisi myöntää.
Ei ensimmäiseen kysymykseen päättää analyysin. Kyllä kaikkiin kolmeen kohtaan osoittaa signed-by-korjaukseen, joka on ainoa järjestely, joka sekä toimii että pysyy auditoitavana. Kahden polun sekoittaminen, lähteen pitäminen ja sen väkisin läpi pakottaminen, on ainoa vaihtoehto, joka kannattaa sulkea nimenomaisesti pois.
Miksi trusted=yes näyttää korjaukselta eikä ole sitä
Sivu sources.listin käsikirjassa on suora asiasta. Asetuksen Trusted asettaminen arvoon yes kertoo aptille, että lähde hyväksytään myös silloin, kun todentaminen epäonnistuu, mikä kytkee apt-securen pois kyseiseltä varastolta. Sivu varaa sen paikalliseen yhteyteen, jos sitä ylipäätään käytetään.
Tämä ei ole kapeampi versio toimittajaan luottamisesta. Se poistaa kysymyksen siitä, kuka indeksin allekirjoitti, joten kuka tahansa, joka voi vastata kyseisestä isäntänimestä, voi antaa koneellesi paketteja, jotka asentuvat root-oikeuksin.
Korjauspolku: hae avain ja kiinnitä se
Hae avain toimittajan dokumentoimasta paikasta ja pura se järjestelmänvalvojan hallitsemaan avainrenkaaseen, sitten osoita varaston rivi siihen tiedostoon, jotta luottamus ei voi ajautua.
- Lue epäonnistuva rivi saadaksesi avaimen ID:n ja lähdetiedoston nimen.
- Lataa toimittajan ASCII-panssaroitu avain ja aja
gpg --dearmortiedostoon/etc/apt/keyrings/vendor-name.gpg. - Lisää
[signed-by=/etc/apt/keyrings/vendor-name.gpg]kyseisen toimittajan.listtiedoston merkintään. - Aja
sudo apt updateja varmista, että lähde hakee indeksin sen sijaan, että toistaisi allekirjoitusvaroituksen.
Suosi /usr/share/keyrings avaimille, jotka tulevat paketin mukana, ja /etc/apt/keyrings avaimille, jotka asetat käsin. Jako ei ole kosmeettinen: se kertoo seuraavalle ylläpitäjälle, mitkä avaimet kestävät pakettipäivityksen ja mitkä tarvitsevat ihmisen.
Varmista sormenjälki toimittajan julkaisemaa arvoa vasten ennen kuin luotat siihen. Keskustelupalstan viestistä liitetty avaimen ID on tapa, jolla kone alkaa luottaa päivitysvaltuuteen, jota kukaan ei osaa nimetä.
Poistopolku ja miksi virhe voi palata
Katso, mitä asentaja todella kirjoitti, koska useat tiedostot voivat mainita saman toimittajan ja yksi niistä on yleensä jäljelle jäänyt kopio.
grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.listapt lukee kyseisestä hakemistosta vain .list ja .sources tiedostoja, joten .save tai .distUpgrade kopio ohitetaan jo; sen poistaminen silti estää myöhempää lukijaa palauttamasta sitä vahingossa. Lähteen poistaminen ei poista asennuksia, ja apt voi silloin kuvata asennetun VPN-paketin paikallisesti asennetuksi tai ei enää saatavilla olevaksi, mikä on paketin tilaviesti eikä luottamusvirheen paluu.
Toistuva tapaus on vanhempi ohje, joka asensi avaimia apt-key avulla globaaliin luotettuun renkaaseen. Tämä polku on vanhentunut, ja julkaisupäivitys voi jättää avaimen pudotetuksi tai yksinkertaisesti huomiotta, ja juuri siksi virhe, joka oli vuoden hiljaa, ilmestyy viikolla, jolloin päivität. Tarkista /etc/apt/trusted.gpg.d/, siirrä sitten luottamuspäätös varaston riville, jonne se kuuluu. Jos toimittaja yhä tulostaa apt-key-ohjeita, käytä silti signed-bytä; se on järjestely, jonka käsikirja dokumentoi, ja se, joka kestää päivityksen.