Seguir En Debian y Ubuntu, sshd escribe en /var/log/auth.log. En RHEL, Rocky, Alma y CentOS Stream, escribe en /var/log/secure. Si ninguno de estos archivos existe, tu sistema registra solo en el journal de systemd. Entonces, el comando que necesitas es journalctl -u ssh en sistemas basados en Debian, o journalctl -u sshd en la familia Red Hat, Fedora y Arch.
SSH es la puerta de entrada de casi todos los servidores Linux, por eso sus registros aparecen en casi todas las investigaciones de Linux. Prime Core tiene 11,632 reglas sigma que se ejecutan sobre registros de autenticación de Linux como estos, mapeados a 643 técnicas de MITRE ATT&CK. Entre ellas: fuerza bruta (T1110), inicios de sesión con credenciales robadas (T1078) y movimiento lateral sobre SSH (T1021.004). A continuación, cómo encontrar tus registros sshd, exportarlos, sanitizarlos e investigarlos gratis en LogTotal.
Resumido
| Familia de distribuciones | Archivo de registro | Comando del journal |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, instalaciones mínimas sin rsyslog | ninguno por defecto | journalctl -u sshd |
Antes de comenzar: ¿realmente puedes leerlos?
Los registros de autenticación están protegidos a propósito, por lo que una cuenta regular usualmente no obtiene nada.
- /var/log/auth.log en Debian y Ubuntu es legible por root y el grupo adm.
- /var/log/secure en la familia Red Hat es solo para root.
- El journal del sistema está abierto a root y miembros de systemd-journal, adm y wheel. Los demás solo ven su propio journal de usuario. Si ejecutas journalctl -u ssh como un usuario normal, obtienes un resultado vacío y un indicio de que no estás viendo mensajes de otros usuarios. Eso es permisos, no un servidor silencioso.
La solución simple es sudo. Si estás configurando una cuenta solo para la recolección de registros, agrégala a adm o systemd-journal en lugar de dar acceso root. Nuestra [guía de permisos de registros de Linux] cubre los detalles.
Una cosa más antes de copiar cualquier cosa de un servidor: los registros de autenticación contienen nombres de usuario, IPs de origen y nombres de host. LogTotal sanitiza las cargas, pero verifica primero tu política de manejo de datos.
Paso 1: ¿Archivo, journal o ambos?
La tabla anterior muestra los valores predeterminados, y los valores predeterminados son exactamente lo que les gusta cambiar a las imágenes de la nube y los scripts de endurecimiento. Dedica diez segundos a verificar:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Si aparece un archivo y rsyslog está activo, tienes ambos: rsyslog copia mensajes del journal en un archivo de texto plano. Cualquiera de las fuentes funciona, y el archivo es más fácil de copiar.
Si no hay archivo, rsyslog simplemente no está instalado. Eso es lo normal ahora: desde Debian 12, rsyslog ya no es parte de una instalación predeterminada, por lo que una instalación fresca de Debian no tiene auth.log en absoluto. Fedora y Arch han funcionado de esta manera durante años. Pasa al Paso 2b.
Mientras estás aquí, comprueba si el journal sobrevive a un reinicio:
ls -d /var/log/journal
Si ese directorio no existe, journald mantiene los registros en memoria en /run/log/journal, y un reinicio los borra. En una máquina que estás investigando, eso vale la pena saber antes de que alguien decida «solo reiniciarla».
Otro punto más para el trabajo en incidentes: si la caja podría estar comprometida, sus registros locales también podrían estarlo. Borrar o editar auth.log es un paso clásico de limpieza. Si el servidor reenvía registros a un SIEM, exporta desde allí también y compara. Nuestra [guía de exportación de Splunk] muestra cómo.
Paso 2a: Exportar desde auth.log o secure
El archivo actual solo cubre los últimos días. Las entradas antiguas se encuentran en archivos rotados junto a él. En Debian y Ubuntu se ven como auth.log.1, auth.log.2.gz, etc. En la familia Red Hat llevan una fecha, como secure-20261012. Si el incidente comenzó la semana pasada, también necesitas esos.
Esto extrae líneas de sshd de los archivos actuales y rotados, de las más antiguas a las más recientes, en un solo archivo:
# Debian / Ubuntu
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/auth.log*) > web-03_sshd.log
# RHEL / Rocky / Alma
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/secure*) > web-03_sshd.log
zgrep lee tanto archivos planos como comprimidos, por lo que no tienes que descomprimir nada. ls -tr ordena por tiempo de modificación, de modo que el archivo más antiguo va primero y la salida se mantiene aproximadamente cronológica. El patrón sshd también coincide con sshd-session, lo cual es importante en sistemas más nuevos (ver Paso 2b).
¿Por qué filtrar en absoluto? Además de reducir el ruido, auth.log también registra sudo, y las líneas sudo incluyen líneas de comando completas. Las personas ocasionalmente escriben contraseñas en esas. Filtrar a sshd mantiene eso fuera del archivo. La excepción es cuando estás investigando lo que hizo un atacante después de iniciar sesión. Entonces también querrás las líneas sudo: toma todo el archivo y deja que el paso de sanitización de LogTotal haga su trabajo.
Revisión rápida antes de subir:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Observa las marcas de tiempo. Dependiendo de la configuración de rsyslog, son o bien syslog clásico (Oct 19 10:15:01, sin año, sin zona horaria) o ISO 8601 completo. Si son clásicos, toma nota de la zona horaria del servidor (timedatectl). La necesitarás en el momento en que intentes alinear estos eventos con cualquier otra cosa.
Paso 2b: Exportar desde el journal de systemd
En sistemas solo con journal, este es todo el trabajo:
sudo journalctl -u ssh -u sshd
–since «2026-10-19 00:00» –until «2026-10-20 00:00»
–no-pager -o short-iso > web-03_sshd.log
Algunas elecciones aquí son deliberadas.
Ambos nombres de unidad. El servicio se llama ssh en Debian y Ubuntu y sshd casi en todos los demás lugares. journalctl combina repetidos flags -u con OR, por lo que el mismo comando funciona en ambas familias.
Filtra por unidad, no por etiqueta. Muchos guías antiguas usan journalctl -t sshd. Desde OpenSSH 9.8, el servidor se divide en dos binarios, y los mensajes por conexión, incluidos los inicios de sesión, son etiquetados sshd-session en lugar de sshd. Filtrar por etiqueta, y pierdes exactamente las líneas por las que viniste. Esto rompió muchos setups de fail2ban y sshguard cuando 9.8 llegó en 2024. RHEL 10 y otras versiones actuales envían OpenSSH 9.8 o más reciente. Filtrar por unidad captura cada proceso que pertenece al servicio, comoquiera que se llame.
-o short-iso. Te da una línea al estilo syslog con una marca de tiempo ISO 8601 completa, año y zona horaria incluidos, para que no tengas que adivinar. Si prefieres mantener cada campo del journal (PID, boot ID, nombre de host, etc.), usa -o json, que escribe un objeto JSON por línea. El archivo se hace más grande, pero no se pierde nada.
Los filtros de tiempo también aceptan valores relativos: –since «hace 2 horas» o –since ayer. Con un journal persistente, -b -1 limita la salida al arranque anterior, lo que ayuda si el servidor se reinició después del incidente.
No copies los archivos binarios .journal de /var/log/journal y los subas. LogTotal lee texto y JSON, y los archivos de journal no son ninguno de ellos.
Qué buscar una vez que tienes el archivo
La mayoría de las líneas de sshd caen en un puñado de patrones:
| Línea comienza con | Qué significa |
|---|---|
| Contraseña fallida para <usuario> desde <ip> | Contraseña incorrecta para una cuenta que existe |
| Usuario inválido <usuario> desde <ip> | El nombre de usuario no existe; típico de escáneres que ciclan por admin, test, oracle |
| Contraseña aceptada para / Clave pública aceptada para | Un inicio de sesión exitoso; la línea de clave pública también incluye la huella SHA256 de la clave |
| Desconectando usuario que se está autenticando … Demasiados fallos de autenticación | El cliente alcanzó MaxAuthTries |
| Conexión cerrada por <ip> … [preauth] | Caído antes de la autenticación, usualmente escáneres y capturadores de banner |
| pam_unix(sshd:session): sesión abierta para el usuario | La sesión realmente comenzó |
La secuencia por la que vale la pena detenerse: una serie de líneas de Contraseña fallida o Usuario inválido desde una IP, luego una Aceptada de la misma IP. Eso es una fuerza bruta que funcionó. Cerca detrás: una Aceptada para una cuenta de servicio, desde una dirección que nadie reconoce, a una hora que nadie trabaja.
En OpenSSH 9.8 y posteriores también puedes ver mensajes sobre penalizaciones: sshd ahora rechaza temporalmente direcciones que continúan fallando la autenticación. Trátalas como un síntoma. Te dicen que alguien estuvo golpeando el puerto, no que alguien haya ingresado.
Subir, sanear y revisar en LogTotal
Leer algunas cientos de líneas a simple vista está bien. Leer 40,000 no lo está. LogTotal es el servicio gratuito de SOC Prime para ejecutar lógica de detección contra un archivo de registro sin configurar nada. Saneece lo que subas y no conserva tus archivos.
- Subir. Abre logtotal.com y coloca web-03_sshd.log.
- Sanear. Observa el resultado antes de continuar. Sabes cuáles de esos nombres son sensibles en tu entorno.
- Revisar.
Cuando sale mal
| Síntoma | Causa probable | Fix |
|---|---|---|
| No existe tal archivo o directorio para auth.log | rsyslog no está instalado (predeterminado desde Debian 12) | Usa journalctl, Paso 2b |
| Permiso denegado en el archivo de registro | auth.log es solo para adm, secure es solo para root | sudo, o agrega la cuenta a adm |
| journalctl -u ssh no devuelve nada, con un indicio sobre otros usuarios | No estás en systemd-journal, adm o wheel | sudo, o agrega la cuenta a systemd-journal |
| journalctl -u ssh no devuelve nada como root | Nombre de unidad incorrecto para esta distribución | Usa -u ssh -u sshd |
| Las desconexiones están ahí, pero no las líneas Aceptadas | Filtrando por etiqueta (-t sshd) en OpenSSH 9.8+ | Filtra por unidad en su lugar |
| Nada más antiguo que el último reinicio | Journal volátil; sin /var/log/journal | Los registros antiguos ya no están; verifica tu SIEM o reenviador de registros |
| El archivo solo cubre unos días | No se incluyeron los archivos rotados | Usa el comando zgrep con auth.log* o secure* |
| Las marcas de tiempo no se alinean con otras fuentes | Las marcas de tiempo syslog clásicas no llevan zona horaria | Anota la zona horaria del servidor, o exporta con -o short-iso |
FAQ
¿Dónde están los registros SSH en Ubuntu?
En una instalación estándar de Ubuntu, en /var/log/auth.log, además del journal (journalctl -u ssh). Las imágenes mínimas en la nube a veces dejan fuera rsyslog. Si el archivo no está allí, usa el journal.
¿Cómo veo solo los inicios de sesión SSH fallidos?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ en sistemas con journal, o sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* cuando tienes el archivo. Para algo más que un vistazo rápido, sube el registro completo de sshd en su lugar. Los fracasos solo significan algo junto a los éxitos.
¿Qué pasa con last y lastb?
Leen los registros binarios de inicio de sesión en /var/log/wtmp y /var/log/btmp. Son útiles para un vistazo rápido a quién inició sesión, pero llevan mucho menos detalle que el registro propio de sshd, y son igual de fáciles para que un intruso los manipule.
¿Cómo recojo registros de sshd de varios servidores a la vez?
Para una sola vez, un bucle lo hace: for h in web-01 web-02 web-03; do ssh «$h» «sudo journalctl -u ssh -u sshd –since yesterday -o short-iso –no-pager» > «${h}_sshd.log» done Eso necesita que sudo funcione sin un requerimiento de contraseña en el lado remoto. De lo contrario, agrega -t a ssh y escríbela cada vez. Si estás haciendo esto más de una vez por trimestre, envía los registros a un SIEM en su lugar.
¿Es seguro subir registros de sshd a una herramienta en línea?
LogTotal sanitiza las cargas antes del análisis y no retiene archivos; nuestra [guía de sanitización] muestra qué se enmascara. Las reglas de manejo de datos de tu organización siguen siendo lo primero.
Próximo paso
¿Tienes el archivo? Súbelo a LogTotal y ve qué hacen esas 11,632 reglas sigma con él. Si deseas que la misma lógica de detección se ejecute en todos tus servidores Linux, no un archivo a la vez.
Referencias
- Notas de lanzamiento de Debian 12: cambios en el registro del sistema
- Notas de lanzamiento de OpenSSH 9.8: la división sshd / sshd-session y las etiquetas de log cambiadas
- journalctl(1): filtros de unidad, formatos de salida, grupos de acceso a journal
- journald.conf(5): almacenamiento persistente vs. volátil
