Analyser les échecs de connexion SSH dans les logs Linux

Quand une connexion SSH échoue, le message affiché par le client ne suffit pas toujours à expliquer le problème. Les journaux du serveur indiquent si l’utilisateur est inconnu, si l’authentification a échoué, si la clé publique a été refusée ou si le service SSH a rejeté la session. Ce guide propose une méthode courte pour analyser ces échecs sur un serveur Linux, Debian, Ubuntu ou une autre distribution Unix, sans modifier la configuration à l’aveugle.

Avant de chercher dans les journaux

Notez l’heure exacte de l’échec, le nom du compte utilisé et l’adresse IP cliente. Une heure imprécise rend les événements difficiles à corréler. Vérifiez aussi que vous observez bien le serveur concerné et non un autre hôte de votre infrastructure.

Ne fermez pas votre session SSH déjà ouverte avant d’avoir validé une nouvelle connexion. Pour une intervention sensible, préparez une seconde session et conservez un accès 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 SSH

Sur les distributions utilisant systemd, commencez par interroger le journal du service SSH. Selon la distribution, le nom de l’unité peut être ssh ou sshd. Essayez les deux noms si le premier ne renvoie aucun événement.

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

Sur certains systèmes, les événements d’authentification sont également écrits dans un fichier comme /var/log/auth.log ou /var/log/secure. Consultez uniquement le fichier présent sur votre système :

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

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

Lire les messages les plus fréquents

Failed password

Ce message indique que le serveur a reçu une tentative d’authentification par mot de passe qui n’a pas abouti. Contrôlez le compte, le clavier utilisé côté client et la méthode d’authentification autorisée. Plusieurs tentatives rapprochées depuis une même adresse peuvent aussi signaler un balayage automatisé, mais le journal seul ne prouve pas l’intention de l’émetteur.

Invalid user

Le nom d’utilisateur demandé n’est pas connu du serveur ou n’est pas accepté dans ce contexte. Vérifiez l’orthographe du compte et la machine cible. Ne créez pas un compte uniquement pour faire disparaître le message : confirmez d’abord que ce compte est réellement nécessaire.

Permission denied publickey

Le serveur n’a pas accepté la clé présentée. Vérifiez que la clé publique correspondante se trouve dans le fichier authorized_keys du bon compte, que les permissions du dossier personnel sont cohérentes et que le client utilise bien la clé privée attendue. Si vous avez récemment déplacé une clé, contrôlez le chemin transmis au client avec l’option -i.

Connection closed ou Connection reset

Ces messages décrivent une fermeture de session, mais ne désignent pas une cause unique. Cherchez les lignes voisines dans le journal, contrôlez l’état du service et vérifiez les règles du firewall ou pare-feu. Une liste de ports en écoute permet de distinguer un service absent d’un service bloqué plus loin sur le réseau.

Filtrer par compte ou par adresse IP

Quand le journal contient beaucoup de lignes, filtrez avec une période courte puis recherchez le compte ou l’adresse IP concernés. Cette approche réduit les faux rapprochements entre plusieurs utilisateurs.

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 sont des données de diagnostic. Évitez de publier un extrait de journal complet : il peut révéler des noms de comptes, des adresses et des habitudes de connexion.

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

Une seule erreur après un changement de clé ressemble souvent à un problème de configuration. Une série de noms d’utilisateur inexistants ou de mots de passe refusés provenant de nombreuses adresses mérite une analyse de sécurité complémentaire. 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.

Pour réduire les tentatives répétées, consultez le guide consacré à la limitation des connexions SSH. La protection ne remplace pas des clés correctement gérées, des comptes nominatifs et des sauvegardes vérifiées.

Vérifier le service et le réseau

Après lecture des logs, vérifiez que le service est actif et qu’il écoute sur l’adresse et le port attendus. Cette étape évite de confondre une authentification refusée avec un service qui n’est pas joignable.

sudo systemctl status ssh
sudo ss -ltnp | grep ssh

Si le service n’écoute pas, contrôlez son fichier de configuration avant tout redémarrage. Si le service écoute mais reste inaccessible, examinez le firewall, le pare-feu, le réseau local et le chemin réseau. Un VPN, un routeur ou une règle de sécurité située en amont peut bloquer le trafic 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 situé en amont.

Cas Debian, Ubuntu et compte root

Le chemin du journal varie selon la distribution et sa configuration. Sur Debian ou Ubuntu, auth.log est courant, tandis que d’autres systèmes s’appuient principalement sur le journal systemd. Le nom du service, le format des lignes et la politique d’authentification peuvent donc différer.

Si la connexion utilise le compte root, vérifiez explicitement la politique SSH au lieu de modifier plusieurs options. Un refus peut venir de PermitRootLogin, d’une restriction de groupe, d’un fichier de configuration inclus ou d’un firewall. Une connexion avec un compte administrateur nominatif, puis une élévation contrôlée avec sudo, facilite le suivi des actions dans les logs.

Depuis Windows, le client SSH peut être lancé dans PowerShell ou un terminal, donc en ligne de commande. Le serveur distant reçoit le même type de tentative, mais le chemin de la clé privée et le format de l’erreur affichée côté client peuvent changer. Comparez toujours le message local avec l’événement présent sur le serveur.

Ne pas confondre SSH, DNS et service Web

Un nom de domaine qui ne se résout pas, un port TCP filtré et une authentification refusée sont trois problèmes différents. Si le nom ne mène pas à la bonne adresse, vérifiez le DNS. Si l’adresse répond mais que le port est fermé, vérifiez le firewall et le service. Si le serveur journalise la tentative puis la refuse, concentrez-vous sur le compte, la clé ou la politique SSH.

Cette séparation est particulièrement utile sur un serveur dédié qui héberge à la fois SSH, un service Web, une base de données ou des scripts d’administration. Un diagnostic ciblé évite de modifier Apache, le proxy ou un autre service qui n’est pas à l’origine du refus.

Shell distant, protocoles et chiffrement

SSH fournit une session shell distante et transporte plusieurs usages dans une même connexion : administration en ligne de commande, transfert de fichiers et tunnels. Les journaux d’authentification décrivent surtout l’accès au service, pas nécessairement l’action réalisée ensuite dans le shell. Pour comprendre une action, croisez les journaux SSH avec ceux du système et du service concerné.

Le chiffrement protège le transport, mais il ne corrige pas un mauvais login, une clé absente ou une configuration invalide. Avant de désactiver l’authentification par mot de passe, testez une clé depuis une seconde session et conservez un compte administrateur de secours. Cette vérification évite de vous verrouiller hors du serveur.

Contrôler la configuration sans perdre l’accès

Avant de modifier la configuration du serveur SSH, faites une copie de sauvegarde du fichier concerné et notez la version actuelle. Relisez les répertoires inclus, les restrictions de groupe et les chemins de clés. Testez la syntaxe avec l’outil disponible sur votre système avant de redémarrer le service. Une sauvegarde de configuration n’est pas une sauvegarde complète des bases de données ou des fichiers, mais elle permet de revenir sur une modification ciblée.

Les scripts d’administration doivent conserver leurs logs et leurs codes de retour. Après un redémarrage, recherchez un message d’erreur dans journalctl. Ne redémarrez pas plusieurs fois sans lire le résultat : un service SSH mal configuré peut interrompre une session et compliquer la récupération.

Checklist de diagnostic

• Conserver l’heure, le compte et l’adresse IP de l’échec.
• Interroger l’unité ssh ou sshd avec une période courte.
• Rechercher les messages Failed, Invalid et Permission denied.
• Comparer une tentative réussie et une tentative refusée.
• Vérifier le service, le port d’écoute, le firewall et le chemin réseau.
• Contrôler le compte root, les clés et le fichier de configuration sans perdre l’accès.
• Ne pas divulguer les journaux complets dans un ticket ou un forum public.

Une fois la cause identifiée, documentez le changement effectué et testez une nouvelle connexion 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.