Analyser les échecs de connexion SSH dans les journaux Linux

SSH, Secure Shell, est un protocole de communication sécurisée qui permet d'ouvrir une session distante sur un serveur Linux, un VPS ou un serveur dédié. Pour se connecter à une machine distante, le client SSH envoie une demande d'authentification au démon sshd. Quand cette connexion échoue, le message affiché en terminal ne suffit pas toujours à expliquer la cause. Les journaux du serveur SSH indiquent si l'utilisateur est inconnu, si l'authentification a échoué, si la clé RSA ou Ed25519 a été refusée, ou si la session distante a été interrompue. Ce guide propose une méthode pas à pas pour lire ces entrées d'authentification sur un serveur Linux, Debian, Ubuntu ou une autre distribution Unix, sans modifier la configuration à l'aveugle.

Avant de chercher dans les journaux SSH

Notez l'heure exacte de l'échec de connexion, le login utilisé et l'adresse IP du client SSH. Une heure imprécise rend les événements d'authentification difficiles à corréler dans les journaux. Vérifiez aussi que vous observez bien le serveur SSH concerné et non une autre machine distante de votre infrastructure.

Ne fermez pas votre terminal distant déjà ouvert avant d'avoir validé une nouvelle connexion SSH. Pour une intervention sensible sur votre serveur Linux ou votre VPS, préparez une session de secours. Le guide sur la configuration d'une clé SSH rappelle les précautions utiles lors d'un changement d'accès.

Identifier le journal du démon SSH

Sur les distributions utilisant systemd, commencez par interroger le journal de l'unité SSH. Le démon sshd écrit ses événements d'authentification dans le journal systemd. Selon la distribution Linux, le nom de l'unité peut être ssh ou sshd. Essayez les deux depuis un terminal si le premier ne renvoie aucun événement de connexion.

sudo journalctl -u ssh --since "30 minutes ago"
sudo journalctl -u sshd --since "30 minutes ago"

Sur certains serveurs Linux, les événements d'authentification SSH sont également écrits dans un fichier dédié. Sur Debian et Ubuntu, il s'agit de /var/log/auth.log ; sur CentOS et Rocky Linux, on consultera plutôt /var/log/secure. La commande suivante filtre les lignes SSH dans ce fichier de configuration de journalisation :

sudo grep -i sshd /var/log/auth.log
sudo grep -i sshd /var/log/secure

Pour une vue générale des erreurs récentes de services sur le serveur distant, vous pouvez aussi consulter notre méthode d'analyse des logs Linux avec journalctl.

Lire les messages d'authentification SSH les plus fréquents

Les entrées du journal SSH suivent un format structuré. Chaque ligne d'authentification contient l'heure, le nom de l'unité sshd, le PID du démon, le type d'événement et l'adresse IP du client SSH. Voici les messages les plus fréquents et leur signification.

Failed password

Ce message indique que le démon SSH a reçu une tentative d'authentification par mot de passe qui n'a pas abouti. Contrôlez le login, le clavier utilisé côté client SSH et la méthode d'authentification autorisée dans sshd_config. Si PasswordAuthentication no est défini, seule l'authentification par clé publique est acceptée. Plusieurs tentatives rapprochées depuis une même adresse IP peuvent signaler un balayage automatisé, mais le journal seul ne prouve pas l'intention.

Invalid user

Le login demandé n'est pas reconnu par le serveur ou n'est pas autorisé à ouvrir une session SSH. Vérifiez l'orthographe du compte, les directives AllowUsers et AllowGroups dans sshd_config, et la machine distante cible. Ne créez pas un compte uniquement pour faire disparaître ce message : confirmez d'abord que ce login est réellement nécessaire.

Permission denied publickey

Le démon SSH n'a pas accepté la clé publique présentée par le client. Les clés RSA, Ed25519 ou ECDSA doivent être référencées dans le fichier ~/.ssh/authorized_keys du bon compte sur le serveur distant. Vérifiez également que les permissions du répertoire SSH sont cohérentes : 700 pour .ssh, 600 pour authorized_keys. Si vous avez récemment changé la clé privée, contrôlez le chemin transmis au client SSH avec l'option -i. Le fingerprint affiché côté client doit correspondre à la clé publique enregistrée.

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Un client SSH en mode verbeux depuis votre terminal permet de confirmer quelle clé privée est proposée au démon et si elle est reconnue :

ssh -vvv login@adresse-du-serveur-distant

Connection closed ou Connection reset

Ces messages décrivent une fermeture de session SSH, mais ne désignent pas une cause unique. Cherchez les lignes voisines dans le journal d'authentification, contrôlez l'état du démon SSH et vérifiez les règles du firewall. La liste des ports en écoute permet de distinguer un démon SSH arrêté d'un service bloqué en amont du réseau local.

Filtrer les entrées d'authentification par login ou adresse IP

Quand le journal SSH contient de nombreuses lignes, filtrez une période courte puis cherchez le login ou l'adresse IP concernés. La commande suivante isole les événements SSH sur une machine distante pendant un intervalle précis :

sudo journalctl -u ssh --since "2026-01-01 10:00" --until "2026-01-01 10:15"
sudo journalctl -u ssh --since "30 minutes ago" | grep -E "Failed|Invalid|Accepted|authentication"
sudo journalctl -u ssh --since "30 minutes ago" | grep "203.0.113.10"

Les adresses IP et les horaires de connexion sont des données de diagnostic. Évitez de publier un extrait de journal complet dans un ticket : il peut révéler des logins, des adresses IP et des habitudes de connexion à une machine distante.

Distinguer une erreur de configuration d'une série de tentatives

Un seul échec d'authentification SSH après un changement de clé ou de login ressemble souvent à un problème de configuration. Une série de logins inexistants ou d'échecs de mots de passe provenant de nombreuses adresses mérite une analyse de sécurité plus approfondie. Ne concluez pas à une compromission sans preuve : recherchez une authentification réussie inhabituelle, un changement de compte ou une commande inattendue dans les autres journaux du serveur Linux.

La directive MaxAuthTries dans sshd_config limite le nombre de tentatives d'authentification par connexion. Pour réduire les tentatives répétées à grande échelle, consultez le guide consacré à la limitation des connexions SSH. La protection ne remplace pas des clés correctement gérées, des logins nominatifs et des sauvegardes vérifiées.

Vérifier le démon SSH et le réseau local

Après lecture des entrées d'authentification SSH, vérifiez que le démon est actif et qu'il écoute sur l'adresse et le port TCP attendus. Cette étape évite de confondre une authentification refusée avec un service inaccessible depuis le réseau local.

sudo systemctl status sshd
sudo ss -ltnp | grep ssh

Si le démon SSH n'écoute pas sur le port TCP attendu, contrôlez son fichier sshd_config avant tout redémarrage. Si le port est ouvert mais la connexion à la machine distante reste impossible, examinez le firewall local et le chemin réseau. Un routeur ou une règle de sécurité en amont peut bloquer le trafic SSH avant son arrivée sur le serveur. Le guide sur les ports Linux avec UFW aide à distinguer une règle locale d'un problème réseau en amont.

DNS et résolution de nom du serveur distant

Avant de conclure à un problème d'authentification SSH, vérifiez que le DNS résout correctement l'adresse du serveur distant. Un nom de domaine qui pointe vers une mauvaise adresse IP peut amener le client SSH à se connecter à la mauvaise machine. Si le client affiche une erreur de clé hôte inconnue ou modifiée dans ~/.ssh/known_hosts, comparez le fingerprint avec celui affiché lors d'une connexion directe par adresse IP. Un fingerprint différent peut signaler un problème DNS, pas un problème d'authentification SSH.

Pour approfondir le diagnostic DNS sur un serveur Linux, consultez le guide sur la résolution DNS défaillante.

Cas Debian, Ubuntu, CentOS et login root

Le chemin du journal d'authentification SSH varie selon la distribution et sa configuration. Sur Debian ou Ubuntu, auth.log est courant. Sur CentOS, Fedora et Rocky Linux, on utilisera plutôt /var/log/secure. D'autres systèmes s'appuient principalement sur le journal systemd pour l'ensemble des messages SSH.

Si la connexion SSH utilise le login root, vérifiez explicitement la directive PermitRootLogin dans sshd_config. Un refus d'authentification peut venir de cette directive, d'une restriction de groupe dans AllowGroups, d'un fichier inclus dans sshd_config.d/ ou d'un firewall. Une connexion avec un login administrateur nominatif puis une élévation avec sudo facilite le suivi des actions dans les journaux d'authentification.

Augmenter le niveau de journalisation du démon SSH

La directive LogLevel dans sshd_config contrôle la quantité d'informations SSH écrites dans les journaux. La valeur par défaut INFO couvre les événements d'authentification courants. VERBOSE ajoute le fingerprint de la clé utilisée à chaque connexion, ce qui aide à confirmer quelle clé privée a été présentée au démon. Rechargez le démon sans couper les sessions distantes existantes après cette modification, puis rétablissez INFO une fois le diagnostic SSH terminé.

Ne laissez pas un niveau élevé de journalisation en production : les journaux d'authentification peuvent grossir rapidement. Notre guide sur la rotation des journaux Linux explique comment archiver et purger ces entrées automatiquement.

Checklist de diagnostic SSH

• Conserver l'heure, le login et l'adresse IP du client SSH lors de l'échec d'authentification.
• Interroger le journal du démon sshd depuis un terminal avec une période courte.
• Rechercher les messages Failed password, Invalid user et Permission denied publickey.
• Vérifier les permissions du répertoire .ssh et du fichier authorized_keys.
• Contrôler les directives PermitRootLogin, AllowUsers et MaxAuthTries dans sshd_config.
• Vérifier que le démon SSH écoute sur le bon port TCP avec ss -ltnp.
• Contrôler la résolution DNS du serveur distant si le fingerprint ne correspond pas.
• Ne pas divulguer les journaux d'authentification complets dans un ticket ou un forum public.

Une fois la cause de l'échec SSH identifiée, documentez le changement effectué et testez une nouvelle connexion au serveur distant sans fermer votre accès de secours. Pour approfondir la maintenance d'un hôte Linux, retrouvez nos guides pour serveurs et VPS ou consultez les offres VPS Ubuntu.