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 que vous souhaitez 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 toutes les investigations Linux. Prime Core dispose de 11 632 règles sigma qui s’exécutent sur des journaux d’authentification Linux comme ceux-ci, mappés à 643 techniques MITRE ATT&CK. Parmi elles : force brute (T1110), connexions avec des identifiants volés (T1078) et mouvement latéral via SSH (T1021.004). Ci-dessous, comment trouver vos journaux sshd, les exporter, les nettoyer et les analyser gratuitement sur LogTotal.
En résumé
| Famille de distributions | Fichier de journal | Commande du 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 volontairement verrouillés, donc un compte régulier n’obtient 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 réservé à root.
- Le journal système est ouvert à root et aux membres de systemd-journal, adm et wheel. Tous les autres ne voient que leur 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 uniquement pour la collecte de journaux, ajoutez-le à adm ou systemd-journal au lieu de donner accès root. Notre [guide des permissions de journaux Linux] couvre les détails.
Une chose de plus 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ôte. LogTotal nettoie 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 renforcement 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 brut. L’une ou l’autre source fonctionne, et le fichier est plus facile à copier.
S’il n’y a pas de fichier, rsyslog n’est simplement pas installé. C’est désormais la norme : depuis Debian 12, rsyslog ne fait plus partie d’une installation par défaut, donc un nouveau serveur Debian n’a pas du tout d’auth.log. Fedora et Arch fonctionnent de cette manière depuis des années. Passez à l’étape 2b.
Pendant 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 conserve les journaux en mémoire sous /run/log/journal, et un redémarrage les efface. Sur une machine que vous enquêtez, c’est bon à savoir avant que quelqu’un décide de « juste la redémarrer ».
Un autre point pour les travaux d’incident : si la machine pourrait être compromise, ses journaux locaux pourraient l’être aussi. Effacer ou modifier auth.log est une étape classique de nettoyage. Si le serveur retransmet les journaux à un SIEM, exportez-les 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 entrées plus anciennes 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 avez aussi besoin de ceux-ci.
Ceci 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 les fichiers texte simple et gzippés de la même façon, vous n’avez donc pas besoin de décompresser quoi que ce soit. ls -tr trie par date de modification, donc le fichier le plus ancien est en premier et la sortie reste globalement chronologique. Le motif sshd correspond aussi à sshd-session, ce qui est important sur les systèmes plus 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. Parfois, les gens tapent des mots de passe là-dedans. Filtrer par sshd garde cela hors du fichier. L’exception est lorsque vous enquêtez sur ce qu’un attaquant a fait après s’être connecté. Vous voulez alors aussi les lignes sudo : prenez tout le fichier 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 au format syslog classique (19 oct 10:15:01, pas d’année, pas de fuseau horaire) ou en ISO 8601 complet. S’ils sont classiques, notez le fuseau horaire du serveur (timedatectl). Vous en aurez besoin dès que vous essayerez d’aligner ces événements avec tout autre élément.
Étape 2b : Exporter le journal systemd
Sur les systèmes uniquement journalisés, 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à-dedans sont délibérés.
Les deux noms d’unités. Le service s’appelle ssh sur Debian et Ubuntu et sshd presque partout ailleurs. journalctl combine les drapeaux -u répétés avec OR, donc la même commande fonctionne sur les deux familles.
Filtrez par unité, pas par étiquette. Nombre 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 étiquetés sshd-session au lieu de sshd. Filtrez par étiquette, et vous perdez exactement les lignes pour lesquelles vous êtes venus. Cela a cassé de nombreuses configurations fail2ban et sshguard lorsqu’OpenSSH 9.8 a été publié en 2024. RHEL 10 et d’autres versions récentes incluent OpenSSH 9.8 ou plus récent. En filtrant par unité, vous attrapez chaque processus appartenant au service, peu importe comment il est appelé.
-o short-iso. Cela vous donne une ligne de style syslog avec un horodatage complet ISO 8601, année et fuseau horaire inclus, donc vous n’avez pas à deviner. [PREUVE : confirmer que LogTotal analyse short-iso ; sinon, utilisez le mode par défaut -o short]. Si vous préférez conserver chaque champ du journal (PID, ID de démarrage, nom d’hôte, etc.), utilisez -o json, ce 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 yesterday. Avec un journal persistant, -b -1 limite la sortie au démarrage précédent, ce qui est utile si le serveur a été redémarré après l’incident.
Ne copiez pas les fichiers binaires .journal de /var/log/journal et ne les téléchargez pas. LogTotal lit les textes et JSON, et les fichiers de journal ne sont ni l’un ni l’autre.
Que chercher une fois que vous avez le fichier
La plupart des lignes sshd suivent une poignée de modèles :
| La ligne commence avec | Ce que cela signifie |
|---|---|
| Mot de passe échoué pour <utilisateur> depuis <ip> | Mauvais mot de passe pour un compte existant |
| Utilisateur non valide <utilisateur> depuis <ip> | Le nom d’utilisateur n’existe pas ; typique des scanners parcourant admin, test, oracle |
| Mot de passe accepté pour / clé publique acceptée pour | Une connexion réussie ; la ligne de clé publique porte aussi l’empreinte numérique SHA256 de la clé |
| Déconnexion de l’utilisateur authentifiant … Trop de tentatives d’authentification | Le client a atteint MaxAuthTries |
| Connexion fermée par <ip> … [preauth] | Interrompu avant l’authentification, généralement des scanners et des récupérateurs de bannières |
| pam_unix(sshd:session): session ouverte pour utilisateur | La session a réellement commencé |
La séquence qui mérite qu’on s’y arrête : une série de lignes Échec ou Utilisateur non valide d’une seule IP, puis un Accepté de la même IP. C’est une force brute qui a fonctionné. De plus près : un Accepté pour un compte de service, d’une adresse que personne ne reconnaît, à une heure où personne ne travaille.
Sur OpenSSH 9.8 et plus, vous pouvez également voir des messages concernant des pénalités : sshd refuse temporairement les adresses qui échouent continuellement à s’authentifier. Traitez-les comme un symptôme. Ils vous indiquent que quelqu’un a martelé le port, pas que quelqu’un est entré.
Téléchargez, nettoyez et examinez dans LogTotal
Lire quelques centaines de lignes à l’œil va bien. En lire 40 000 ne l’est pas. LogTotal est le service gratuit de SOC Prime pour exécuter une logique de détection sur un fichier journal sans rien configurer. Il nettoie ce que vous téléchargez et ne garde pas vos fichiers.
- Téléchargez. Ouvrir logtotal.com et déposez web-03_sshd.log. [PREUVE : écran de téléchargement, limite de taille]
- Nettoyer. [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.
- Examiner. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
À quoi cela ressemble-t-il sur des données réelles. Nous avons généré des journaux sshd sur une VM de test jetable : [PREUVE : ce qui a été simulé, par exemple une opération d’attaques par pulvérisation de mots de passe SSH contre quelques noms d’utilisateur courants, se terminant par une connexion réussie]. Le fichier s’est avéré faire [PREUVE : N lignes, X KB]. LogTotal a signalé [PREUVE : résultats réels, règles appliquées, techniques ATT&CK].
Vous voulez l’essayer avant de toucher à vos propres serveurs ? [PREUVE : lien vers le fichier d’exemple] est le même fichier que nous avons utilisé ci-dessus.
Quand ça tourne mal
| Symptôme | Cause probable | Fix |
|---|---|---|
| Aucun fichier ou répertoire de ce type pour auth.log | rsyslog n’est pas installé (par défaut depuis Debian 12) | Utilisez journalctl, Étape 2b |
| Permission refusée sur le fichier journal | auth.log est réservé à adm, secure est réservé à root | sudo, ou ajoutez le compte à adm |
| journalctl -u ssh ne renvoie rien, avec une indication concernant 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 | Utilisez -u ssh -u sshd |
| Les déconnexions sont présentes, mais pas les lignes Accepté | Filtrage par étiquette (-t sshd) sur OpenSSH 9.8+ | Filtrez plutôt par unité |
| 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 transmetteur de journaux |
| Le fichier ne couvre que quelques jours | Les fichiers tournés n’ont pas été inclus | Utilisez la commande zgrep avec auth.log* ou secure* |
| Les horodatages ne s’alignent pas avec d’autres sources | Les horodatages syslog classiques ne portent pas de fuseau horaire | Notez le fuseau horaire du serveur, ou exportez avec -o short-iso |
FAQ
Où sont 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 omettent parfois rsyslog. Si le fichier n’est pas là, utilisez le journal.
Comment voir uniquement les connexions SSH échouées ?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ sur les systèmes journal, ou sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* lorsque vous avez le fichier. Pour tout ce qui va au-delà d’un coup d’œil rapide, téléchargez plutôt le journal sshd complet. Les échecs signifient quelque chose uniquement à côté des succès.
Qu’en est-il de last et lastb ?
Ils lisent les enregistrements binaires des connexions dans /var/log/wtmp et /var/log/btmp. Ils sont pratiques pour un rapide aperçu des personnes connectées, mais ils contiennent beaucoup moins de détails que le journal propre de sshd, et ils sont tout aussi faciles à manipuler pour un intrus.
Comment puis-je collecter les journaux sshd de plusieurs serveurs à la fois ?
Pour une opération ponctuelle, une boucle fait l’affaire : pour h dans 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 » fait Cela nécessite que sudo fonctionne 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-ce sûr de télécharger des journaux sshd sur un outil en ligne ?
LogTotal nettoie les fichiers téléchargés avant 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 restent toutefois prioritaires.
Étape suivante
Avez-vous le fichier ? Téléchargez-le sur LogTotal et voyez ce que ces 11 632 règles sigma en disent. Si vous voulez que la même logique de détection fonctionne sur tous vos serveurs Linux, pas un fichier à la fois.
Références
- Notes de version Debian 12: changements dans la journalisation système
- Notes de version OpenSSH 9.8 : la scission sshd / sshd-session et les étiquettes de journal modifiées
- journalctl(1) : filtres d’unités, formats de sortie, groupes d’accès au journal
- journald.conf(5) : stockage persistant vs volatil
