apt-bywurkje mislearret mei NO_PUBKEY nei it tafoegjen fan in VPN-boarne

NO_PUBKEY en in ûntbrekkend Release-bestân binne fertrouwensflaters, gjin netwurkstoarringen. Beslis oft jo de kaai fan de leveransier mei signed-by fêstsette of de boarne fuortsmite.

De apt-boarne fan jo VPN-leveransier hat jo pakketbehearder brutsen, en de oplossing is in beslissing, gjin opdracht. NO_PUBKEY, of in klacht dat it argyf gjin Release-bestân hat, betsjut dat apt wegere hat dy boarne te fertrouwen, sadat elke lettere pakketbewurking deselde warskôging bliuwt printsjen. De tunnel sels is wierskynlik ûnskuldich. Beäntwurdzje trije fragen oer oft jo dy boarne noch wolle, en de krekte reparaasje folget hast meganysk.

Earst: set de flater yn de juiste kategory

In fertrouwensflater neamt it boarnebestân en óf de ûntbrekkende kaai óf it ûntbrekkende Release-bestân. In transportflater sjocht der oars út: TLS-sertifikaatflaters, wegere ferbining, tiidferrin, of in proxy dy't CONNECT wegeret. Dat ûnderskied beslist hokker artikel jo lêze, want in VPN dy't TLS ûnderskept of de host fan de leveransier blokkearret, jout transportflaters, gjin hantekeningflaters.

Fier sudo apt update allinnich út en lês de sturt, wylst jo de cachede treffers derboppe negearje. De rigel dy't fan belang is, neamt /etc/apt/sources.list.d/ en fertelt jo hokker bestân jo iepenje moatte.

As de flater folget as de tunnel omheech komt, test dan mei de tunnel del en mei DNS oplost troch de systeemresolver. In boarne dy't sûnder de VPN wurket, is in fraach fan rûtesjen of ûnderskepping, en gjin hoemannichte kaaibehear sil dat reparearje.

Trije fragen dy't it paad kieze

Ynstallearje of bywurkje jo noch pakketten fan dizze boarne? As de klant aktyf brûkt wurdt, reparearje dan it fertrouwen. As jo de klant ien kear ynstallearre hawwe en no in gewoan profyl yn NetworkManager ymportearje, is de boarne dea gewicht en is fuortsmite de earlike reparaasje.

Twadde: publisearret de leveransier in kaai en in fingerprint dy't jo bûten it kanaal ferifiearje kinne? Tredde: wa beheart kaaien op dizze host, de distribúsje of jo? In boarne ûndertekene mei in kaai dy't jo net ferifiearje kinne, is in bywurkingsautoriteit dy't jo net jaan moatte.

Nee antwurdzje op de earste fraach einiget de analyze. Ja op alle trije punten wiist op de signed-by-reparaasje, de iennige regeling dy't sawol wurket as auditearber bliuwt. De twa paden mingselje, troch de boarne te hâlden en dy der troch te twingen, is de iennige opsje dy't de muoite wurdich is om eksplisyt út te sluten.

Wêrom't trusted=yes op in reparaasje liket en gjin is

De side fan de hânlieding foar sources.list is der direkt oer. De opsje Trusted op yes sette fertelt apt om de boarne te akseptearjen sels as dy net troch de autentikaasje komt, wat apt-secure foar dat argyf útskeakelet. De side behâldt it foar in lokale kontekst, as it al brûkt wurdt.

Dit is gjin smeller ferzje fan fertrouwen yn de leveransier. It hellet de fraach fuort wa't de yndeks ûndertekene hat, sadat elkenien dy't foar dy hostnamme antwurdzje kin, jo masine pakketten jaan kin dy't as root ynstallearje.

Reparaasjepaad: helje de kaai en set dy dan fêst

Helje de kaai fan it plak dat de leveransier dokumintearret en pak dy út yn in kaaihingst dy't troch de behearder bestjoerd wurdt, en rjochtsje dan de argyfrigel op dat bestân sadat it fertrouwen net driuwe kin.

  1. Lês de mislearjende rigel om de kaai-ID en de namme fan it boarnebestân te krijen.
  2. Download de ASCII-pânsere kaai fan de leveransier en fier gpg --dearmor út nei /etc/apt/keyrings/vendor-name.gpg.
  3. Foegje [signed-by=/etc/apt/keyrings/vendor-name.gpg] ta oan de ynfier yn de .list-bestân fan dy leveransier.
  4. Fier sudo apt update út en befêstigje dat de boarne in yndeks hellet ynstee fan de hantekeningwarskôging te werheljen.

Foarkar /usr/share/keyrings foar kaaien dy't mei in pakket komme en /etc/apt/keyrings foar kaaien dy't jo mei de hân pleatse. De splitsing is net kosmetysk: it fertelt de folgjende behearder hokker kaaien in pakketfernijing oerlibje en hokker in minske nedich hawwe.

Ferifiearje de fingerprint tsjin de publisearre wearde fan de leveransier foardat jo it fertrouwe. In kaai-ID plakt út in foarumpost is hoe't in masine in bywurkingsautoriteit begjint te fertrouwen dy't nimmen neame kin.

Fuortsmytpaad, en wêrom't de flater weromkomme kin

Sjoch nei wat de ynstallearder eins skreaun hat, want ferskate bestannen kinne deselde leveransier neame en ien dêrfan is meastentiids in oerbleaune kopy.

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

apt lêst allinnich .list en .sources-bestannen út dy map, dus in .save of .distUpgrade-kopy wurdt al negearre; it dochs fuortsmiten stopet in lettere lêzer derfan it by ûngelok werom te setten. It fuortsmite fan de boarne ynstallearret neat, en apt kin dan it ynstallearre VPN-pakket beskriuwe as lokaal ynstallearre of net mear beskikber, wat in pakketstatusberjocht is en net it weromkommen fan de fertrouwensflater.

It weromkommende gefal is âldere begelieding dy't kaaien mei apt-key yn de globale fertroude ring ynstallearre. Dat paad is ferâldere, en in útjeftefernijing kin de kaai falle litte of gewoan net rieplachte, en dat is krekt wêrom't in flater dy't in jier stil wie, ferskynt yn de wike dat jo bywurkje. Kontrolearje /etc/apt/trusted.gpg.d/, ferpleatse dan it fertrouwensbeslút nei de argyfrigel wêr't it heart. As de leveransier noch apt-key-ynstruksjes printsjet, brûk dan dochs signed-by; it is de regeling dy't de hânlieding dokumintearret, en dy't in fernijing oerlibbet.

Relatearre artikelen