Teie VPN-i tarnija apt-allikas lõhkus paketihalduri ja parandus on otsus, mitte käsk. NO_PUBKEY, või kaebus, et hoidlas pole Release-faili, tähendab, et apt keeldus sellele allikale usaldamast, seega trükib iga järgnev pakettoiming sama hoiatust edasi. Tunnel ise on tõenäoliselt süütu. Vastake kolmele küsimusele, kas te seda allikat ikka soovite, ja õige parandus järgneb peaaegu mehaaniliselt.

Esiteks, asetage tõrge õigesse kategooriasse

Usaldustõrge nimetab allikafaili ning kas puuduva võtme või puuduva Release-faili. Transporditõrge näeb teistsugune välja: TLS-sertifikaadi vead, keeldutud ühendus, aegumised või puhverserver, mis keeldub CONNECT-ist. See erinevus otsustab, millist artiklit te loete, sest VPN, mis püüab TLS-i kinni või blokeerib tarnija hosti, tekitab transpordivigu, mitte allkirjavigu.

Käivitage sudo apt update üksinda ja lugege lõppu, jättes ülal olevad vahemällu salvestatud tabamused tähelepanuta. Oluline rida nimetab /etc/apt/sources.list.d/ ja ütleb teile, millist faili avada.

Kui tõrge järgneb tunneli tõusmisele, testige tunnel maas ja DNS-iga, mille lahendab süsteemi resolver. Allikas, mis töötab ilma VPN-ita, on marsruutimise või vahelesegamise küsimus ja mingi võtmehaldus seda ei paranda.

Kolm küsimust, mis valivad tee

Kas installite või uuendate endiselt pakette sellest allikast? Kui klient on aktiivses kasutuses, parandage usaldus. Kui paigaldasite kliendi korra ja impordite nüüd NetworkManagerisse tavalise profiili, on allikas surnud raskus ja eemaldamine on aus parandus.

Teiseks, kas tarnija avaldab võtme ja sõrmejälje, mida saate väljaspool kanalit kontrollida? Kolmandaks, kes haldab selles hostis võtmeid: distributsioon või teie? Võtmega allkirjastatud allikas, mida te ei saa kontrollida, on uuendusvolitus, mida te ei peaks andma.

Vastus ei esimesele küsimusele lõpetab analüüsi. Vastus jah kõigile kolmele punktile osutab signed-by parandusele, mis on ainus lahendus, mis nii töötab kui ka jääb auditeeritavaks. Kahe tee segamine, allika hoidmine ja sellest läbi surumine, on ainus valik, mida tasub selgesõnaliselt välistada.

Miks trusted=yes näeb parandusena välja, kuid pole seda

Lehekülg sources.list-i käsiraamatus on selles otsene. Valiku Trusted väärtuseks yes seadmine ütleb apt-ile allikat aktsepteerida ka siis, kui autentimine ebaõnnestub, mis lülitab selle hoidla jaoks apt-secure'i välja. Lehekülg jätab selle kohaliku konteksti jaoks, kui seda üldse kasutatakse.

See pole tarnijasse usaldamise kitsam versioon. See eemaldab küsimuse, kes indeksi allkirjastas, nii et igaüks, kes selle hostinime eest vastata saab, võib teie masinale anda pakette, mis paigaldatakse root-õigustega.

Parandustee: hankige võti ja kinnitage see

Hankige võti kohast, mille tarnija dokumenteerib, ja pakkige see lahti administraatori hallatavasse võtmehoidlasse, seejärel suunake hoidla rida sellele failile, et usaldus ei saaks triivima hakata.

  1. Lugege nurjuvat rida, et saada võtme ID ja allikafaili nimi.
  2. Laadige alla tarnija ASCII-soomustatud võti ja käivitage gpg --dearmor faili /etc/apt/keyrings/vendor-name.gpg.
  3. Lisage [signed-by=/etc/apt/keyrings/vendor-name.gpg] selle tarnija faili .list kirjele.
  4. Käivitage sudo apt update ja kinnitage, et allikas toob indeksi, mitte ei korda allkirjahoiatust.

Eelistage /usr/share/keyrings võtmetele, mis tulevad paketiga, ja /etc/apt/keyrings võtmetele, mille asetate käsitsi. Jaotus pole kosmeetiline: see ütleb järgmisele administraatorile, millised võtmed peavad paketiuuendusele vastu ja millised vajavad inimest.

Kontrollige sõrmejälge tarnija avaldatud väärtuse vastu enne, kui usaldate seda. Foorumipostitusest kleepitud võtme-ID on see, kuidas masin hakkab usaldama uuendusvolitust, mida keegi nimetada ei oska.

Eemaldamistee ja miks viga võib tagasi tulla

Vaadake, mida paigaldaja tegelikult kirjutas, sest mitu faili võivad mainida sama tarnijat ja üks neist on tavaliselt ülejäänud koopia.

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

apt loeb sellest kaustast ainult .list ja .sources faile, seega .save või .distUpgrade koopiat juba eiratakse; selle kustutamine takistab siiski hilisemal lugejal seda kogemata taastada. Allika eemaldamine ei desinstalli midagi ja apt võib seejärel kirjeldada paigaldatud VPN-paketti kui kohapeal paigaldatud või enam mitte saadaval, mis on paketi olekuteade, mitte usaldusvea naasmine.

Korduv juhtum on vanem juhis, mis paigaldas võtmeid apt-key abil üleilmsesse usaldusrõngasse. See tee on aegunud ja väljalaskeuuendus võib jätta võtme maha visatuks või lihtsalt konsulteerimata, mis on täpselt põhjus, miks viga, mis oli aasta vaikne, ilmub nädalal, mil te uuendate. Kontrollige /etc/apt/trusted.gpg.d/, seejärel viige usaldusotsus hoidla reale, kuhu see kuulub. Kui tarnija trükib endiselt apt-key juhiseid, kasutage ikkagi signed-by; see on lahendus, mille käsiraamat dokumenteerib, ja see, mis uuendusele vastu peab.

Seotud artiklid