El registro de autenticación de Linux — sshd, lo que entra y lo que falla

Linux no tiene un canal de Seguridad como Windows: tiene archivos de texto que alimenta el servicio de registro del sistema. El de autenticación es el que importa para el turno, y cambia de nombre según la distribución: /var/log/auth.log en Debian y Ubuntu, /var/log/secure en Red Hat, CentOS y derivadas. Ahí van los intentos de acceso remoto, el uso de sudo, los cambios de usuario y las aperturas y cierres de sesión.

Cada línea empieza con la fecha, el nombre del equipo y el programa que la escribió —sshd, sudo, su, systemd-logind— seguido del mensaje. Ese nombre de programa es el primer filtro de cualquier búsqueda: no se lee «el log entero», se lee lo que escribió un programa concreto en una ventana concreta.

El servicio de acceso remoto escribe tres mensajes que resuelven la mayoría de los casos. Accepted: la sesión se abrió. Failed password: alguien probó una contraseña equivocada contra una cuenta que sí existe. Invalid user: el nombre de usuario ni siquiera está en la máquina.

La diferencia entre los dos últimos cambia la lectura igual que los códigos de estado en Windows. Una ráfaga de usuarios inválidos —admin, oracle, test, postgres— es alguien recorriendo una lista genérica contra cualquier servidor expuesto: ruido de internet, constante y casi siempre irrelevante. Una ráfaga de fallos de contraseña contra una cuenta real de la empresa es otra cosa: quien la lanza ya sabe a quién va, y eso significa que obtuvo el nombre en algún sitio.

El mensaje de sesión aceptada trae el método de autenticación, y ese dato decide el caso. Accepted password significa que alguien tecleó una contraseña correcta. Accepted publickey significa que presentó una clave privada cuya parte pública está en el archivo de claves autorizadas de esa cuenta, y el mensaje incluye además la huella de esa clave.

Ahí está la trampa que se cobra turnos enteros: una ráfaga de fallos de contraseña que termina en una aceptación por clave pública no es «la fuerza bruta funcionó». Es alguien que ya tenía la llave y, probablemente, la puso él mismo antes. En MITRE ATT&CK, añadirse una clave autorizada para volver cuando quiera es manipulación de cuentas por claves SSH (T1098.004), y es una de las persistencias más silenciosas que hay en Linux: no crea usuarios, no instala nada y sobrevive a cualquier cambio de contraseña.

En la consola tienes el registro de autenticación de los servidores Linux de Delta Cargo del 1 y el 2 de octubre. En el bastión del-lnx-bast01 hay una ráfaga de intentos desde una dirección externa y, al final, una sesión aceptada que no se abrió con contraseña. Encuentra con qué cuenta se abrió.