WardtermClient SSH
FR
Télécharger

Comment voir les tentatives de connexion SSH sous Linux

Lancez sudo journalctl -u ssh --since today sur Debian et Ubuntu, ou -u sshd sur Red Hat et Fedora. Là où des journaux texte existent, regardez /var/log/auth.log ou /var/log/secure. Les lignes avec Accepted sont de vraies connexions, et Failed password ou Invalid user sont des tentatives. Utilisez who pour les sessions en cours, last pour les passées et sudo lastb pour les échecs, là où ces commandes existent.

Mis à jour le . Lignes de journal et commandes grep exécutées avec OpenSSH 10.0 sous Debian 13 avec rsyslog.

Où sont les journaux

SystèmeLire les journaux avec
Debian ou Ubuntu, avec systemdsudo journalctl -u ssh
Red Hat ou Fedora, avec systemdsudo journalctl -u sshd
Debian ou Ubuntu avec rsyslog/var/log/auth.log
Famille Red Hat avec rsyslog/var/log/secure

Un fichier peut manquer, et c'est normal : Debian n'installe plus rsyslog par défaut depuis la version 12, donc un système Debian récent n'a souvent que le journal systemd.

Avec journalctl

sudo journalctl -u ssh --since today
sudo journalctl -u ssh --since "2 hours ago" --grep 'Accepted|Failed|Invalid'
sudo journalctl -u ssh -f

-f suit les nouvelles lignes au fur et à mesure, ce qui aide quand vous testez une connexion.

Avec les fichiers texte

sudo grep Accepted /var/log/auth.log
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log

Les lignes plus anciennes peuvent se trouver dans /var/log/auth.log.1 et dans les fichiers compressés à côté. Depuis OpenSSH 9.8, ces lignes portent le nom sshd-session et non sshd : un filtre ou un script qui cherche sshd[ ne trouve rien sur un système actuel.

Ce que signifient les lignes

Toutes sont de vraies lignes d'un serveur de test, avec l'adresse modifiée.

sshd-session[1329]: Accepted publickey for user from 203.0.113.10 port 43594 ssh2: ED25519 SHA256:NxFS05Q+k1zf...
sshd-session[1339]: Accepted password for user from 203.0.113.10 port 43598 ssh2

Quelqu'un s'est connecté. Ce sont les lignes à lire en premier. La première montre quelle clé a été utilisée. Voir comment révoquer une clé si vous en trouvez une que vous ne voulez pas.

sshd-session[1311]: Failed password for user from 203.0.113.10 port 33598 ssh2

Un mot de passe erroné pour un compte qui existe.

sshd-session[1317]: Invalid user admin from 203.0.113.10 port 50898
sshd-session[1317]: Failed password for invalid user admin from 203.0.113.10 port 50898 ssh2

Une tentative sur un compte qui n'existe pas sur ce système. C'est à quoi ressemble la plupart des devinettes automatisées.

sshd-session[1326]: Connection closed by authenticating user user 203.0.113.10 port 43590 [preauth]

Le client a abandonné pendant la connexion. Avec des connexions par clé, cela signifie généralement qu'une clé a été proposée sans être acceptée. Par défaut, le journal ne dit pas laquelle.

sshd-session[1317]: error: maximum authentication attempts exceeded for invalid user admin from 203.0.113.10 port 50898 ssh2 [preauth]

Le client a dépassé MaxAuthTries et a été déconnecté.

Compter les tentatives par adresse et par utilisateur

# Which addresses
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

# Which user names they try
sudo grep -oE 'Invalid user [^ ]+' /var/log/auth.log \
  | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

Une seule tentative produit généralement à la fois une ligne Failed et une ligne Invalid user : considérez les nombres comme une indication. Avec le journal systemd, commencez le premier pipeline ainsi :

sudo journalctl -u ssh --since today --no-pager | grep -E 'Failed password|Invalid user' \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

Voir qui est connecté maintenant

who
w

Les deux listent les sessions avec un terminal. Une commande lancée avec ssh server somecommand, un transfert de fichiers ou un tunnel n'apparaît pas. Pour voir toutes les connexions, y compris celles-là :

sudo ss -tnp state established '( sport = :22 )'

Changez 22 si votre serveur utilise un autre port. Nous avons vu la connexion dans cette liste alors que who n'affichait rien.

Sessions passées : last et lastb

last -a -n 20
sudo lastb -a -n 20

last lit les connexions passées et lastb les échouées. -a place l'adresse dans la dernière colonne. Deux limites sont apparues dans nos tests :

  • last n'a montré que les sessions avec un terminal. Une connexion qui a seulement lancé une commande n'a rien laissé : les fichiers de journal sont donc le registre le plus complet.
  • Sur Debian 13, ces commandes ont disparu. Le paquet util-linux n'inclut plus last ni lastb. Installez wtmpdb et libpam-wtmpdb pour retrouver last, ce qui a fonctionné dans notre test, pour les sessions postérieures à l'installation. Pour les échecs, il n'existe pas de remplaçant qui lise l'ancien fichier. Les notes de version suggèrent lslogins --failed, mais il n'a rien affiché dans notre test : utilisez les journaux.

Voir quelle clé a été refusée

Pour journaliser aussi l'empreinte des clés qui échouent, mettez ceci dans un fichier de /etc/ssh/sshd_config.d/ et rechargez :

LogLevel VERBOSE
sshd-session[1376]: Failed publickey for user from 203.0.113.10 port 43612 ssh2: RSA SHA256:R3PypHnQ7AMz...

Que faire de ce que vous trouvez

  • Beaucoup d'échecs depuis beaucoup d'adresses : c'est courant sur tout serveur ouvert à Internet. Si le serveur n'accepte que les clés, les essais de mots de passe ne peuvent pas réussir. Voir comment désactiver la connexion par mot de passe et, pour réduire le bruit, fail2ban.
  • Une ligne Accepted que vous ne savez pas expliquer : prenez cela au sérieux. Notez l'heure, l'adresse et la clé. Supprimez cet accès, regardez ce que le compte a fait, et si vous n'êtes pas sûr de ce qui s'est passé, reconstruisez le serveur à partir d'un état propre.

Quelqu'un qui a root peut modifier les journaux locaux : pour les serveurs importants, envoyez-les aussi vers une autre machine.

Pour rendre inutiles les essais de mots de passe, générez une clé SSH Ed25519 et n'acceptez que les clés.

Questions

Comment voir les tentatives de connexion SSH échouées ?

Sur les systèmes avec systemd, lancez sudo journalctl -u ssh --grep 'Failed|Invalid' (sshd sur Red Hat). Avec les journaux texte, cherchez 'Failed password' dans /var/log/auth.log ou /var/log/secure avec grep. sudo lastb liste les échecs là où il est installé.

Où se trouve le journal SSH sous Ubuntu ?

Dans le journal, à lire avec sudo journalctl -u ssh, et dans /var/log/auth.log quand rsyslog est présent, ce qui est le cas par défaut sous Ubuntu.

Beaucoup de connexions SSH échouées, est-ce un problème ?

Sur un serveur public, c'est le bruit de fond normal des robots, et ils ne peuvent pas réussir si seules les clés sont acceptées. La ligne qui demande une action est un Accepted que vous ne pouvez pas expliquer.

Sources

Autres guides : Sécuriser un serveur

Tous les guides