Cómo activar SSH en Kali Linux y asegurar la conexión

Para activar SSH en Kali Linux, comprueba que OpenSSH Server esté instalado, inicia el servicio y verifica la identidad del equipo antes de conectarte. Hazlo únicamente en tus equipos o en un laboratorio autorizado. No necesitas abrir el puerto del router a Internet para administrar Kali dentro de tu red.
Comprueba el servicio y el tipo de instalación
Estas instrucciones corresponden a Kali con systemd, instalado directamente o en una máquina virtual. NetHunter Rootless dentro de Termux tiene otro entorno: no apliques allí comandos de systemctl suponiendo que funcionan igual. Si necesitas preparar el laboratorio, consulta Kali en VMware o Kali en VirtualBox.
sudo apt update
sudo apt install openssh-server
systemctl status ssh.service ssh.socket --no-pager
El estado puede mostrar el servicio, el socket o ambos según la instalación. Un socket activo también puede mantener un puerto a la escucha aunque el proceso del servicio no esté ejecutándose continuamente. No actives dos mecanismos por costumbre ni interpretes un servicio detenido como prueba de que no hay acceso SSH.
Inicia SSH y localiza la dirección correcta
sudo systemctl start ssh.service
ip -br address
sudo ss -lntp
Identifica la dirección de la interfaz que comparte red con el cliente y comprueba qué direcciones y puerto escucha sshd. No copies la IP de una captura. En una VM, la configuración NAT o de solo anfitrión determina qué conexiones pueden llegar; una IP visible no demuestra que exista una ruta desde cualquier equipo.
Si quieres iniciar el servicio después de cada arranque, puedes habilitar ssh.service de forma deliberada. Para una práctica puntual basta con iniciarlo. Evita reglas de firewall que permitan acceso desde cualquier origen: limita el acceso a la red de administración según tu entorno.
Verifica la huella antes de iniciar sesión
Desde la consola de Kali, consulta la huella de su clave pública de host Ed25519, si ese archivo existe:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
En el cliente, ejecuta ssh seguido del usuario, el símbolo @ y la dirección real de Kali. Compara la huella presentada con la obtenida por un canal de confianza; acepta únicamente si corresponde. Si cambia inesperadamente una huella conocida, investiga la causa antes de borrar el registro de known_hosts.
Una clave de host identifica al servidor; la clave privada de tu usuario te autentica a ti. No compartas ninguna clave privada ni supongas que cifrar la conexión elimina la necesidad de verificar al otro extremo. Para repasar comandos y rutas, consulta la práctica de terminal de Linux.
Endurece el acceso sin quedarte fuera
- Cambia cualquier contraseña predeterminada y utiliza una cuenta de administración adecuada; evita el acceso directo de root.
- Configura una clave de usuario y comprueba que puedes abrir una segunda sesión con ella antes de deshabilitar contraseñas. Conserva acceso por consola.
- Revisa sshd_config y sus archivos incluidos: las opciones efectivas y las reglas Match pueden cambiar el resultado.
- Antes de recargar, comprueba la sintaxis con sudo sshd -t. Si muestra errores, corrígelos sin cerrar la sesión que funciona.
- Tras aplicar un cambio, prueba otra conexión y solo entonces cierra la anterior. No habilites UFW a ciegas sobre una sesión remota.
Las opciones PermitRootLogin no y PasswordAuthentication no tienen funciones distintas. La segunda no debe activarse hasta tener una vía alternativa de acceso comprobada; revisa también los métodos interactivos y las políticas de tu sistema. La guía de SSH en Ubuntu amplía la explicación de claves y permisos, aunque debes contrastar las diferencias de Kali.
Si no conecta o ya terminaste
Connection refused suele apuntar a un puerto sin servicio o a un rechazo; un tiempo de espera obliga a revisar ruta y filtros; Permission denied requiere comprobar usuario y autenticación. No abras todos los puertos para distinguirlos. Consulta el estado y los registros del servidor antes de cambiar más opciones.
journalctl -u ssh.service -n 50 --no-pager
Al terminar una práctica, puedes detener tanto el servicio como el socket con sudo systemctl stop ssh.service ssh.socket. Si los habilitaste para el arranque y ya no los necesitas, revisa también esa habilitación. Comprueba de nuevo los puertos a la escucha.
Capturas del procedimiento anterior
Se conservan las imágenes originales. Los nombres de interfaz, direcciones y estados que muestran son ejemplos de esa captura; utiliza los de tu equipo y verifica la huella antes de aceptarla.






Video de la versión anterior
El video se conserva como material de una versión anterior. Para las opciones y comprobaciones actuales, sigue el procedimiento escrito y la documentación oficial de esta guía.

Deja un comentario