Informática y Software Práctico

Cómo poner en Kali Linux un repositorio que no rompa APT

Post actualizado el día noviembre 1, 2026 by DeiviSanzPlay

Cuando alguien busca cómo poner en Kali Linux una herramienta que no viene en los repos oficiales, el error más común es añadir líneas a mano en /etc/apt/sources.list sin comprobar la suite. Kali es una distribución rolling release basada en Debian testing, y mezclar repos de Debian stable o de Ubuntu con los de Kali es la vía rápida a un sistema roto. Lo he visto en instalaciones de laboratorio donde, tras pegar un comando de un foro antiguo, apt update empieza a devolver errores de claves GPG y dependencias incumplidas.

Antes de tocar nada, revisa qué tienes configurado. Ejecuta cat /etc/apt/sources.list y mira también los archivos dentro de /etc/apt/sources.list.d/. En versiones recientes de Kali, el repositorio principal suele estar en un archivo aparte llamado kali.sources con formato deb822. Si añades una línea clásica encima, puedes duplicar entradas y ralentizar las actualizaciones.

Añadir un repositorio externo sin destrozar el sistema

Pongamos un caso real: quieres instalar una herramienta de análisis que solo se distribuye mediante su propio repositorio APT. El procedimiento sensato para saber cómo poner en Kali Linux ese origen pasa por cuatro pasos concretos. Primero, descarga la clave pública del proyecto y guárdala en /usr/share/keyrings/ con un nombre descriptivo, no en el llavero global. Segundo, crea un archivo .list dentro de /etc/apt/sources.list.d/ con la línea deb [signed-by=/usr/share/keyrings/proyecto.gpg] https://repo.proyecto.com/deb/ kali main. Tercero, ejecuta sudo apt update y lee la salida con atención. Cuarto, instala solo el paquete que necesitas, no el metapaquete completo si existe.

Ese parámetro signed-by es la diferencia entre un sistema que sigue funcionando y uno que empieza a quejarse de firmas. Sin él, APT confía en cualquier clave del llavero, y eso en una máquina de auditoría es un riesgo innecesario.

El problema de las dependencias cuando mezclas suites

Kali arrastra paquetes de Debian testing. Si añades un repositorio pensado para Debian stable, es probable que algunas librerías queden en versiones más antiguas de las que Kali espera. El resultado típico: apt install se niega a continuar porque rompería dependencias, o peor, las instala y algo deja de arrancar. Esto no funciona bien para proyectos que solo publican binarios para Ubuntu LTS; en ese caso conviene usar el paquete .deb con dpkg -i y resolver dependencias a mano, o compilar desde el código fuente.

Una alternativa que muchos ignoran: los contenedores. Si la herramienta no es crítica para el sistema, puedes levantarla con Docker y evitar contaminar el árbol de paquetes. Es la opción que recomiendo cuando el software es de terceros y no hay garantías de compatibilidad.

Cómo poner en Kali Linux un PPA: por qué casi nunca es la respuesta

Los PPA son de Ubuntu, y Kali no los soporta oficialmente. He visto tutoriales que sugieren añadir add-apt-repository ppa:algo y luego arreglar el desastre con apt install -f. Eso puede funcionar una vez, pero deja el sistema en un estado frágil. La pregunta sobre cómo poner en Kali Linux software de terceros tiene una respuesta más honesta: usa el repositorio del proyecto si existe, y si no, aísla la aplicación. No hay atajo limpio.

Si aun así decides probar, haz una instantánea del sistema antes. En una máquina virtual el coste es cero; en una instalación nativa, un timeshift o un snapshot LVM te ahorra una reinstalación.

Verificar que el repositorio quedó bien configurado

Después de añadir el origen, comprueba tres cosas. Que apt update termina sin errores de firma. Que apt policy nombre-paquete muestra el repositorio nuevo como candidato. Y que el paquete se instala sin arrastrar actualizaciones masivas de librerías del sistema. Si ves que APT quiere actualizar cientos de paquetes que no tienen relación, algo va mal: probablemente has añadido una suite incorrecta.

La documentación oficial de Kali explica el formato deb822 y las claves, y la wiki de Debian detalla el uso de signed-by. Son las dos fuentes que conviene leer antes de improvisar. Ninguna promesa de que todo saldrá bien en el primer intento: la compatibilidad depende del proyecto concreto.


Sobre el autor: DeiviSanzPlay — Soy David Sanz, Editor y Responsable de Contenidos. Mi trabajo consiste en revisar, corregir y mejorar los contenidos de este blog para que la información sea clara, útil y esté bien estructurada. Trabajo con diferentes temáticas y verticales, por lo que una parte importante de mi día a día es analizar cada contenido, cuidar la redacción y asegurar que el lector encuentre información de calidad. Me gusta prestar atención a los detalles. Desde una corrección de estilo hasta la organización de un artículo, todo cuenta cuando se trata de crear contenidos que realmente aporten valor y sean fáciles de entender. En este blog encontrarás artículos sobre diferentes temas y sectores. Mi responsabilidad es cuidar y supervisar cada contenido para que mantenga unos estándares de calidad y ofrezca una buena experiencia a quien nos visita. Porque para mí, un buen contenido no consiste únicamente en escribir. También hay que revisar, contrastar, ordenar y pensar en la persona que está al otro lado de la pantalla.

Perfiles verificables: Sitio web

Publicado el 1 de November de 2026. Última revisión: 1 de November de 2026.