¿Qué evidencia deja un acceso SSH correcto, un intento fallido o una autenticación mediante clave pública? En lugar de limitarme a consultar documentación, lo comprobé en mi propio laboratorio con dos equipos físicos: un Dell Latitude E7250 con Kali Linux y un servidor Ubuntu conectado a la misma red.
La sesión forma parte de las prácticas técnicas que desarrollo alrededor de CIBERMURO, pero aquí documento el proceso y sus evidencias con un enfoque de administración Linux, autenticación y análisis defensivo. La diferencia es importante: una cosa es saber ejecutar un comando y otra demostrar, a partir de los registros del servidor, qué ocurrió realmente.
Entorno y objetivos
- Cliente SSH: Dell Latitude E7250 con Kali Linux, IP
192.168.8.112. - Servidor: Ubuntu Server
ch1, IP192.168.8.241. - Red: laboratorio propio mediante router GL.iNet.
- Servicio: OpenSSH, puerto TCP 22.
- Usuario de prueba:
ioli26.
La conectividad y el servicio SSH ya habían sido comprobados en una práctica anterior. Esta vez el objetivo era relacionar acciones concretas con eventos de autenticación, crear un par de claves Ed25519 y verificar el cambio de método sin arriesgar el acceso al servidor.
Alcance y precauciones: solo se utilizaron equipos propios. Mantuve abierta una sesión administrativa durante las pruebas, no desactivé la autenticación por contraseña y no modifiqué UFW. La clave privada permaneció en Kali y no se publicó.
1. Una autenticación correcta deja un registro identificable
Desde Kali abrí una sesión SSH habitual:
ssh ioli26@192.168.8.241Tras introducir la contraseña del usuario, accedí al servidor. Ya dentro de Ubuntu consulté el diario del servicio:
sudo journalctl -u ssh -n 20 --no-pagerEntre las líneas obtenidas apareció un evento como este, correspondiente a la prueba:
Oct 22 19:03:22 ch1 sshd-session[14142]: Accepted password for ioli26 from 192.168.8.112 port 34528 ssh2El mensaje reúne varios datos relevantes en una sola línea: fecha y hora, nombre del servidor, proceso, resultado Accepted password, usuario, dirección IP de origen y puerto de origen. Ese puerto 34528 es el usado por el cliente para la conexión; no es el puerto 22 en el que escucha el servidor.
2. Generar errores controlados y encontrarlos en journalctl
Para estudiar el comportamiento ante un rechazo, abrí otra terminal local en Kali y ejecuté:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password -o NumberOfPasswordPrompts=1 ioli26@192.168.8.241Introduje una contraseña deliberadamente incorrecta. El cliente respondió:
Permission denied (publickey,password).Repetí una segunda vez la misma prueba, sin automatizar intentos ni realizar ataques de fuerza bruta. En Ubuntu consulté otra vez los registros:
sudo journalctl -u ssh -n 30 --no-pagerEncontré eventos pam_unix(sshd:auth): authentication failure y Failed password for ioli26 from 192.168.8.112, aproximadamente a las 19:37 y 19:42 del 22 de octubre, según los registros capturados.
Es una diferencia fundamental para quien investiga incidentes: el cliente únicamente informa de que no pudo entrar, pero el servidor conserva información que permite correlacionar usuario, origen, momento y resultado. Aun así, estos eventos, aislados, no prueban una intrusión: en este caso sabemos que fueron fallos generados deliberadamente.
3. Verificar desde qué máquina estamos consultando los registros
Durante la sesión también cometí un error útil para el aprendizaje: ejecuté journalctl -u ssh en el propio Kali y apareció -- No entries --. No era una prueba de que el servidor no hubiera registrado los fallos. Simplemente estaba consultando la máquina equivocada.
Kali era el cliente; Ubuntu era el servidor que verificaba la autenticación. Para esta investigación, el registro relevante estaba en ch1. Es una comprobación pequeña, pero evita interpretaciones falsas durante el análisis de logs.
4. Crear un par de claves Ed25519 específico para el laboratorio
Antes de generar nuevas claves comprobé el directorio SSH en Kali:
ls -la ~/.sshHabía archivos como known_hosts, pero no aparecía el par de claves Ed25519 que necesitaba para esta prueba. Generé uno con un nombre identificable:
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_cibermuro -C "cibermuro-kali-ubuntu"El comando creó estos dos archivos:
~/.ssh/id_ed25519_cibermuro: clave privada, que debe permanecer protegida en Kali.~/.ssh/id_ed25519_cibermuro.pub: clave pública, destinada a autorizar el acceso en Ubuntu.
Protegí la clave privada mediante una passphrase. Esa frase protege la clave almacenada localmente y no es la contraseña de la cuenta Ubuntu.
5. Instalar la clave pública y probar de verdad el nuevo método
Desde Kali transferí solo la clave pública al usuario autorizado del servidor:
ssh-copy-id -i ~/.ssh/id_ed25519_cibermuro.pub ioli26@192.168.8.241El procedimiento solicitó la contraseña del usuario Ubuntu para autorizar la operación y terminó con el mensaje:
Number of key(s) added: 1Esta operación añade la clave pública al conjunto de claves autorizadas de la cuenta remota. No copia la clave privada al servidor.
La prueba decisiva fue iniciar una nueva sesión impidiendo que se recurriera a la contraseña de la cuenta:
ssh -i ~/.ssh/id_ed25519_cibermuro -o IdentitiesOnly=yes -o PasswordAuthentication=no ioli26@192.168.8.241El cliente pidió la passphrase de la clave privada y, después, mostró la bienvenida de Ubuntu. La sesión se abrió correctamente.
Para no quedarme solo con la observación del cliente, busqué la evidencia en los logs del servidor:
sudo journalctl -u ssh -n 15 --no-pagerEl registro mostró Accepted publickey for ioli26 from 192.168.8.112 e identificó una clave de tipo ED25519. Así pude confirmar que la autenticación aceptada había utilizado la clave pública autorizada, en lugar de darlo por supuesto.
6. Comprobar la configuración efectiva sin cerrar otras vías de acceso
La última comprobación fue consultar la configuración efectiva general del servidor OpenSSH:
sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication) 'El resultado obtenido fue:
pubkeyauthentication yes
passwordauthentication yesAmbos métodos seguían habilitados. Esto era intencionado: el objetivo de la sesión no era endurecer todavía el acceso eliminando contraseñas, sino implementar y verificar una alternativa basada en claves, sin perder el acceso administrativo ya probado.
La configuración general puede tener condiciones adicionales por usuario u origen; aquí, además de consultar sshd -T, contamos con pruebas reales de acceso por ambos métodos.
Resultados obtenidos
| Acción ejecutada | Evidencia comprobada |
|---|---|
| Acceso correcto desde Kali con contraseña | Accepted password |
| Dos intentos fallidos controlados | Dos eventos Failed password y registros PAM relacionados |
| Creación del par Ed25519 | Archivos de clave privada y pública generados en Kali |
| Instalación de la pública en Ubuntu | Number of key(s) added: 1 |
| Entrada mediante clave | Sesión abierta y evento Accepted publickey |
| Configuración efectiva consultada | pubkeyauthentication yes y passwordauthentication yes |
Qué demuestra esta práctica (y qué no)
Demuestra que OpenSSH registra accesos aceptados y rechazados con información temporal, de usuario y origen; que los eventos pueden correlacionarse con las acciones hechas desde Kali; y que una autenticación mediante clave Ed25519 puede implantarse y comprobarse desde ambos extremos de la conexión.
No demuestra que Ubuntu Server sea invulnerable, que cualquier intento fallido sea un ataque o que la autenticación por contraseña haya quedado eliminada. Tampoco implica que usar una clave SSH equivalga por sí solo a disponer de autenticación multifactor.
Si en una fase posterior se plantea desactivar contraseñas, habrá que validar primero accesos de recuperación, gestión de claves y copias de seguridad. No era el objetivo de esta sesión.
Aplicación profesional: logs, identidad y Blue Team
La práctica une tres áreas que suelen estudiarse por separado: administración remota Linux, autenticación e investigación de eventos. En un entorno de operaciones de seguridad, la secuencia Failed password / Accepted password / Accepted publickey puede servir para formular hipótesis, contrastar actividad conocida y construir detecciones. Siempre será necesario aportar contexto antes de concluir que existe un incidente.
Para mi portfolio, lo relevante es haber trabajado con dos equipos reales, generado eventos controlados, recuperado su evidencia, interpretado sus límites y configurado un mecanismo de acceso sin perder la administración del servidor.
En esta sesión no me limité a seguir una receta para crear claves SSH. Primero observé cómo Ubuntu registraba un acceso válido y dos rechazos; después instalé una clave Ed25519 desde Kali y confirmé en los registros que la nueva conexión había sido aceptada mediante publickey.
Es el criterio que intento aplicar en mis laboratorios: ejecutar, comprobar, obtener evidencia y solo entonces interpretar. Es también la base metodológica de CIBERMURO, mi proyecto de seguridad digital práctica orientado principalmente a usuarios no técnicos.
Práctica: [LAB-BT-03] · Fecha: 22/10/2026 · Entorno: Kali Linux (Dell E7250) → Ubuntu Server (ch1).
Referencias: Ubuntu Server — OpenSSH · OpenSSH — documentación oficial · systemd — journalctl.
Acerca del autor
