Suivre Sur Debian et Ubuntu, sshd écrit dans /var/log/auth.log. Sur RHEL, Rocky, Alma et CentOS Stream, il écrit dans /var/log/secure. Si aucun de ces fichiers n’existe, votre système ne journalise que dans le journal systemd. Ensuite, la commande souhaitée est journalctl -u ssh sur les systèmes basés sur Debian, ou journalctl -u sshd sur la famille Red Hat, Fedora et Arch.
SSH est la porte d’entrée de presque tous les serveurs Linux, c’est pourquoi ses journaux apparaissent dans presque chaque enquête Linux. Prime Core dispose de 11 632 règles sigma qui fonctionnent sur des journaux d’authentification Linux comme ceux-ci, mappés à 643 techniques MITRE ATT&CK. Parmi elles : la force brute (T1110), les connexions avec des identifiants volés (T1078) et le déplacement latéral sur SSH (T1021.004). Voici comment trouver vos journaux sshd, les exporter, les nettoyer et les analyser gratuitement dans LogTotal.
Résumé
| Famille de distribution | Fichier de journaux | Commande Journal |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, installations minimales sans rsyslog | aucun par défaut | journalctl -u sshd |
Avant de commencer : pouvez-vous réellement les lire ?
Les journaux d’authentification sont verrouillés à dessein, donc un compte normal ne reçoit généralement rien en retour.
- /var/log/auth.log sur Debian et Ubuntu est lisible par root et le groupe adm.
- /var/log/secure sur la famille Red Hat est uniquement réservé à root.
- Le journal système est ouvert à root et aux membres de systemd-journal, adm et wheel. Tout autre utilisateur ne voit que son propre journal utilisateur. Si vous exécutez journalctl -u ssh en tant qu’utilisateur normal, vous obtenez un résultat vide et une indication que vous ne voyez pas les messages des autres utilisateurs. C’est une question de permissions, pas un serveur silencieux.
La solution simple est sudo. Si vous configurez un compte juste pour la collecte de journaux, ajoutez-le à adm ou systemd-journal au lieu de donner le root. Notre [guide des permissions de journaux Linux] couvre les détails.
Encore une chose avant de copier quoi que ce soit d’un serveur : les journaux d’authentification contiennent des noms d’utilisateur, des IP sources et des noms d’hôtes. LogTotal sanitize les téléchargements, mais vérifiez d’abord votre politique de gestion des données.
Étape 1 : Fichier, journal ou les deux ?
Le tableau ci-dessus montre les valeurs par défaut, et les valeurs par défaut sont exactement ce que les images cloud et les scripts de sécurisation aiment changer. Passez dix secondes à vérifier :
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Si un fichier apparaît et que rsyslog est actif, vous avez les deux : rsyslog copie les messages du journal dans un fichier texte simple. Les deux sources fonctionnent, et le fichier est plus facile à déplacer.
S’il n’y a pas de fichier, rsyslog n’est tout simplement pas installé. C’est la norme à présent : depuis Debian 12, rsyslog ne fait plus partie d’une installation par défaut, donc une machine Debian récente n’a pas d’auth.log du tout. Fedora et Arch fonctionnent de cette façon depuis des années. Passez à l’étape 2b.
Tant que vous y êtes, vérifiez si le journal survit à un redémarrage :
ls -d /var/log/journal
Si ce répertoire n’existe pas, journald garde les journaux en mémoire sous /run/log/journal, et un redémarrage les efface. Sur une machine que vous enquêtez, cela vaut la peine de le savoir avant que quelqu’un décide de « juste la redémarrer ».
Un autre point pour le travail d’incident : si la machine est compromise, ses journaux locaux peuvent l’être aussi. Effacer ou modifier auth.log est une étape classique de nettoyage. Si le serveur transfère des journaux à un SIEM, exportez de là aussi et comparez. Notre [guide d’exportation Splunk] montre comment.
Étape 2a : Exporter depuis auth.log ou secure
Le fichier actuel ne couvre que les derniers jours. Les anciennes entrées se trouvent dans les fichiers tournés à côté. Sur Debian et Ubuntu, ils ressemblent à auth.log.1, auth.log.2.gz, et ainsi de suite. Sur la famille Red Hat, ils portent une date, comme secure-20261012. Si l’incident a commencé la semaine dernière, vous en avez besoin également.
Cela extrait les lignes sshd des fichiers actuels et tournés, du plus ancien au plus récent, dans un seul fichier :
# 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 lit également les fichiers simples et gzipés, vous n’avez donc pas besoin de décompresser quoi que ce soit. ls -tr trie par heure de modification, donc le fichier le plus ancien est en premier et la sortie reste à peu près chronologique. Le modèle sshd correspond également à sshd-session, ce qui importe sur les systèmes récents (voir étape 2b).
Pourquoi filtrer du tout ? En plus de réduire le bruit, auth.log enregistre également sudo, et les lignes sudo incluent les lignes de commande complètes. Les gens tapent parfois des mots de passe dedans. En filtrant vers sshd, cela reste hors du fichier. L’exception est lorsque vous enquêtez sur ce qu’un attaquant a fait après s’être connecté. Ensuite, vous voulez aussi les lignes sudo : prenez le fichier entier et laissez l’étape de nettoyage de LogTotal faire son travail.
Vérification rapide avant de télécharger :
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Regardez les horodatages. Selon la configuration de rsyslog, ils sont soit en style syslog classique (19 oct 10:15:01, pas d’année, pas de fuseau horaire) soit en ISO 8601 complet. S’ils sont classiques, notez le fuseau horaire du serveur (timedatectl). Vous en aurez besoin dès que vous tenterez d’aligner ces événements avec autre chose.
Étape 2b : Exporter depuis le journal systemd
Sur les systèmes avec uniquement le journal, c’est tout le travail :
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
Quelques choix à l’intérieur sont délibérés.
Les deux noms d’unités. Le service est appelé ssh sur Debian et Ubuntu et sshd presque partout ailleurs. journalctl combine les répétitions des drapeaux -u avec OR, donc la même commande fonctionne sur les deux familles.
Filtrer par unité, pas par tag. Beaucoup de guides plus anciens utilisent journalctl -t sshd. Depuis OpenSSH 9.8, le serveur est divisé en deux binaires, et les messages par connexion, y compris les connexions, sont marqués sshd-session au lieu de sshd. Filtrer par tag, et vous perdez exactement les lignes que vous êtes venu chercher. Cela a cassé de nombreux réglages fail2ban et sshguard lorsque la version 9.8 est arrivée en 2024. RHEL 10 et d’autres versions actuelles envoient OpenSSH 9.8 ou plus récent. La filtration par unité capture chaque processus appartenant au service, quel que soit son nom.
-o short-iso. Cela vous donne une ligne de type syslog avec un horodatage ISO 8601 complet, comprenant l’année et le fuseau horaire, vous ne devez donc pas deviner. Si vous préférez garder chaque champ de journal (PID, ID de démarrage, nom d’hôte, etc.), utilisez -o json, qui écrit un objet JSON par ligne. Le fichier devient plus grand, mais rien n’est perdu.
Les filtres temporels prennent également des valeurs relatives : –since « il y a 2 heures » ou –since hier. Avec un journal persistant, -b -1 limite la sortie au démarrage précédent, ce qui est utile si le serveur a redémarré après l’incident.
Ne copiez pas les fichiers binaires .journal depuis /var/log/journal et ne les téléchargez pas. LogTotal lit le texte et le JSON, et les fichiers journaux ne sont ni l’un ni l’autre.
Que chercher une fois que vous avez le fichier
La plupart des lignes sshd se répartissent en quelques modèles :
| La ligne commence par | Ce que cela signifie |
|---|---|
| Mot de passe incorrect pour <utilisateur> depuis <ip> | Mot de passe incorrect pour un compte existant |
| Utilisateur invalide <utilisateur> depuis <ip> | Le nom d’utilisateur n’existe pas; typique des scanners qui tournent sur admin, test, oracle |
| Mot de passe accepté pour / Clé publique acceptée pour | Une connexion réussie ; la ligne de clé publique porte également l’empreinte SHA256 de la clé |
| Déconnexion de l’utilisateur authentifiant … Trop d’échecs d’authentification | Le client a atteint MaxAuthTries |
| Connexion fermée par <ip> … [preauth] | Interrompu avant l’authentification, généralement des scanners et collecteurs de bannières |
| pam_unix(sshd:session) : session ouverte pour l’utilisateur | La session a réellement commencé |
La séquence qui vaut la peine de s’arrêter : une série de lignes de Mot de passe incorrect ou d’Utilisateur invalide depuis une IP, puis un Mot de passe accepté depuis la même IP. C’est une force brute qui a fonctionné. Juste derrière : un Mot de passe accepté pour un compte de service, depuis une adresse que personne ne reconnaît, à une heure que personne ne travaille.
Sur OpenSSH 9.8 et plus tard, vous pouvez également voir des messages concernant des pénalités : sshd refuse temporairement les adresses qui continuent d’échouer l’authentification. Considérez-les comme un symptôme. Ils vous disent que quelqu’un martelait le port, pas que quelqu’un est entré.
Télécharger, nettoyer et examiner dans LogTotal
Lire quelques centaines de lignes à l’œil nu, c’est bien. Lire 40 000 ne l’est pas. LogTotal est le service gratuit de SOC Prime pour exécuter la logique de détection sur un fichier journal sans rien configurer. Il nettoie ce que vous téléchargez et ne conserve pas vos fichiers.
- Télécharger. Ouvrir logtotal.com et déposez web-03_sshd.log.
- Nettoyer. Examinez le résultat avant de continuer. Vous savez quels de ces noms sont sensibles dans votre environnement.
- Examiner.
Quand cela va mal
| Symptôme | Cause probable | Fix |
|---|---|---|
| Aucun fichier ou répertoire pour auth.log | rsyslog n’est pas installé (par défaut depuis Debian 12) | Utiliser journalctl, Étape 2b |
| Permission refusée sur le fichier journal | auth.log est uniquement pour adm, secure est uniquement pour root | sudo, ou ajoutez le compte à adm |
| journalctl -u ssh ne renvoie rien, avec une indication sur d’autres utilisateurs | Vous n’êtes pas dans systemd-journal, adm ou wheel | sudo, ou ajoutez le compte à systemd-journal |
| journalctl -u ssh ne renvoie rien en tant que root | Mauvais nom d’unité pour cette distribution | Utiliser -u ssh -u sshd |
| Les déconnexions sont là, mais pas de lignes Acceptées | Filtrage par tag (-t sshd) sur OpenSSH 9.8+ | Filtrer par unité à la place |
| Rien de plus ancien que le dernier redémarrage | Journal volatil; pas de /var/log/journal | Les anciens journaux sont partis; vérifiez votre SIEM ou transmettez les journaux |
| Le fichier ne couvre que quelques jours | Les fichiers tournés n’étaient pas inclus | Utilisez la commande zgrep avec auth.log* ou secure* |
| Les horodatages ne correspondent pas avec d’autres sources | Les horodatages syslog classiques ne contiennent pas de fuseau horaire | Notez le fuseau horaire du serveur, ou exportez avec -o short-iso |
FAQ
Où se trouvent les journaux SSH sur Ubuntu ?
Sur une installation standard d’Ubuntu, dans /var/log/auth.log, plus le journal (journalctl -u ssh). Les images cloud minimales laissent parfois de côté rsyslog. Si le fichier n’est pas là, utilisez le journal.
Comment puis-je voir uniquement les connexions SSH échouées ?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ sur les systèmes de journal, ou sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* lorsque vous avez le fichier. Pour tout ce qui dépasse un simple aperçu, téléchargez plutôt le journal complet sshd. Les échecs ne signifient quelque chose qu’à côté des réussites.
Qu’en est-il des commandes last et lastb ?
Elles lisent les enregistrements binaires de connexion dans /var/log/wtmp et /var/log/btmp. Elles sont utiles pour un aperçu rapide de qui s’est connecté, mais elles portent beaucoup moins de détails que le journal propre de sshd, et il est aussi facile pour un intrus de les falsifier.
Comment collecter les journaux sshd de plusieurs serveurs à la fois ?
Pour une opération ponctuelle, une boucle le fait : 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 Cela nécessite sudo pour fonctionner sans demande de mot de passe du côté distant. Sinon, ajoutez -t à ssh et tapez-le à chaque fois. Si vous faites cela plus d’une fois par trimestre, envoyez plutôt les journaux à un SIEM.
Est-il sûr de télécharger des journaux sshd sur un outil en ligne ?
LogTotal nettoie les téléchargements avant l’analyse et ne conserve pas les fichiers ; notre [guide de nettoyage] montre ce qui est masqué. Les règles de gestion des données de votre organisation passent toujours en premier.
Étape suivante
Avez-vous le fichier ? Téléchargez-le sur LogTotal et voyez ce que ces 11 632 règles sigma en font. Si vous souhaitez que la même logique de détection fonctionne sur tous vos serveurs Linux, et pas un fichier à la fois.
Références
- Notes de version de Debian 12 : changements dans la journalisation du système
- Notes de version d’OpenSSH 9.8: la scission sshd / sshd-session et les tags de journal modifiés
- journalctl(1): filtres d’unité, formats de sortie, groupes d’accès au journal
- journald.conf(5): stockage persistant vs. volatil
