La actualización con apt falla con NO_PUBKEY tras añadir un repositorio de VPN

La fuente apt de su proveedor de VPN ha roto el gestor de paquetes, y la solución es una decisión, no un comando. NO_PUBKEY, o una queja de que el repositorio no tiene archivo Release, significa que apt se negó a confiar en esa fuente, así que cada operación de paquetes posterior sigue imprimiendo la misma advertencia. El túnel en sí probablemente es inocente. Responda tres preguntas sobre si aún quiere esa fuente, y la reparación correcta llega casi mecánicamente.

Primero, coloque el fallo en la categoría correcta

Un fallo de confianza nombra el archivo de origen y o bien la clave que falta o bien el archivo Release ausente. Un fallo de transporte se ve distinto: errores de certificado TLS, conexión rechazada, tiempos de espera agotados o un proxy que rechaza CONNECT. Esa distinción decide qué artículo está leyendo, porque un VPN que intercepta TLS o bloquea el host del proveedor produce errores de transporte, no errores de firma.

Ejecute sudo apt update por sí solo y lea el final, ignorando los aciertos en caché de arriba. La línea que importa nombra /etc/apt/sources.list.d/ y le dice qué archivo abrir.

Si el fallo sigue a la subida del túnel, pruebe con el túnel bajado y con DNS resuelto por el resolutor del sistema. Una fuente que funciona sin el VPN es una cuestión de enrutamiento o intercepción, y ninguna cantidad de gestión de claves lo arreglará.

Tres preguntas que eligen el camino

¿Sigue instalando o actualizando paquetes desde esta fuente? Si el cliente está en uso activo, repare la confianza. Si instaló el cliente una vez y ahora importa un perfil sencillo en NetworkManager, la fuente es peso muerto y eliminarla es la reparación honesta.

Segundo, ¿publica el proveedor una clave y una huella que pueda verificar fuera de banda? Tercero, ¿quién gestiona las claves en este host: la distribución o usted? Una fuente firmada con una clave que no puede verificar es una autoridad de actualización que no debería conceder.

Responder no a la primera pregunta termina el análisis. Responder sí a los tres puntos apunta a la reparación con signed-by, la única disposición que funciona y sigue siendo auditable. Mezclar los dos caminos, manteniendo la fuente y forzándola, es la única opción que vale la pena descartar explícitamente.

Por qué trusted=yes parece una solución y no lo es

La página del manual de sources.list es directa al respecto. Poner la opción Trusted en yes le dice a apt que acepte la fuente incluso cuando falla la autenticación, lo que desactiva apt-secure para ese repositorio. La página lo reserva para un contexto local, si es que se usa.

No es una versión más estrecha de confiar en el proveedor. Elimina la pregunta de quién firmó el índice, así que cualquiera que pueda responder por ese nombre de host puede entregar a su máquina paquetes que se instalan como root.

Camino de reparación: obtenga la clave y luego fíjela

Obtenga la clave del lugar que el proveedor documenta y desenvuélvala en un llavero gestionado por el administrador, luego apunte la línea del repositorio a ese archivo para que la confianza no pueda derivar.

1. Lea la línea que falla para obtener el ID de la clave y el nombre del archivo de origen.
2. Descargue la clave del proveedor blindada en ASCII y ejecute gpg --dearmor hacia /etc/apt/keyrings/vendor-name.gpg.
3. Añada [signed-by=/etc/apt/keyrings/vendor-name.gpg] a la entrada del archivo .list de ese proveedor.
4. Ejecute sudo apt update y confirme que la fuente obtiene un índice en lugar de repetir la advertencia de firma.

Prefiera /usr/share/keyrings para las claves que llegan con un paquete y /etc/apt/keyrings para las claves que coloca a mano. La división no es cosmética: dice al siguiente administrador qué claves sobrevivirán a una actualización de paquete y cuáles necesitan a una persona.

Verifique la huella contra el valor publicado por el proveedor antes de confiar en ella. Un ID de clave pegado de una publicación de foro es cómo una máquina acaba confiando en una autoridad de actualización que nadie puede nombrar.

Camino de eliminación, y por qué el error puede volver

Mire lo que el instalador escribió realmente, porque varios archivos pueden mencionar al mismo proveedor y uno de ellos suele ser una copia sobrante.

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

apt solo lee archivos .list y .sources de ese directorio, así que una copia .save o .distUpgrade ya se ignora; borrarla de todos modos impide que un lector posterior la restaure por accidente. Eliminar la fuente no desinstala nada, y apt puede entonces describir el paquete VPN instalado como instalado localmente o ya no disponible, lo que es un mensaje de estado del paquete y no el retorno del error de confianza.

El caso recurrente son instrucciones más antiguas que instalaban claves con apt-key en el anillo de confianza global. Ese camino está obsoleto, y una actualización de versión puede dejar la clave caída o simplemente no consultada, que es exactamente por qué un error que estuvo callado un año aparece la semana en que actualiza. Revise /etc/apt/trusted.gpg.d/, y luego mueva la decisión de confianza a la línea del repositorio donde corresponde. Si el proveedor aún imprime instrucciones de apt-key, use signed-by de todos modos; es la disposición que documenta el manual, y la que sobrevive a una actualización.