Qui s'est connecté à la machine : journaux de connexion
Où consulter les connexions réussies et échouées, comment lire last, lastb et journalctl, comment suivre les actions via sudo et comment configurer la conservation des journaux.
Mis à jour le 23 août 2026
Chaque connexion à une machine laisse une trace. Savoir lire ces traces en cinq minutes, c'est ce qui distingue une analyse d'incident sereine d'une simple supposition.
Aperçu rapide
last -a -n 20
lastb -a -n 20
lastlog
who
w
last affiche les connexions réussies avec les adresses, lastb — les tentatives échouées, lastlog — la date de dernière connexion de chaque utilisateur. who et w montrent qui est présent sur la machine en ce moment.
Si lastlog affiche une date de connexion pour un utilisateur système comme www-data, c'est une raison sérieuse d'enquêter.
Journal systemd
journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50
Lignes clés :
| Ligne | Signification |
|---|---|
Accepted publickey for artem | Connexion réussie par clé |
Accepted password for root | Connexion réussie par mot de passe — motif d'inquiétude |
Failed password for invalid user admin | Force brute sur des noms inexistants, bruit de fond |
Disconnected from authenticating user | Tentative interrompue |
Sur Debian et Ubuntu, les mêmes événements sont dupliqués dans /var/log/auth.log ; sur AlmaLinux, dans /var/log/secure.
grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log
Des centaines de tentatives échouées par jour sur une adresse publique, c'est normal. Ce qui est anormal, c'est autre chose : une connexion réussie depuis une adresse que vous ne reconnaissez pas. fail2ban aide à lutter contre le bruit.
Ce qui a été fait après la connexion
journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history
L'historique des commandes n'est pas fiable : il est facile à effacer et il n'est pas enregistré lors des sessions non interactives. Le journal sudo est bien plus honnête — il est tenu par le système, pas par le shell. Un argument de plus en faveur du schéma « utilisateur normal plus sudo » décrit dans l'article utilisateurs et sudo.
Audit complet au niveau du noyau :
apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes
Stockage
Par défaut, le journal systemd peut résider en mémoire et être perdu au redémarrage. C'est mauvais pour l'analyse d'incident. Le fichier /etc/systemd/journald.conf :
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage
Une limite de taille est obligatoire : un journal qui a dévoré le disque arrête les services.
Erreurs courantes
| Erreur | Conséquence | Solution |
|---|---|---|
| Le journal n'est pas conservé entre les redémarrages | Les traces sont perdues | Storage=persistent |
Se fier uniquement à .bash_history | Les données sont faciles à falsifier | Vérifier les journaux sudo et auditd |
| Ne pas avoir limité la taille du journal | Disque saturé | SystemMaxUse |
| Prendre le bruit de la force brute pour un piratage | Fausse alerte | Regarder Accepted, pas Failed |
Si vous découvrez une connexion réussie depuis une adresse qui n'est pas la vôtre, les journaux de la machine elle-même ne peuvent plus être considérés comme fiables : celui qui s'est connecté a pu les modifier. Suivez l'article signes de compromission et partez du principe que la machine devra être réinstallée.