Tecnología · GUÍA PRÁCTICA
APT muestra NO_PUBKEY: verifica el repositorio y repara la clave con Signed-By
Identifica la fuente activa, verifica al editor y la huella completa, revisa el formato y los permisos de _apt y vincula la clave con Signed-By. Después comprueba la autenticación del mismo repositorio.
NO_PUBKEY indica que APT no pudo utilizar, para esa fuente, la clave que firmó los metadatos del repositorio. No demuestra que una clave encontrada en un foro o servidor de claves sea correcta, ni justifica desactivar la comprobación de firmas.
La reparación segura se limita a cada repositorio. Conserva el error, localiza la entrada, verifica al propietario y la huella completa mediante canales oficiales, coloca la clave con el formato correcto en un archivo dedicado y referencia ese archivo con Signed-By. Repite la actualización sin omitir la autenticación.
1. Conserva el fallo antes de cambiar la confianza
Repite la actualización normal y guarda toda la salida. Anota el identificador NO_PUBKEY, la URL, la suite o nombre en clave y si el error menciona InRelease o Release.gpg. Todavía no añadas ninguna clave. Varias fuentes de terceros pueden producir avisos distintos en la misma ejecución: identifica la afectada por el servidor y la suite, no por el orden de los mensajes.
Inspecciona /etc/apt/sources.list y los archivos .list y .sources reconocidos dentro de /etc/apt/sources.list.d. Lee la línea o bloque deb822 completo, incluidos URIs, Suites, Signed-By y Enabled. Una línea comentada y un bloque con Enabled: no están desactivados; los archivos de respaldo con otras extensiones no son entradas activas. Relaciona URL y suite con el error y anota todos los duplicados activos. Una búsqueda recursiva solo orienta: no prueba que APT cargue una entrada.
2. Distingue archivos oficiales y repositorios de terceros
Las instalaciones predeterminadas de Debian y Ubuntu incluyen las claves de sus archivos oficiales mediante paquetes mantenidos por la distribución. Una clave ausente puede deberse a un paquete de claves antiguo, una versión sin soporte, una entrada incorrecta o una instalación dañada. Comprueba primero la versión del sistema y la URL oficial, antes de descargar una clave manualmente.
Para un repositorio de terceros, utiliza la página oficial de configuración o distribución de claves del proveedor. Si no puedes relacionar de forma independiente la URL, la identidad del editor y su huella completa publicada, desactiva la fuente y detente. Importar una clave cualquiera puede cambiar el error, pero no establece quién controla el repositorio.
3. Verifica la huella completa antes de instalar
Descarga la candidata únicamente desde el canal verificado del editor a un archivo temporal. Inspecciónala con `gpg --show-keys --with-fingerprint --with-subkey-fingerprint /path/to/candidate-key`, sin añadirla a claves de confianza. Compara, carácter por carácter, la huella completa de la clave principal con la publicada por el propietario en otra página oficial.
No apruebes una clave porque sus últimos ocho o dieciséis caracteres coincidan con NO_PUBKEY. Un resultado de servidor de claves, una orden de un foro, una redirección o un identificador de usuario familiar no verifican al editor. Si la documentación anuncia una rotación, registra las huellas anterior y nueva y las instrucciones aplicables antes de continuar.
4. Prepara un archivo de claves con el formato correcto
Crea /etc/apt/keyrings si hace falta, con propietario root y permisos que permitan recorrer el directorio. Usa .asc para una clave pública con armadura ASCII y .gpg para un archivo binario OpenPGP exportado. Debian distingue un keybox moderno de GnuPG de un archivo de claves para APT: no copies un directorio personal de GnuPG ni su keybox.
Una vez verificada la huella, instala solo el material público con un nombre específico del repositorio, propietario root y modo 0644. Comprueba file, gpg --show-keys --with-fingerprint, stat y `sudo -u _apt test -r /etc/apt/keyrings/vendor-archive-keyring.asc`. Si la última prueba falla, revisa todos los directorios superiores con namei -l. Un archivo legible dentro de un directorio inaccesible sigue sin estar disponible para _apt.
5. Limita la clave del repositorio con Signed-By
En un bloque deb822 .sources, añade `Signed-By: /etc/apt/keyrings/vendor-archive-keyring.asc` al que contiene la URI y suite verificadas. En el formato .list, coloca `signed-by=/etc/apt/keyrings/vendor-archive-keyring.asc` dentro de los corchetes de opciones inmediatamente después de deb. Usa el archivo .asc o .gpg realmente instalado; la extensión debe corresponder a su representación.
Signed-By limita las claves que pueden autenticar ese repositorio. Acota la confianza frente a incorporar todas las claves de terceros globalmente, pero no garantiza paquetes inofensivos. Migra un repositorio cada vez, conserva la entrada original y no retires la clave global anterior antes de verificar la fuente limitada. Si el archivo contiene varias claves y no seleccionas una huella, todas quedan permitidas: inspecciona el archivo completo y sigue la selección documentada por el editor, sin confiar en un conjunto inexplicado.
6. Verifica el repositorio, no solo el código de salida
Ejecuta `sudo apt-get update` sin opciones inseguras. El repositorio objetivo debe descargar y autenticar sus metadatos sin mensajes NO_PUBKEY, de firma inválida o de archivo de claves ilegible. Verifica que el servidor y la suite coincidan con los identificados al principio. El éxito de otro espejo no demuestra que la entrada afectada esté reparada.
Para un paquete esperado de ese repositorio, consulta `apt-cache policy PACKAGE_NAME` y confirma el candidato y origen previstos. Registra la ruta del archivo de fuentes, URI y suite, huella verificada, ruta y SHA-256 del archivo de claves, modo, resultado de actualización y comprobación del origen. Ese registro facilita futuras rotaciones e investigaciones más que una importación sin documentar.
7. Investiga el fallo sin debilitar la autenticación
Si la huella difiere, la página oficial no está disponible, la clave ha caducado o está revocada sin sustitución documentada, o cambia de repente la identidad del repositorio, deja de usarlo y consulta al editor. Si la huella coincide pero persiste NO_PUBKEY, revisa la ruta Signed-By, el formato, la lectura por _apt, las entradas duplicadas y si realmente se firmaron los metadatos Release con esa clave.
trusted=yes, allow-insecure=yes, Acquire::AllowInsecureRepositories o una instalación sin autenticar debilitan el control que detectó el problema. Debian los documenta como excepciones que reducen la seguridad, no como pasos de reparación. Mantén el repositorio desactivado hasta poder verificar la cadena entre editor, clave y metadatos firmados.
