Instalar Kali Linux en un portátil y conectarlo a Ubuntu Server

CIBERMURO · Laboratorio práctico · LAB-KALI-01

: un laboratorio real paso a paso

De la preparación del USB a la primera sesión SSH: una instalación documentada con errores reales de antivirus, particionado y conectividad Wi-Fi.


 

Fecha de la práctica: 15 de octubre de 2026 · Entorno: equipos propios, red local · Nivel: intermedio inicial

No hace falta comenzar con una gran infraestructura para aprender seguridad de redes. En esta práctica se utiliza un Dell Latitude E7250 con Kali Linux y un GEEKOM A5 con Ubuntu Server. El primero actúa como estación de administración y análisis; el segundo proporciona un sistema Linux al que se accede de forma remota. El resultado final es concreto y verificable: los dos equipos se comunican por una red GL.iNet y se establece una sesión SSH autenticada.

Alcance: este artículo documenta una instalación y pruebas realizadas en equipos propios. Las direcciones IP son ejemplos de una red privada y pueden cambiar porque se asignan mediante DHCP. No se realizan pruebas ofensivas contra terceros.

1. Equipos y esquema de red

ElementoFunción en el laboratorio
Dell Latitude E7250Kali Linux 2026.2, escritorio Xfce, SSD Samsung de 256 GB; estación de trabajo
GEEKOM A5Ubuntu Server 26.04.1 LTS; equipo remoto de prácticas
GL.iNet AXT1800Red Wi-Fi del laboratorio y asignación de direcciones mediante DHCP
Memoria USB de 64 GBMedio de instalación preparado con Rufus
Dell · Kali Linux192.168.8.3Cliente SSH
Router GL.iNet192.168.8.1Red local
GEEKOM · Ubuntu192.168.8.2Servidor SSH
Esquema final comprobado en la sesión. Se trata de una red privada; la separación completa respecto a la red doméstica requiere revisar también las reglas de enrutamiento y cortafuegos.

2. USB de Kali: Rufus, modo DD y alerta de Defender

Se utiliza la imagen de instalación kali-linux-2026.2-installer-amd64.iso, no una imagen Live. Se selecciona la memoria USB en Rufus, se indica la ISO y se inicia la grabación.

En el primer intento, Rufus trabaja en modo ISO y Microsoft Defender detecta el paquete commix_4.1-0kali1_all.deb, incluido entre los archivos de la distribución. Commix es una herramienta de evaluación de vulnerabilidades de inyección de comandos. Las herramientas de pruebas de penetración pueden generar alertas antivirus debido a sus capacidades, pero una alerta no permite asegurar por sí sola que el archivo sea inofensivo (Kali Linux, 2025a; Kali Linux, s. f.).

Medida de seguridad: no se desactiva Defender ni se permite indiscriminadamente una detección grave. Se comprueba que la imagen proceda de la fuente oficial y se recomienda verificar su hash SHA-256 antes de instalarla. En esta sesión no queda documentado el resultado de esa verificación, por lo que no se presenta como una prueba completada.

Para calcular el hash de una ISO desde PowerShell, se utiliza:

Get-FileHash "C:
uta\kali-linux-2026.2-installer-amd64.iso" -Algorithm SHA256

El resultado se compara con el publicado para esa descarga en la página oficial de Kali. La documentación de Kali recomienda modo Imagen DD cuando Rufus ofrece la elección entre ISO y DD, por su mejor compatibilidad con determinados sistemas (Kali Linux, 2025a, 2026).

Se repite la grabación en modo DD y Rufus finaliza sin errores visibles.

3. Instalación de Kali y particionado LVM

Con la memoria USB conectada al Dell, se abre el menú de arranque mediante F12 y se selecciona Graphical install. El asistente solicita el idioma, la configuración de red y una cuenta de usuario normal.

Advertencia: en esta práctica se sustituye por completo el sistema anterior del Dell. Elegir el disco entero y confirmar la escritura de particiones elimina la instalación anterior y puede hacer irrecuperables los datos. Antes de reproducir el procedimiento se realiza una copia de seguridad y se comprueba cuidadosamente la unidad de destino.

En el particionado se elige Guided – use entire disk and set up LVM y se identifica el SSD Samsung interno de 256,1 GB. Se mantiene la opción All files in one partition para el sistema. Esta configuración permite utilizar LVM sin separar el directorio personal en un volumen propio. No se selecciona cifrado del disco.

La instalación permite seleccionar Xfce como escritorio, junto con las colecciones top10 y default de herramientas de Kali. Después de finalizar y arrancar el sistema, se comprueba la instalación con:

hostnamectl
lsblk -f
ip -br address
Elemento del SSDFunción comprobada
/dev/sda1Partición FAT32 montada en /boot/efi
/dev/sda2Partición ext4 para /boot
/dev/sda3Volumen físico LVM
vg-rootVolumen lógico ext4 montado en /
vg-swap_1Volumen lógico de intercambio

El resultado de lsblk -f confirma que el sistema se inicia desde el SSD y que los volúmenes lógicos están activos. LVM facilita la administración del almacenamiento, pero no equivale a cifrar el disco (Kali Linux, 2025b).

4. Una incidencia real: los dos equipos no se comunican

La primera conexión se realiza sobre la red Wi-Fi de Movistar. Kali recibe la dirección 192.168.1.58 y Ubuntu Server utiliza 192.168.1.44. Ambos equipos indican la misma dirección BSSID del punto de acceso; sin embargo, el ping falla en ambos sentidos.

ping -c 4 192.168.1.44
ip neigh show 192.168.1.44

Desde Kali aparece el mensaje Destination Host Unreachable y la tabla de vecinos muestra:

192.168.1.44 dev wlan0 FAILED

Este último resultado indica que la resolución de la dirección de enlace del vecino no concluye correctamente. El comando ip neigh permite consultar esos estados de vecindad en Linux (iproute2, s. f.).

La investigación considera una posible limitación de comunicación entre clientes Wi-Fi y la participación de un amplificador Smart WiFi 6 de Movistar. La causa exacta no se demuestra. Por ello, no se afirma que exista un fallo de Kali, que el repetidor sea defectuoso ni que una función de aislamiento esté realmente activada.

Lección práctica: disponer de una dirección IP y poder comunicarse con la puerta de enlace no garantiza que dos dispositivos de la misma subred consigan comunicarse entre sí. El diagnóstico empieza por interfaces, rutas, ARP y conectividad, antes de culpar al servicio SSH.

5. Solución práctica: ambos equipos en GL.iNet

Se decide conectar los dos equipos a la red principal del GL.iNet AXT1800, con SSID GL-AXT1800-116. Kali recibe por DHCP 192.168.8.112/24 y utiliza 192.168.8.1 como puerta de enlace.

En el GEEKOM, la conexión inalámbrica de Ubuntu Server se gestiona mediante Netplan y el archivo /etc/netplan/00-installer-config.yaml. Antes de modificarlo se conserva una copia de seguridad:

sudo cp /etc/netplan/00-installer-config.yaml /root/netplan.bak

Se actualiza el bloque Wi-Fi correspondiente a la interfaz wlp3s0. El siguiente fragmento es un ejemplo de estructura dentro del apartado network:; se conserva cualquier otra sección existente del archivo, como la configuración Ethernet:

wifis:
  wlp3s0:
    access-points:
      "GL-AXT1800-116":
        password: "CONTRASENA_WIFI_AQUI"
    dhcp4: true

Los espacios son fundamentales en YAML: password: se indenta debajo del nombre de la red, mientras que dhcp4: queda al mismo nivel que access-points:. Durante la práctica, Netplan detecta errores de indentación que se corrigen antes de aplicar los cambios. Netplan documenta esta sintaxis para conexiones Wi-Fi con contraseña (Netplan, s. f.-a).

En la consola local del servidor se validan y aplican los ajustes:

sudo netplan generate
sudo netplan apply
ip -br address

El servidor obtiene 192.168.8.241/24. A continuación, desde Kali se comprueba la comunicación:

ping -c 4 192.168.8.241
Resultado verificado: 4 paquetes enviados, 4 recibidos y 0 % de pérdidas. La comunicación IP directa entre Kali Linux y Ubuntu Server funciona en la red GL.iNet. El cambio de red resuelve el problema práctico, aunque no identifica de forma definitiva la causa del fallo en Movistar.

Como el archivo de Netplan contiene una contraseña, se recomienda restringir sus permisos al administrador:

sudo chmod 600 /etc/netplan/00-installer-config.yaml

Este endurecimiento se plantea como recomendación para revisar, no como un paso cuya ejecución haya quedado registrada (Netplan, s. f.-b).

6. Acceso remoto: primera conexión SSH

Una vez que ambos sistemas se alcanzan por red, se comprueba el estado del servicio SSH en Ubuntu Server:

systemctl is-active ssh

El servicio aparece inicialmente como inactive. Se inicia y se habilita para los siguientes arranques:

sudo systemctl enable --now ssh

Desde la terminal de Kali se abre la conexión utilizando el nombre de usuario del servidor:

ssh USUARIO_DEL_SERVIDOR@192.168.8.241

En la primera conexión, el cliente presenta la huella de la clave de host ED25519 y solicita confirmación. La práctica registra que se acepta el aviso y se inicia sesión correctamente; no se dispone de una verificación independiente de esa huella. Como procedimiento recomendable, antes de aceptarla se compara con la huella obtenida directamente en la consola del servidor:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Después de la autenticación aparece el mensaje de bienvenida de Ubuntu Server 26.04.1 LTS y la terminal remota. Esta es la prueba final de que el acceso SSH funciona. OpenSSH proporciona sesiones remotas cifradas y autenticadas (Canonical, s. f.).

Objetivo conseguido: desde el Dell con Kali se accede a una sesión de usuario de Ubuntu Server en el GEEKOM mediante la red GL.iNet. No se requiere utilizar el teclado ni la pantalla conectados físicamente al servidor para las tareas habituales de terminal.

7. Resultados, limitaciones y siguiente práctica

Esta primera sesión deja un laboratorio Linux funcional con dos máquinas físicas. La instalación de Kali se verifica, el particionado LVM queda identificado, el problema de conectividad se investiga con herramientas de red y el acceso SSH se confirma de manera práctica.

La experiencia también muestra la importancia de no presentar como hechos las hipótesis de diagnóstico: el repetidor Movistar es un elemento investigado, no un culpable demostrado; la advertencia de Defender requiere verificar el origen del archivo; y un ping satisfactorio confirma conectividad, pero no sustituye una revisión de la seguridad de la red.

Próximos pasos en CIBERMURO

  1. Reservar mediante DHCP la IP del servidor en el GL.iNet y evitar cambios inesperados de dirección.
  2. Verificar la clave de host SSH y configurar autenticación por claves públicas, manteniendo una vía de recuperación.
  3. Revisar actualizaciones, permisos, firewall y exposición de servicios en Ubuntu Server.
  4. Cambiar la contraseña Wi-Fi visible accidentalmente en una captura de la sesión y revisar el material antes de publicarlo.
  5. Realizar una primera práctica de descubrimiento de dispositivos y servicios solo en los equipos del laboratorio.

Conclusión: un laboratorio útil no consiste únicamente en instalar Kali Linux: se construye comprobando el almacenamiento, entendiendo cómo se comunican los equipos, resolviendo incidencias y estableciendo un acceso remoto verificable. El siguiente paso consiste en reforzar ese acceso y comenzar las pruebas de seguridad autorizadas.

Ref

Canonical. (s. f.). OpenSSH server. Ubuntu Server documentation. https://ubuntu.com/server/docs/how-to/security/openssh-server/

iproute2. (s. f.). ip-neighbour(8) — Linux manual page. Linux man-pages. https://man7.org/linux/man-pages/man8/ip-neighbour.8.html

Kali Linux. (s. f.). Commix: command injection and exploitation tool. Kali Linux Bug Tracker. https://bugs.kali.org/view.php?id=2201

Kali Linux. (2025a). Making a Kali bootable USB drive on Windows. https://www.kali.org/docs/usb/live-usb-install-with-windows/

Kali Linux. (2025b). Installing Kali Linux. https://www.kali.org/docs/installation/hard-disk-install/

Kali Linux. (2026). Downloading Kali Linux. https://www.kali.org/docs/introduction/download-official-kali-linux-images/

Netplan. (s. f.-a). Examples. https://netplan.readthedocs.io/en/stable/examples/

Netplan. (s. f.-b). Netplan security. https://netplan.readthedocs.io/en/stable/security/


CIBERMURO · LAB-KALI-01. Práctica realizada en un entorno propio con finalidad formativa. Se omiten deliberadamente contraseñas, huellas completas y otros datos de autenticación.