Actualizarea apt eșuează cu NO_PUBKEY după adăugarea unui depozit VPN

Sursa apt a furnizorului dvs. VPN a stricat managerul de pachete, iar remedierea este o decizie, nu o comandă. NO_PUBKEY, sau o plângere că depozitul nu are fișier Release, înseamnă că apt a refuzat să aibă încredere în acea sursă, așa că fiecare operațiune ulterioară cu pachete continuă să afișeze același avertisment. Tunelul în sine este probabil nevinovat. Răspundeți la trei întrebări despre dacă mai doriți acea sursă, iar remedierea corectă urmează aproape mecanic.

Mai întâi, puneți defecțiunea în categoria corectă

Un eșec de încredere numește fișierul sursă și fie cheia lipsă, fie fișierul Release absent. Un eșec de transport arată altfel: erori de certificat TLS, conexiune refuzată, expirări de timp sau un proxy care refuză CONNECT. Această distincție decide ce articol citiți, pentru că un VPN care interceptează TLS sau blochează gazda furnizorului produce erori de transport, nu erori de semnătură.

Rulați sudo apt update singur și citiți finalul, ignorând rezultatele din cache de deasupra. Linia care contează numește /etc/apt/sources.list.d/ și vă spune ce fișier să deschideți.

Dacă eșecul apare după ridicarea tunelului, testați cu tunelul coborât și cu DNS rezolvat prin resolverul sistemului. O sursă care funcționează fără VPN este o chestiune de rutare sau interceptare, iar nicio gestionare a cheilor nu o va remedia.

Trei întrebări care aleg calea

Mai instalați sau actualizați pachete din această sursă? Dacă clientul este în uz activ, reparați încrederea. Dacă ați instalat clientul o dată și acum importați un profil simplu în NetworkManager, sursa este balast și eliminarea este remedierea onestă.

În al doilea rând, publică furnizorul o cheie și o amprentă pe care le puteți verifica în afara canalului? În al treilea rând, cine gestionează cheile pe această gazdă: distribuția sau dumneavoastră? O sursă semnată cu o cheie pe care nu o puteți verifica este o autoritate de actualizare pe care nu ar trebui să o acordați.

Un nu la prima întrebare încheie analiza. Un da la toate cele trei puncte duce la remedierea cu signed-by, singura configurare care funcționează și rămâne auditabilă. Amestecarea celor două căi, păstrând sursa și forțând-o, este singura opțiune care merită exclusă explicit.

De ce trusted=yes pare o remediere și nu este

Pagina din manualul sources.list este directă în privința asta. Setarea opțiunii Trusted la yes îi spune lui apt să accepte sursa chiar și când eșuează autentificarea, ceea ce dezactivează apt-secure pentru acel depozit. Pagina rezervă asta pentru un context local, dacă este folosită vreodată.

Nu este o versiune mai îngustă a încrederii în furnizor. Elimină întrebarea cine a semnat indexul, așa că oricine poate răspunde pentru acel nume de gazdă poate oferi mașinii dvs. pachete care se instalează ca root.

Calea de remediere: obțineți cheia, apoi fixați-o

Obțineți cheia din locul documentat de furnizor și despachetați-o într-un portchei administrat de administrator, apoi îndreptați linia depozitului către acel fișier ca încrederea să nu poată deriva.

1. Citiți linia care eșuează pentru a obține ID-ul cheii și numele fișierului sursă.
2. Descărcați cheia furnizorului îmbrăcată în ASCII și executați gpg --dearmor în /etc/apt/keyrings/vendor-name.gpg.
3. Adăugați [signed-by=/etc/apt/keyrings/vendor-name.gpg] la intrarea din fișierul .list al acelui furnizor.
4. Executați sudo apt update și confirmați că sursa aduce un index în loc să repete avertismentul de semnătură.

Preferați /usr/share/keyrings pentru cheile care vin cu un pachet și /etc/apt/keyrings pentru cheile pe care le puneți manual. Împărțirea nu este cosmetică: îi spune următorului administrator care chei vor supraviețui unei actualizări de pachet și care au nevoie de un om.

Verificați amprenta față de valoarea publicată a furnizorului înainte de a avea încredere în ea. Un ID de cheie lipit dintr-o postare de forum este modul în care o mașină ajunge să aibă încredere într-o autoritate de actualizare pe care nimeni nu o poate numi.

Calea de eliminare și de ce eroarea poate reveni

Uitați-vă la ce a scris de fapt instalatorul, pentru că mai multe fișiere pot menționa același furnizor și unul dintre ele este de obicei o copie rămasă.

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

apt citește doar fișiere .list și .sources din acel director, așa că o copie .save sau .distUpgrade este deja ignorată; ștergerea ei totuși împiedică un cititor ulterior să o restaureze din greșeală. Eliminarea sursei nu dezinstalează nimic, iar apt poate apoi descrie pachetul VPN instalat ca instalat local sau indisponibil, ceea ce este un mesaj despre starea pachetului și nu revenirea erorii de încredere.

Cazul recurent este o îndrumare mai veche care instala chei cu apt-key în inelul de încredere global. Acea cale este învechită, iar o actualizare de versiune poate lăsa cheia căzută sau pur și simplu neconsultată, și exact de aceea o eroare care a fost tăcută un an apare în săptămâna în care actualizați. Verificați /etc/apt/trusted.gpg.d/, apoi mutați decizia de încredere în linia depozitului, unde îi este locul. Dacă furnizorul încă tipărește instrucțiuni apt-key, folosiți signed-by oricum; este configurarea documentată de manual și cea care supraviețuiește unei actualizări.