Artefactos SSH: authorized_keys, known_hosts y logs

Qué es

OpenSSH deja evidencias en ambos extremos de una conexión. En el lado del servidor, authorized_keys decide qué claves públicas pueden iniciar sesión en una cuenta, sshd_config fija las reglas y sshd registra cada intento aceptado o fallido. En el lado del cliente, known_hosts registra los servidores a los que se ha conectado un usuario y ~/.ssh/config a menudo les pone nombre. Juntos responden a las dos preguntas centrales de la mayoría de las intrusiones en Linux: cómo entró el atacante y a dónde fue después.

Añadir una clave a authorized_keys es una de las técnicas de persistencia más habituales en Linux (MITRE ATT&CK T1098.004) porque sobrevive a los cambios de contraseña.

Dónde se encuentra

Qué prueba

• Capacidad de acceso: cualquier clave de authorized_keys puede iniciar sesión con esa cuenta, sujeta a sus opciones y a sshd_config.
• Inicios de sesión reales: las líneas Accepted publickey o Accepted password prueban una autenticación correcta, con IP de origen, puerto y (para las claves) la huella de la clave.
• Intentos: Failed password, Invalid user y líneas similares muestran fuerza bruta y tanteo de nombres de usuario.
• Movimiento saliente: known_hosts y ~/.ssh/config muestran que la cuenta se conectó a otros hosts, incluso sin historial de la shell.
• Lo que no prueba: el comentario de una clave (user@host) es texto libre escrito por quien creó la clave. Las entradas de known_hosts no llevan fecha ni demuestran que un inicio de sesión tuviera éxito, solo que se aceptó una clave de host.

Campos clave

Opciones de authorized_keys (separadas por comas, antes del tipo de clave):

known_hosts: [marker] hostnames keytype base64key [comment]. Las entradas con hash empiezan por |1| (sal y HMAC), así que los nombres de host no se pueden leer directamente. Debian y Ubuntu incluyen HashKnownHosts yes en /etc/ssh/ssh_config; el valor por defecto de upstream es no.

Directivas de sshd_config: AuthorizedKeysFile, AuthorizedKeysCommand, AuthorizedPrincipalsFile, TrustedUserCAKeys, PermitRootLogin (por defecto prohibit-password), PasswordAuthentication, PermitUserEnvironment (por defecto no), ForceCommand, bloques Match, LogLevel (por defecto INFO), SyslogFacility.

Líneas de log (proceso sshd, y en OpenSSH 9.8+ también sshd-session; en 10.0+ algunos mensajes también pueden proceder de sshd-auth):

Accepted publickey for deploy from 198.51.100.7 port 51522 ssh2: ED25519 SHA256:<fingerprint>
Accepted password for deploy from 203.0.113.50 port 40318 ssh2
Failed password for invalid user admin from 203.0.113.50 port 40022 ssh2
Invalid user admin from 203.0.113.50 port 40022

Marcas de tiempo

Los archivos de claves y de configuración solo tienen marcas de tiempo del sistema de archivos: el mtime de authorized_keys cambia cada vez que se añade o elimina una clave, y el ctime no se puede fijar con touch. Los archivos de syslog (auth.log, secure) usan la zona horaria local y, en el formato clásico, no incluyen el año; el journal guarda __REALTIME_TIMESTAMP en microsegundos desde 1970-01-01 UTC. Los valores de expiry-time sin Z se interpretan en la zona horaria del sistema.

Retención

Los archivos de claves y de configuración permanecen hasta que se modifican. La retención de los logs depende de logrotate (semanal con cuatro rotaciones es un valor por defecto habitual en Debian para auth.log) y de los límites de tamaño del journal; ver syslog y auth.log y el journal de systemd. known_hosts solo crece salvo que un usuario ejecute ssh-keygen -R o lo edite.

Adquisición

UAC tiene artefactos dedicados para authorized_keys*, known_hosts, las claves públicas y ~/.ssh/rc, y recoge /etc/ssh junto con /etc. Velociraptor ofrece Linux.Ssh.AuthorizedKeys, Linux.Ssh.KnownHosts y Linux.Syslog.SSHLogin.

R=/mnt/evidence
tar -C "$R" -czf ssh.tgz etc/ssh root/.ssh home/*/.ssh 2>/dev/null   # includes private keys: handle as sensitive
journalctl -D "$R"/var/log/journal _COMM=sshd -o short-iso        # add _COMM=sshd-session on newer OpenSSH

Trate las claves privadas de host y de usuario como evidencia sensible: registre las huellas, restrinja el acceso y no las reutilice nunca.

Análisis

# fingerprint every authorized key, then match against "Accepted publickey" lines
for f in /mnt/evidence/root/.ssh/authorized_keys* /mnt/evidence/home/*/.ssh/authorized_keys*; do
  echo "== $f"; ssh-keygen -l -f "$f"; done
grep -hE 'sshd(-session|-auth)?\[[0-9]+\]: (Accepted|Failed|Invalid user)' /mnt/evidence/var/log/auth.log* /mnt/evidence/var/log/secure*
zgrep -h 'Accepted' /mnt/evidence/var/log/auth.log.*.gz
# test a candidate hostname against a hashed known_hosts
ssh-keygen -F 10.0.0.12 -f /mnt/evidence/home/alice/.ssh/known_hosts

Linux Log Parser lee en el navegador auth.log / secure, syslog, los archivos del journal, audit.log y wtmp / btmp / lastlog, y los combina en una sola cronología con las sesiones de inicio reconstruidas; no se sube nada.

Consejos para la investigación

• Asocie la huella SHA256: de cada línea Accepted publickey con una línea de clave concreta; así se identifica qué clave usó un atacante aunque los comentarios sean falsos.
• Busque en sshd_config y en cada drop-in un AuthorizedKeysFile que apunte a una ruta inusual, o un AuthorizedKeysCommand: las claves pueden estar fuera de ~/.ssh.
• Las claves con command= y ~/.ssh/rc ejecutan código en cada inicio de sesión; una opción from= puede revelar la infraestructura del atacante.
• Los parsers o reglas de SIEM que solo buscan sshd[ pierden las líneas etiquetadas como sshd-session o sshd-auth en OpenSSH reciente (Linux.Syslog.SSHLogin de Velociraptor filtra por el programa sshd).
• Un known_hosts con hash se puede seguir contrastando con las IP candidatas de su caso mediante ssh-keygen -F.
• Unas claves de host cambiadas (ctime nuevo en /etc/ssh/ssh_host_*) pueden indicar un servidor reconstruido o clonado.
• Correlacione los inicios de sesión aceptados con wtmp/lastlog y con el historial de la shell del usuario.