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 los archivos existe, sus registros de sistema solo se guardan en el diario de systemd. Entonces, el comando que desea 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 principal 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 en 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 a través de SSH (T1021.004). A continuación se muestra cómo encontrar sus registros sshd, exportarlos, sanitizarlos e investigarlos gratis en LogTotal.
TL;DR
| Familia de distribuciones | Archivo de registro | Comando del diario |
|---|---|---|
| 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 | nada por defecto | journalctl -u sshd |
Antes de comenzar: ¿puede realmente leerlos?
Los registros de autenticación están bloqueados a propósito, por lo que una cuenta regular generalmente no obtiene nada de vuelta.
- /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 de root.
- El diario del sistema está abierto para root y para los miembros de systemd-journal, adm y wheel. Todos los demás solo ven su propio diario de usuario. Si ejecuta journalctl -u ssh como un usuario normal, obtiene un resultado vacío y un indicio de que no está viendo mensajes de otros usuarios. Eso es permisos, no un servidor silencioso.
La solución simple es sudo. Si está configurando una cuenta solo para la recopilación de registros, agréguela a adm o systemd-journal en lugar de proporcionar 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 sanea las cargas, pero primero verifique su política de manejo de datos.
Paso 1: ¿Archivo, diario o ambos?
La tabla anterior muestra los valores predeterminados, y los valores predeterminados son exactamente lo que las imágenes en la nube y los scripts de endurecimiento tienden a cambiar. Pase diez segundos verificando:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Si un archivo aparece y rsyslog está activo, tienes ambos: rsyslog copia los mensajes del diario 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. Esa es la norma ahora: desde Debian 12, rsyslog ya no es parte de una instalación por defecto, por lo que un nuevo equipo Debian no tiene auth.log en absoluto. Fedora y Arch han funcionado de esta manera durante años. Vaya al Paso 2b.
Mientras estás aquí, verifica si el diario sobrevive a un reinicio:
ls -d /var/log/journal
Si ese directorio no existe, journald mantiene los registros en memoria bajo /run/log/journal, y un reinicio los borra. En una máquina que está investigando, eso vale la pena saberlo antes de que alguien decida «solo reiniciarlo».
Otro punto más para el trabajo de incidentes: si la máquina 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 los registros a un SIEM, expórtelos desde allí también y compárelos. 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 más antiguas se encuentran en archivos rotados junto a él. En Debian y Ubuntu se ven como auth.log.1, auth.log.2.gz, y así sucesivamente. En la familia Red Hat llevan una fecha, como secure-20261012. Si el incidente comenzó la semana pasada, también necesita esos.
Esto extrae líneas de sshd de los archivos actuales y rotados, del más antiguo al más nuevo, 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 archivos normales y comprimidos por igual, por lo que no necesita desempaquetar nada. ls -tr ordena por tiempo de modificación, por lo que el archivo más antiguo va primero y la salida se mantiene aproximadamente en orden cronológico. El patrón sshd también coincide con sshd-session, lo cual importa en sistemas más nuevos (vea el Paso 2b).
¿Por qué filtrar en absoluto? Además de reducir el ruido, auth.log también registra sudo, y las líneas de sudo incluyen líneas de comando completas. A veces, las personas escriben contraseñas en ellas. Filtrar para sshd evita eso en el archivo. La excepción es cuando está investigando lo que un atacante hizo después de iniciar sesión. Entonces también quiere las líneas de sudo: tome el archivo completo y deje que el paso de saneamiento de LogTotal haga su trabajo.
Verificación rápida antes de cargar:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Observe las marcas de tiempo. Dependiendo de la configuración de rsyslog, son ya sea syslog clásico (Oct 19 10:15:01, sin año, sin zona horaria) o ISO 8601 completo. Si son clásicos, anote la zona horaria del servidor (timedatectl). La necesitará en el momento en que intente alinear estos eventos con cualquier otra cosa.
Paso 2b: Exportar desde el diario systemd
En sistemas solo con diario, 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 en esa línea son deliberadas.
Ambos nombres de unidad. El servicio se llama ssh en Debian y Ubuntu y casi en todas partes más como sshd. journalctl combina los flags repetidos -u con OR, por lo que el mismo comando funciona en ambas familias.
Filtrar por unidad, no por etiqueta. Muchas guías antiguas usan journalctl -t sshd. Desde OpenSSH 9.8, el servidor está dividido en dos binarios, y los mensajes por conexión, incluyendo inicios de sesión, están etiquetados como sshd-session en lugar de sshd. Filtrar por etiqueta, y perderás exactamente las líneas que viniste a buscar. Esto rompió muchos desarrollos de fail2ban y sshguard cuando el 9.8 aterrizó en 2024. RHEL 10 y otras versiones actuales envían OpenSSH 9.8 o más nuevo. Filtrar por unidad captura cada proceso que pertenece al servicio, independientemente de cómo se llame.
-o short-iso. Le da una línea de estilo syslog con una marca de tiempo completa ISO 8601, año y zona horaria incluidos, por lo que no tiene que adivinar. [PRUEBA: confirm LogTotal analiza short-iso; de lo contrario, utilice el valor predeterminado -o short]. Si prefiere conservar cada campo del diario (PID, ID de inicio, nombre de host, etc.), use -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 diario persistente, -b -1 limita la salida al arranque previo, lo cual es útil si el servidor se reinició después del incidente.
No copie los archivos binarios .journal de /var/log/journal y los cargue. LogTotal lee texto y JSON, y archivos de diario no son ninguno de los dos.
Qué buscar una vez que tenga el archivo
La mayoría de las líneas de sshd caen en un puñado de patrones:
| La línea comienza con | Lo que 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 pasan por administrador, prueba, 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 lleva la huella digital SHA256 de la clave |
| Desconectando usuario autenticando … Demasiados errores de autenticación | El cliente alcanzó MaxAuthTries |
| Conexión cerrada por <ip> … [preauth] | Desconectado antes de la autenticación, usualmente escáneres y capturadores de banner |
| pam_unix(sshd:session): sesión abierta para usuario | La sesión realmente comenzó |
La secuencia que vale la pena detenerse: una serie de líneas de Contraseña fallida o Usuario inválido desde una IP, luego una Aceptada desde la misma IP. Eso es una fuerza bruta que funcionó. Cerca: una Aceptada para una cuenta de servicio, de una dirección que nadie reconoce, a una hora que nadie trabaja.
En OpenSSH 9.8 y posteriores también puede ver mensajes sobre penalizaciones: sshd ahora se niega temporalmente a direcciones que siguen fallando en la autenticación. Trátelos como un síntoma. Dicen que alguien estaba golpeando el puerto, no que alguien haya entrado.
Cargar, 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. Sanitiza lo que carga y no mantiene sus archivos.
- Cargar. Abrir logtotal.com y arrastrar web-03_sshd.log. [PRUEBA: pantalla de carga, límite de tamaño]
- Sanear. [PROOF: what gets masked in an sshd log: usernames, source IPs, hostnames]. Look over the result before you go on. You know which of those names are sensitive in your environment.
- Revisar. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
Cómo se ve esto con datos reales. Generamos registros de sshd en una VM de prueba desechable: [PRUEBA: qué se simuló, por ejemplo, una carrera de rociado de contraseñas SSH contra algunos nombres de usuario comunes, terminando en un inicio de sesión exitoso]. El archivo resultó en [PRUEBA: N líneas, X KB]. LogTotal marcó [PRUEBA: hallazgos actuales, reglas coincidentes, técnicas ATT&CK].
¿Quiere probarlo antes de tocar sus propios servidores? [PRUEBA: enlace al archivo de muestra] es el mismo archivo que usamos arriba.
Cuando va mal
| Síntoma | Causa probable | Fix |
|---|---|---|
| No existe tal archivo o directorio para auth.log | rsyslog no está instalado (predeterminado desde Debian 12) | Use journalctl, Paso 2b |
| Permiso denegado en el archivo de registro | auth.log solo es para adm, secure solo para root | sudo, o agregue la cuenta a adm |
| journalctl -u ssh no devuelve nada, con una pista sobre otros usuarios | No estás en systemd-journal, adm o wheel | sudo, o agregue la cuenta a systemd-journal |
| journalctl -u ssh no devuelve nada como root | Nombre de unidad incorrecto para esta distro | Use -u ssh -u sshd |
| Los cierres de sesión están allí, pero no las líneas Aceptadas | Filtrando por etiqueta (-t sshd) en OpenSSH 9.8+ | Filtre por unidad en su lugar |
| Nada más viejo que el último reinicio | Diario volátil; no /var/log/journal | Los registros antiguos se han ido; verifique su SIEM o reenvío de registros |
| El archivo solo cubre unos pocos días | Los archivos rotados no fueron incluidos | Use el comando zgrep con auth.log* o secure* |
| Las marcas de tiempo no coinciden con otras fuentes | Las marcas de tiempo syslog clásicas no tienen zona horaria | Anote la zona horaria del servidor, o exporte 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, más el diario (journalctl -u ssh). Las imágenes mínimas en la nube a veces omiten rsyslog. Si el archivo no está allí, use el diario.
¿Cómo veo solo los inicios de sesión SSH fallidos?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Usuario inválido’ en sistemas con diario, o sudo zgrep -hE ‘Failed|Usuario inválido’ /var/log/auth.log* cuando tiene el archivo. Para algo más allá de una mirada rápida, cargue el registro sshd completo. Los fallos solo significan algo junto a los éxitos.
¿Qué pasa con last y lastb?
Leen los registros de inicio de sesión binarios en /var/log/wtmp y /var/log/btmp. Son útiles para una rápida visualización de quién inició sesión, pero llevan mucho menos detalle que el propio registro de sshd, y son igual de fáciles de alterar para un intruso.
¿Cómo recojo registros sshd de varios servidores a la vez?
Para una vez, un bucle lo hace: for h in web-01 web-02 web-03; do ssh «$h» «sudo journalctl -u ssh -u sshd –since ayer -o short-iso –no-pager» > «${h}_sshd.log» done Eso necesita sudo para funcionar sin solicitud de contraseña en el lado remoto. De lo contrario, agregue -t a ssh y escríbala cada vez. Si hace esto más de una vez al trimestre, envíe los registros a un SIEM en su lugar.
¿Es seguro cargar registros sshd en una herramienta en línea?
LogTotal sanea las cargas antes del análisis y no retiene archivos; nuestra [guía de saneamiento] muestra qué se oculta. Las reglas de manejo de datos de su organización aún son lo primero.
Próximo paso
¿Tienes el archivo? Carguelo en LogTotal y vea qué hacen esas 11,632 reglas sigma con él. Si desea la misma lógica de detección funcionando en todos sus 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 registro cambiadas
- journalctl(1): filtros de unidad, formatos de salida, grupos de acceso al diario
- journald.conf(5): almacenamiento persistente vs. volátil
