Az apt frissítés NO_PUBKEY hibával meghiúsul a VPN-tároló hozzáadása után

A NO_PUBKEY és a hiányzó Release-fájl bizalmi hiba, nem hálózati hiba. Döntse el, rögzíti-e a szállító kulcsát signed-by-jal, vagy eltávolítja a forrást.

A VPN-szállítója apt-forrása tönkretette a csomagkezelőt, és a javítás döntés, nem parancs. NO_PUBKEY, vagy a panasz, hogy a tárolónak nincs Release-fájlja, azt jelenti, hogy az apt megtagadta a forrás megbízhatónak tekintését, ezért minden későbbi csomagművelet ugyanazt a figyelmeztetést írja ki. Maga az alagút valószínűleg ártatlan. Válaszoljon három kérdésre arról, hogy még mindig akarja-e ezt a forrást, és a helyes javítás szinte mechanikusan következik.

Először sorolja a hibát a megfelelő kategóriába

A bizalmi hiba megnevezi a forrásfájlt és vagy a hiányzó kulcsot, vagy a hiányzó Release-fájlt. A szállítási hiba másképp néz ki: TLS-tanúsítvány-hibák, elutasított kapcsolat, időtúllépések, vagy CONNECT-et elutasító proxy. Ez a különbség dönti el, melyik cikket olvassa, mert a TLS-t elfogó vagy a szállító hosztját blokkoló VPN szállítási hibákat okoz, nem aláírási hibákat.

Futtassa a sudo apt update parancsot önmagában, és olvassa el a végét, figyelmen kívül hagyva a felette lévő gyorsítótárazott találatokat. A fontos sor megnevezi a /etc/apt/sources.list.d/ könyvtárat, és megmondja, melyik fájlt nyissa meg.

Ha a hiba az alagút feljövetele után jelentkezik, teszteljen leállított alagúttal és a rendszer feloldóján keresztül feloldott DNS-sel. Az a forrás, amely VPN nélkül működik, útválasztási vagy elfogási kérdés, és semmilyen kulcskezelés nem javítja meg.

Három kérdés, amelyek kiválasztják az utat

Telepít vagy frissít még csomagokat ebből a forrásból? Ha az ügyfél aktívan használatban van, javítsa a bizalmat. Ha egyszer telepítette az ügyfelet, és most egy egyszerű profilt importál a NetworkManagerbe, a forrás holt teher, és az eltávolítás az őszinte javítás.

Másodszor, közzétesz-e a szállító olyan kulcsot és ujjlenyomatot, amelyet sávon kívül ellenőrizhet? Harmadszor, ki kezeli a kulcsokat ezen a hoszton: a disztribúció vagy ön? Az olyan forrás, amelyet nem ellenőrizhető kulccsal írtak alá, olyan frissítési jogosultság, amelyet nem lenne szabad megadnia.

Az első kérdésre adott nem lezárja az elemzést. A mindhárom pontra adott igen a signed-by javításhoz vezet, amely az egyetlen olyan elrendezés, amely működik és auditálható is marad. A két út keverése, a forrás megtartása és erőszakos átpréselése az egyetlen lehetőség, amelyet érdemes kifejezetten kizárni.

Miért tűnik a trusted=yes javításnak, és miért nem az

A sources.list kézikönyvoldala egyértelmű erről. A Trusted beállítás yes értékre állítása azt mondja az apt-nak, hogy akkor is fogadja el a forrást, ha az hitelesítése meghiúsul, ami kikapcsolja az apt-secure-t arra a tárolóra. Az oldal ezt helyi környezetre tartja fenn, ha egyáltalán használják.

Ez nem a szállítóba vetett bizalom szűkebb változata. Eltávolítja azt a kérdést, ki írta alá az indexet, így bárki, aki felelhet azért a hosztnévért, olyan csomagokat adhat a gépének, amelyek rootként települnek.

Javítási út: szerezze be a kulcsot, majd rögzítse

Szerezze be a kulcsot a szállító által dokumentált helyről, és csomagolja ki egy rendszergazda által kezelt kulcskarikába, majd irányítsa a tároló sorát arra a fájlra, hogy a bizalom ne sodródjon el.

  1. Olvassa el a meghiúsuló sort, hogy megkapja a kulcsazonosítót és a forrásfájl nevét.
  2. Töltse le a szállító ASCII-páncélozott kulcsát, és futtassa a gpg --dearmor parancsot a /etc/apt/keyrings/vendor-name.gpg fájlba.
  3. Adja hozzá a [signed-by=/etc/apt/keyrings/vendor-name.gpg] bejegyzést a szállító .list fájljához.
  4. Futtassa a sudo apt update parancsot, és erősítse meg, hogy a forrás indexet kér le, nem ismétli az aláírási figyelmeztetést.

Részesítse előnyben a /usr/share/keyrings könyvtárat a csomaggal érkező kulcsokhoz, és a /etc/apt/keyrings könyvtárat a kézzel elhelyezett kulcsokhoz. Ez a felosztás nem kozmetikai: megmondja a következő rendszergazdának, mely kulcsok élik túl a csomagfrissítést, és melyekhez kell ember.

Ellenőrizze az ujjlenyomatot a szállító közzétett értékével szemben, mielőtt megbízik benne. A fórumbejegyzésből bemásolt kulcsazonosító az az út, ahogy egy gép elkezd megbízni egy olyan frissítési jogosultságban, amelyet senki sem tud megnevezni.

Eltávolítási út, és miért térhet vissza a hiba

Nézze meg, mit írt valójában a telepítő, mert több fájl is említheti ugyanazt a szállítót, és ezek egyike általában visszamaradt másolat.

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

Az apt csak .list és .sources fájlokat olvas abból a könyvtárból, ezért a .save vagy .distUpgrade másolatot már figyelmen kívül hagyja; a törlése viszont megakadályozza, hogy egy későbbi olvasó véletlenül visszaállítsa. A forrás eltávolítása nem távolít el semmit, és az apt ezután a telepített VPN-csomagot helyben telepítettként vagy már nem elérhetőként írhatja le, ami csomagállapot-üzenet, nem a bizalmi hiba visszatérése.

Az ismétlődő eset a régebbi útmutatás, amely apt-key használatával telepített kulcsokat a globális megbízható gyűrűbe. Ez az út elavult, és egy kiadásfrissítés elhagyhatja a kulcsot vagy egyszerűen nem konzultál róla, és pontosan ezért jelenik meg egy évig csendes hiba abban a héten, amikor frissít. Ellenőrizze a /etc/apt/trusted.gpg.d/ könyvtárat, majd helyezze át a bizalmi döntést a tároló sorába, ahová tartozik. Ha a szállító még mindig apt-key utasításokat nyomtat, akkor is használjon signed-by-t; ez az az elrendezés, amelyet a kézikönyv dokumentál, és amely túléli a frissítést.

Kapcsolódó cikkek