Artefacts SSH : authorized_keys, known_hosts, logs sshd

Ce que c'est

OpenSSH laisse des traces aux deux extrémités d'une connexion. Côté serveur, authorized_keys détermine quelles clés publiques peuvent se connecter à un compte, sshd_config fixe les règles, et sshd journalise chaque tentative acceptée ou échouée. Côté client, known_hosts enregistre les serveurs auxquels un utilisateur s'est connecté et ~/.ssh/config les nomme souvent. Ensemble, ils répondent aux deux questions centrales de la plupart des intrusions Linux : comment l'attaquant est-il entré, et où est-il allé ensuite.

Ajouter une clé à authorized_keys est l'une des techniques de persistance Linux les plus courantes (MITRE ATT&CK T1098.004), car elle survit aux réinitialisations de mot de passe.

Où il se trouve

Ce qu'il prouve

• Capacité d'accès : toute clé présente dans authorized_keys peut se connecter sous ce compte, sous réserve de ses options et de sshd_config.
• Connexions effectives : les lignes Accepted publickey ou Accepted password prouvent une authentification réussie, avec IP source, port et (pour les clés) l'empreinte de la clé.
• Tentatives : Failed password, Invalid user et lignes similaires révèlent la force brute et les essais de noms d'utilisateur.
• Mouvement sortant : known_hosts et ~/.ssh/config montrent que le compte s'est connecté à d'autres hôtes, même sans historique du shell.
• Non prouvé : le commentaire d'une clé (user@host) est un texte libre rédigé par celui qui a créé la clé. Les entrées de known_hosts ne portent pas de date et ne montrent pas qu'une connexion a réussi, seulement qu'une clé d'hôte a été acceptée.

Champs clés

Options d'authorized_keys (séparées par des virgules, avant le type de clé) :

known_hosts : [marker] hostnames keytype base64key [comment]. Les entrées hachées commencent par |1| (sel et HMAC) : les noms d'hôte ne sont donc pas lisibles directement. Debian et Ubuntu livrent HashKnownHosts yes dans /etc/ssh/ssh_config ; la valeur par défaut en amont est no.

Directives de sshd_config : AuthorizedKeysFile, AuthorizedKeysCommand, AuthorizedPrincipalsFile, TrustedUserCAKeys, PermitRootLogin (par défaut prohibit-password), PasswordAuthentication, PermitUserEnvironment (par défaut no), ForceCommand, blocs Match, LogLevel (par défaut INFO), SyslogFacility.

Lignes de journal (processus sshd, et depuis OpenSSH 9.8 aussi sshd-session ; depuis 10.0, certains messages peuvent aussi provenir 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

Horodatages

Les fichiers de clés et de configuration n'ont que des horodatages du système de fichiers : le mtime d'authorized_keys change à chaque ajout ou retrait de clé, et le ctime ne peut pas être modifié avec touch. Les fichiers syslog (auth.log, secure) utilisent le fuseau horaire local et, dans le format classique, pas d'année ; le journal stocke __REALTIME_TIMESTAMP en microsecondes depuis le 1970-01-01 UTC. Les valeurs expiry-time sans Z sont interprétées dans le fuseau horaire du système.

Rétention

Les fichiers de clés et de configuration restent jusqu'à leur modification. La rétention des journaux dépend de logrotate (rotation hebdomadaire avec quatre générations, un réglage Debian courant pour auth.log) et des limites de taille du journal ; voir syslog et auth.log et journal systemd. known_hosts ne fait que grossir, sauf si un utilisateur lance ssh-keygen -R ou le modifie.

Collecte

UAC dispose d'artefacts dédiés pour authorized_keys*, known_hosts, les clés publiques et ~/.ssh/rc, et collecte /etc/ssh avec /etc. Velociraptor fournit Linux.Ssh.AuthorizedKeys, Linux.Ssh.KnownHosts et 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

Traitez les clés privées d'hôte et d'utilisateur comme des preuves sensibles : relevez les empreintes, restreignez l'accès, ne les réutilisez jamais.

Analyse

# 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 lit dans le navigateur auth.log / secure, syslog, les fichiers du journal, audit.log et wtmp / btmp / lastlog, et les fusionne en une seule chronologie avec les sessions de connexion reconstituées ; rien n'est envoyé.

Conseils d'investigation

• Rapprochez l'empreinte SHA256: de chaque ligne Accepted publickey d'une ligne de clé précise : vous identifiez ainsi la clé utilisée par un attaquant même si les commentaires sont faux.
• Cherchez un AuthorizedKeysFile pointant vers un chemin inhabituel, ou un AuthorizedKeysCommand, dans sshd_config et dans chaque drop-in : des clés peuvent se trouver hors de ~/.ssh.
• Les clés command= et ~/.ssh/rc exécutent du code à chaque connexion ; une option from= peut révéler l'infrastructure de l'attaquant.
• Les parsers ou règles SIEM qui ne reconnaissent que sshd[ manquent les lignes étiquetées sshd-session ou sshd-auth des OpenSSH récents (le Linux.Syslog.SSHLogin de Velociraptor filtre sur le programme sshd).
• Un known_hosts haché peut quand même être testé contre les IP candidates de votre dossier avec ssh-keygen -F.
• Des clés d'hôte modifiées (nouveau ctime sur /etc/ssh/ssh_host_*) peuvent indiquer un serveur reconstruit ou cloné.
• Corrélez les connexions acceptées avec wtmp/lastlog et l'historique du shell de l'utilisateur.