WardtermCliente SSH
ES
Descargar

Cómo ver los intentos de inicio de sesión SSH en Linux

Ejecuta sudo journalctl -u ssh --since today en Debian y Ubuntu, o -u sshd en Red Hat y Fedora. Donde existan logs de texto, mira en /var/log/auth.log o /var/log/secure. Las líneas con Accepted son accesos reales, y Failed password o Invalid user son intentos. Usa who para las sesiones actuales, last para las pasadas y sudo lastb para los fallos, donde esos comandos existan.

Actualizada el . Líneas de log y comandos grep ejecutados con OpenSSH 10.0 en Debian 13 con rsyslog.

Dónde están los logs

SistemaLee los logs con
Debian o Ubuntu, con systemdsudo journalctl -u ssh
Red Hat o Fedora, con systemdsudo journalctl -u sshd
Debian o Ubuntu con rsyslog/var/log/auth.log
Familia Red Hat con rsyslog/var/log/secure

Puede que falte un archivo, y es normal: Debian no instala rsyslog por defecto desde la versión 12, así que un Debian nuevo suele tener solo el journal.

Con journalctl

sudo journalctl -u ssh --since today
sudo journalctl -u ssh --since "2 hours ago" --grep 'Accepted|Failed|Invalid'
sudo journalctl -u ssh -f

-f sigue las líneas nuevas según llegan, lo que ayuda cuando pruebas un inicio de sesión.

Con los archivos de texto

sudo grep Accepted /var/log/auth.log
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log

Las líneas más antiguas pueden estar en /var/log/auth.log.1 y en los archivos comprimidos que hay junto a él. Desde OpenSSH 9.8 estas líneas llevan el nombre sshd-session en lugar de sshd, así que un filtro o script que busque sshd[ no encuentra nada en un sistema actual.

Qué significan las líneas

Todas son líneas reales de un servidor de pruebas, con la dirección cambiada.

sshd-session[1329]: Accepted publickey for user from 203.0.113.10 port 43594 ssh2: ED25519 SHA256:NxFS05Q+k1zf...
sshd-session[1339]: Accepted password for user from 203.0.113.10 port 43598 ssh2

Alguien inició sesión. Son las líneas que hay que leer primero. La primera muestra qué clave se usó. Consulta cómo revocar una clave si encuentras una que no quieres.

sshd-session[1311]: Failed password for user from 203.0.113.10 port 33598 ssh2

Una contraseña incorrecta para una cuenta que existe.

sshd-session[1317]: Invalid user admin from 203.0.113.10 port 50898
sshd-session[1317]: Failed password for invalid user admin from 203.0.113.10 port 50898 ssh2

Un intento sobre una cuenta que no existe en este sistema. Así se ve la mayor parte del adivinado automático.

sshd-session[1326]: Connection closed by authenticating user user 203.0.113.10 port 43590 [preauth]

El cliente se rindió durante el inicio de sesión. Con claves, normalmente significa que se ofreció una clave y no se aceptó. Por defecto el log no dice cuál.

sshd-session[1317]: error: maximum authentication attempts exceeded for invalid user admin from 203.0.113.10 port 50898 ssh2 [preauth]

El cliente superó MaxAuthTries y fue desconectado.

Cuenta los intentos por dirección y usuario

# Which addresses
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

# Which user names they try
sudo grep -oE 'Invalid user [^ ]+' /var/log/auth.log \
  | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

Un solo intento suele producir una línea Failed y otra Invalid user, así que toma los números como orientación. Con el journal, empieza la primera tubería así:

sudo journalctl -u ssh --since today --no-pager | grep -E 'Failed password|Invalid user' \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

Mira quién está conectado ahora

who
w

Ambos listan las sesiones con terminal. Un comando ejecutado como ssh server somecommand, una transferencia de archivos o un túnel no aparecen. Para ver todas las conexiones, incluidas esas:

sudo ss -tnp state established '( sport = :22 )'

Cambia 22 si tu servidor usa otro puerto. Vimos la conexión en esta lista cuando who no mostraba nada.

Sesiones pasadas: last y lastb

last -a -n 20
sudo lastb -a -n 20

last lee los accesos pasados y lastb los fallidos. -a pone la dirección en la última columna. En nuestras pruebas aparecieron dos límites:

  • last mostró solo las sesiones con terminal. Un acceso que solo ejecutó un comando no dejó nada, así que los archivos de log son el registro más completo.
  • En Debian 13 estos comandos han desaparecido. El paquete util-linux ya no incluye last ni lastb. Instala wtmpdb y libpam-wtmpdb para recuperar last, lo que funcionó en nuestra prueba, para las sesiones posteriores a la instalación. Para los fallos no hay sustituto que lea el archivo antiguo. Las notas de la versión sugieren lslogins --failed, pero no mostró nada en nuestra prueba, así que usa los logs.

Ver qué clave fue rechazada

Para registrar también la huella de las claves que fallan, pon esto en un archivo de /etc/ssh/sshd_config.d/ y recarga:

LogLevel VERBOSE
sshd-session[1376]: Failed publickey for user from 203.0.113.10 port 43612 ssh2: RSA SHA256:R3PypHnQ7AMz...

Qué hacer con lo que encuentres

  • Muchos fallos desde muchas direcciones: es habitual en cualquier servidor abierto a internet. Si el servidor acepta solo claves, los intentos de adivinar contraseñas no pueden tener éxito. Consulta cómo desactivar el acceso con contraseña y, para reducir el ruido, fail2ban.
  • Una línea Accepted que no puedes explicar: tómatela en serio. Anota la hora, la dirección y la clave. Quita ese acceso, mira qué hizo la cuenta y, si no estás seguro de qué pasó, reconstruye el servidor desde un estado limpio.

Quien tiene root puede editar los logs locales, así que en los servidores que importan, envíalos también a otra máquina.

Para que adivinar contraseñas no sirva de nada, genera una clave SSH Ed25519 y acepta solo claves.

Preguntas

¿Cómo veo los intentos fallidos de acceso SSH?

En sistemas con systemd ejecuta sudo journalctl -u ssh --grep 'Failed|Invalid' (sshd en Red Hat). Con logs de texto, busca 'Failed password' en /var/log/auth.log o /var/log/secure con grep. sudo lastb lista los fallos donde está instalado.

¿Dónde está el log de SSH en Ubuntu?

En el journal, que se lee con sudo journalctl -u ssh, y en /var/log/auth.log cuando hay rsyslog, que en Ubuntu viene instalado por defecto.

¿Son un problema muchos accesos SSH fallidos?

En un servidor público son el ruido de fondo normal de los bots, y no pueden tener éxito si solo se aceptan claves. La línea que pide actuar es un Accepted que no sabes explicar.

Fuentes

Más en Proteger un servidor

Todas las guías