A actualización con apt falla con NO_PUBKEY tras engadir un repositorio de VPN

NO_PUBKEY e un ficheiro Release ausente son fallos de confianza, non de rede. Decida se fixa a clave do provedor con signed-by ou elimina a fonte.

A fonte apt do seu provedor de VPN rompeu o xestor de paquetes, e a solución é unha decisión, non un comando. NO_PUBKEY, ou unha queixa de que o repositorio non ten ficheiro Release, significa que apt se negou a confiar nesa fonte, así que cada operación de paquetes posterior segue imprimindo o mesmo aviso. O túnel en si probablemente é inocente. Responda tres preguntas sobre se aínda quere esa fonte, e a reparación correcta chega case mecanicamente.

Primeiro, poña o fallo na categoría correcta

Un fallo de confianza nomea o ficheiro de orixe e ou ben a clave que falta ou ben o ficheiro Release ausente. Un fallo de transporte vese distinto: erros de certificado TLS, conexión rexeitada, tempos de espera esgotados ou un proxy que rexeita CONNECT. Esa distinción decide que artigo está a ler, porque un VPN que intercepta TLS ou bloquea o host do provedor produce erros de transporte, non erros de sinatura.

Execute sudo apt update por si só e lea o final, ignorando os acertos na caché de arriba. A liña que importa nomea /etc/apt/sources.list.d/ e di que ficheiro abrir.

Se o fallo segue a subida do túnel, probe co túnel baixado e con DNS resolto polo resolutor do sistema. Unha fonte que funciona sen o VPN é unha cuestión de encamiñamento ou intercepción, e ningunha cantidade de xestión de claves o arranxará.

Tres preguntas que elixen o camiño

Segue instalando ou actualizando paquetes desde esta fonte? Se o cliente está en uso activo, repare a confianza. Se instalou o cliente unha vez e agora importa un perfil sinxelo en NetworkManager, a fonte é peso morto e eliminala é a reparación honesta.

Segundo, publica o provedor unha clave e unha pegada que poida verificar fóra da canle? Terceiro, quen xestiona as claves neste host: a distribución ou vostede? Unha fonte asinada cunha clave que non pode verificar é unha autoridade de actualización que non debería conceder.

Responder non á primeira pregunta remata a análise. Responder si aos tres puntos apunta á reparación con signed-by, a única disposición que funciona e segue a ser auditable. Mesturar os dous camiños, mantendo a fonte e forzándoa, é a única opción que paga a pena descartar explicitamente.

Por que trusted=yes parece unha solución e non o é

A páxina do manual de sources.list é directa respecto diso. Poñer a opción Trusted en yes dille a apt que acepte a fonte mesmo cando falla a autenticación, o que desactiva apt-secure para ese repositorio. A páxina resérvao para un contexto local, se é que se usa.

Non é unha versión máis estreita de confiar no provedor. Elimina a pregunta de quen asinou o índice, así que calquera que poida responder por ese nome de host pode entregar á súa máquina paquetes que se instalan como root.

Camiño de reparación: obteña a clave e logo fíxea

Obteña a clave do lugar que o provedor documenta e desenvólvaa nun chaveiro xestionado polo administrador, logo apunte a liña do repositorio a ese ficheiro para que a confianza non poida derivar.

  1. Lea a liña que falla para obter o ID da clave e o nome do ficheiro de orixe.
  2. Descargue a clave do provedor blindada en ASCII e execute gpg --dearmor cara a /etc/apt/keyrings/vendor-name.gpg.
  3. Engada [signed-by=/etc/apt/keyrings/vendor-name.gpg] á entrada do ficheiro .list dese provedor.
  4. Execute sudo apt update e confirme que a fonte obtén un índice en lugar de repetir o aviso de sinatura.

Prefera /usr/share/keyrings para as claves que chegan cun paquete e /etc/apt/keyrings para as claves que coloca a man. A división non é cosmética: di ao seguinte administrador que claves sobrevivirán a unha actualización de paquete e cales necesitan unha persoa.

Verifique a pegada contra o valor publicado polo provedor antes de confiar nela. Un ID de clave pegado dunha publicación de foro é como unha máquina acaba confiando nunha autoridade de actualización que ninguén pode nomear.

Camiño de eliminación, e por que o erro pode volver

Mire o que o instalador escribiu realmente, porque varios ficheiros poden mencionar o mesmo provedor e un deles adoita ser unha copia sobrante.

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

apt só le ficheiros .list e .sources dese directorio, así que unha copia .save ou .distUpgrade xa se ignora; borrala de todos os xeitos impide que un lector posterior a restaure por accidente. Eliminar a fonte non desinstala nada, e apt pode entón describir o paquete VPN instalado como instalado localmente ou xa non dispoñible, o que é unha mensaxe de estado do paquete e non o regreso do erro de confianza.

O caso recorrente son instrucións máis antigas que instalaban claves con apt-key no anel de confianza global. Ese camiño está obsoleto, e unha actualización de versión pode deixar a clave caída ou simplemente non consultada, que é exactamente por que un erro que estivo calado un ano aparece a semana en que actualiza. Revise /etc/apt/trusted.gpg.d/, e logo mova a decisión de confianza á liña do repositorio onde corresponde. Se o provedor aínda imprime instrucións de apt-key, use signed-by de todos os xeitos; é a disposición que documenta o manual, e a que sobrevive a unha actualización.

Artigos relacionados