Diagnostic et résolution des échecs d'authentification SSH

Secure Shell (SSH) est la pierre angulaire de l'administration à distance sécurisée, permettant un accès chiffré aux serveurs et aux périphériques réseau. Cependant, rencontrer des échecs d'authentification est une expérience courante et souvent frustrante pour les administrateurs système et les développeurs. Ces problèmes peuvent découler d'une myriade de causes, allant de simples fautes de frappe à des problèmes de permissions complexes ou des erreurs de configuration.

Cet article sert de guide complet pour diagnostiquer et résoudre efficacement les échecs d'authentification SSH. Nous allons explorer des méthodes de dépannage systématiques, en soulignant le rôle critique de la sortie verbeuse côté client et de l'analyse des journaux côté serveur. En comprenant comment interpréter ces indices de diagnostic, vous serez en mesure d'identifier la cause première de la plupart des problèmes d'authentification et de restaurer votre accès distant sécurisé.

Comprendre les méthodes d'authentification SSH

Avant de plonger dans le dépannage, il est essentiel de comprendre les principales méthodes d'authentification qu'SSH utilise :

• Authentification par mot de passe : L'utilisateur fournit un mot de passe, que le serveur vérifie par rapport à sa base de données d'utilisateurs ou à un service d'authentification externe (comme PAM).
• Authentification par clé publique : Cette méthode plus sécurisée utilise une paire de clés cryptographiques : une clé privée stockée sur le client et une clé publique correspondante stockée sur le serveur. Lors de l'authentification, le client utilise sa clé privée pour prouver son identité sans jamais envoyer la clé privée sur le réseau.

Les échecs d'authentification peuvent survenir avec l'une ou l'autre méthode, mais les étapes de dépannage diffèrent souvent.

Vérifications initiales et pièges courants

Avant de se plonger dans les journaux verbeux, il est judicieux d'effectuer quelques vérifications de base, car de nombreux problèmes sont souvent de simples oublis :

• Nom d'utilisateur et nom d'hôte corrects : Vérifiez que vous utilisez le bon nom d'utilisateur et l'adresse IP ou le nom d'hôte exact du serveur cible.
• Connectivité réseau : Pouvez-vous atteindre le serveur ? Utilisez ping pour vérifier la joignabilité réseau de base.
  bash ping example.com
• État du service SSH : Le serveur SSH (sshd) est-il réellement en cours d'exécution sur la machine cible ? Si vous avez un accès console, vérifiez son état.
  bash sudo systemctl status sshd # Pour les systèmes basés sur systemd (la plupart des Linux modernes) sudo service sshd status # Pour les systèmes init plus anciens
• Port SSH : Le démon SSH écoute-t-il sur le port par défaut (22) ou sur un port personnalisé ? S'il s'agit d'un port personnalisé, vous devrez le spécifier avec -p.
• Règles de pare-feu : Y a-t-il des pare-feu (côté client ou côté serveur) bloquant le port 22 (ou votre port SSH personnalisé) ? Vérifiez les pare-feu côté serveur comme ufw, firewalld ou les groupes de sécurité AWS.
  bash sudo ufw status sudo firewall-cmd --list-all

Diagnostic côté client : Exploiter le mode verbeux

Le client SSH offre des modes verbeux (-v, -vv, -vvv) qui fournissent une sortie de débogage détaillée sur le processus de connexion et les tentatives d'authentification. Cette sortie est inestimable pour comprendre pourquoi le client pense que l'authentification échoue.

Utilisation des indicateurs de verbosité

• -v : Sortie verbeuse.
• -vv : Sortie plus verbeuse.
• -vvv : Sortie encore plus verbeuse (souvent la plus utile pour les problèmes d'authentification).

Exemple de commande :

ssh -vvv username@your_server_ip

Interprétation de la sortie verbeuse

Lorsque vous exécutez ssh en mode verbeux, recherchez les lignes clés qui indiquent où le processus d'authentification échoue :

• debug1: Authentications that can continue: : Cette ligne vous indique quelles méthodes d'authentification le serveur est prêt à accepter. Si votre méthode souhaitée (par exemple, publickey) n'est pas répertoriée, la configuration du serveur l'empêche.
  debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
• debug1: Offering public key: : Ceci indique que votre client tente d'utiliser une clé publique spécifique pour l'authentification. Si vous vous attendez à une authentification par clé publique mais ne voyez pas cela, votre client ne trouve pas ou n'offre pas la clé.
  debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
• debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa : Ceci confirme que le client tente d'utiliser une clé privée spécifique.
• debug1: Server accepts key: ... : Ceci indiquerait une authentification par clé publique réussie du point de vue du client. Si vous ne voyez pas cela, la clé a probablement été rejetée par le serveur.
• debug1: No more authentication methods to try. : Cela apparaît souvent juste avant une erreur Permission denied et signifie que le client a épuisé toutes les méthodes d'authentification disponibles sans succès.
• debug1: Permission denied (publickey,password). : Ceci est l'erreur finale côté client, résumant le rejet du serveur de toutes les tentatives.

Conseil : Portez une attention particulière à l'ordre des méthodes d'authentification offertes et acceptées. Si publickey est offert mais immédiatement suivi d'une invite de mot de passe, cela signifie souvent que le serveur a rejeté la clé publique.

Diagnostic côté serveur : Examen des journaux du serveur SSH

Alors que la sortie verbeuse côté client montre ce que le client tente de faire, les journaux du serveur fournissent des informations définitives sur la raison pour laquelle le serveur a rejeté la tentative d'authentification. C'est souvent l'étape la plus critique dans l'analyse de la cause première.

Localisation des journaux du serveur SSH

L'emplacement des journaux du serveur SSH varie selon le système d'exploitation :

• Debian/Ubuntu et dérivés : /var/log/auth.log
• RHEL/CentOS/Fedora et dérivés : /var/log/secure
• Systèmes basés sur Systemd (la plupart des Linux modernes) : Vous pouvez également utiliser journalctl.

Affichage et filtrage des journaux du serveur

Utilisez des outils comme tail ou journalctl pour surveiller les journaux en temps réel ou filtrer les entrées spécifiques à SSH.

Exemples de commandes :

# Pour Debian/Ubuntu
sudo tail -f /var/log/auth.log | grep sshd

# Pour RHEL/CentOS
sudo tail -f /var/log/secure | grep sshd

# Pour les systèmes basés sur systemd (la manière la plus robuste d'afficher les journaux actuels)
sudo journalctl -u sshd -f

# Pour afficher tous les journaux sshd depuis le début (utile si l'échec s'est produit plus tôt)
sudo journalctl -u sshd

Entrées courantes des journaux du serveur et leur signification

Recherchez les messages liés à sshd lorsque vous tentez de vous connecter. Voici quelques entrées courantes indiquant des échecs d'authentification :

• Failed password for user from IP port ssh2 : Indique un échec de tentative d'authentification par mot de passe. Cela peut être dû à un mot de passe incorrect, ou si l'utilisateur n'est pas autorisé à se connecter par mot de passe.
• Authentication refused: bad ownership or modes for directory /home/user/.ssh : Il s'agit d'une erreur très courante d'authentification par clé publique. Le répertoire .ssh sur le serveur a des permissions incorrectes.
  • Solution : chmod 700 /home/user/.ssh
• Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys : Une autre erreur courante de clé publique, indiquant que le fichier authorized_keys a des permissions incorrectes.
  • Solution : chmod 600 /home/user/.ssh/authorized_keys
• sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open. : Indique explicitement le problème avec des modes de fichier trop permissifs. SSH est très strict sur les permissions pour des raisons de sécurité.
• User username from IP not allowed because not listed in AllowUsers : L'utilisateur n'est pas autorisé à se connecter via SSH selon la directive AllowUsers dans /etc/ssh/sshd_config.
• User username from IP not allowed because listed in DenyUsers : L'utilisateur est explicitement refusé l'accès SSH par DenyUsers.
• input_userauth_request: invalid user username : Le nom d'utilisateur fourni n'existe pas sur le serveur.
• Publickey authentication refused: authenticate using identity file. : Cela signifie généralement que la clé publique présentée par le client ne correspond à aucune clé dans le fichier authorized_keys du serveur pour cet utilisateur, ou que le format de la clé est incorrect.
• Maximum authentication attempts exceeded for user from IP : Le client a tenté trop de méthodes d'authentification ou envoyé trop de tentatives de connexion incorrectes. Contrôlé par MaxAuthTries dans sshd_config.
• Connection closed by authenticating user IP port 22 [preauth] : Cela peut se produire si aucune méthode d'authentification acceptable n'a été trouvée, ou si le client ferme brusquement la connexion après un échec.

Scénarios courants d'échec d'authentification et solutions

Classons les échecs courants et leurs remèdes spécifiques.

1. Échecs d'authentification par mot de passe

• Mot de passe incorrect : Le problème le plus simple. Vérifiez votre mot de passe. Faites attention aux dispositions du clavier, au verrouillage majuscule (Caps Lock) ou au verrouillage numérique (Num Lock).
• Utilisateur non autorisé : Le fichier sshd_config (/etc/ssh/sshd_config) pourrait restreindre la connexion pour certains utilisateurs.
  • PermitRootLogin no : Empêche la connexion de l'utilisateur root (fortement recommandé pour la sécurité).
  • AllowUsers username1 username2 : Seuls les utilisateurs spécifiés peuvent se connecter.
  • DenyUsers username : Les utilisateurs spécifiés ne peuvent pas se connecter.
  • AllowGroups groupname : Seuls les utilisateurs des groupes spécifiés peuvent se connecter.
  • Solution : Ajustez les directives de sshd_config et redémarrez sshd.
• Problèmes PAM : Si le serveur utilise les modules d'authentification enfichables (PAM), des problèmes de configuration PAM peuvent empêcher l'authentification par mot de passe. Vérifiez /var/log/auth.log pour les erreurs spécifiques à PAM. C'est moins courant pour les configurations SSH de base.

2. Échecs d'authentification par clé publique

L'authentification par clé publique est souvent plus sécurisée mais sujette à plus d'erreurs liées à la configuration.

• Permissions de fichier/répertoire incorrectes (côté serveur) : C'est de loin la cause la plus courante. SSH exige des permissions strictes pour ~/.ssh et ~/.ssh/authorized_keys pour des raisons de sécurité.
  • ~ : Le répertoire personnel de l'utilisateur ne doit pas être accessible en écriture par le monde entier (chmod 755 ~ est généralement sûr).
  • ~/.ssh : Doit être 700 (rwx pour le propriétaire uniquement).
    bash chmod 700 ~/.ssh
  • ~/.ssh/authorized_keys : Doit être 600 (rw pour le propriétaire uniquement).
    bash chmod 600 ~/.ssh/authorized_keys
  • Le propriétaire de ces fichiers et répertoires doit être l'utilisateur tentant de se connecter.
    bash sudo chown -R username:username ~/.ssh
• Contenu authorized_keys incorrect : La clé publique dans ~/.ssh/authorized_keys peut être corrompue, contenir des caractères supplémentaires ou être dans un format incorrect. Chaque clé doit être sur une seule ligne. Une façon rapide de garantir le bon format est d'utiliser ssh-copy-id depuis le client.
  bash ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
  Pour vérifier l'empreinte de votre clé publique côté client, utilisez : ssh-keygen -l -f ~/.ssh/id_rsa.pub
• Le client n'offre pas la clé : La clé privée peut ne pas se trouver à l'emplacement par défaut (~/.ssh/id_rsa), ne pas être chargée dans ssh-agent, ou vous ne l'avez pas spécifiée avec -i.
  • Solution : Assurez-vous que votre clé privée est id_rsa (ou id_ed25519, etc.) dans ~/.ssh et qu'elle a les permissions 600. Sinon, spécifiez-la :
    bash ssh -i /path/to/your/private_key username@your_server_ip
  • Si vous utilisez ssh-agent, assurez-vous que votre clé est ajoutée :
    bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/your_private_key
• sshd_config interdisant l'authentification par clé publique : Le démon SSH du serveur pourrait être configuré pour interdire l'authentification par clé publique.
  • Vérifiez PubkeyAuthentication yes dans /etc/ssh/sshd_config.
  • Vérifiez AuthorizedKeysFile .ssh/authorized_keys pour vous assurer qu'il pointe vers le bon fichier. Le défaut est généralement suffisant.
  • Solution : Définissez PubkeyAuthentication yes et redémarrez sshd.
• Interférence de SELinux/AppArmor : Sur les systèmes avec SELinux ou AppArmor, ces modules de sécurité peuvent parfois empêcher SSH d'accéder aux répertoires personnels des utilisateurs ou aux fichiers .ssh, même si les permissions de fichier sont correctes. Vérifiez les journaux d'audit (/var/log/audit/audit.log ou sudo ausearch -m AVC -ts recent) pour des indices. Il s'agit d'un scénario avancé.

3. Connexion refusée ou délai d'attente dépassé

Bien que n'étant pas strictement des échecs « d'authentification », ceux-ci précèdent souvent les tentatives d'authentification et les empêchent même de démarrer.

• Blocage par le pare-feu : Vérifiez les pare-feu côté client (par exemple, pare-feu du système d'exploitation local) et côté serveur (par exemple, ufw, firewalld, groupes de sécurité cloud, listes de contrôle d'accès réseau). Assurez-vous que le port 22 (ou le port personnalisé) est ouvert.
• Serveur SSH non démarré : Le service sshd pourrait ne pas être actif ou avoir planté.
• Port/IP incorrect : Tentative de connexion à un port ou une adresse IP erronés.

Conseils de débogage généraux

• Vérifier sshd_config : Examinez toujours /etc/ssh/sshd_config sur le serveur pour toute configuration non par défaut qui pourrait interférer. Après avoir apporté des modifications, redémarrez toujours le démon SSH : sudo systemctl restart sshd (ou sudo service sshd restart).
• Tester avec un nouvel utilisateur/une nouvelle clé : Si possible, créez un nouvel utilisateur et une nouvelle paire de clés publique/privée. Essayez de vous authentifier avec cette nouvelle configuration. Si cela fonctionne, le problème est spécifique à la configuration de l'utilisateur d'origine.
• Isoler le problème : Essayez de vous connecter depuis une machine cliente différente. Si cela fonctionne, le problème est spécifique au client. Si cela échoue depuis plusieurs clients, le problème est spécifique au serveur.
• Augmenter le niveau de journalisation (côté serveur) : Pour un débogage approfondi, vous pouvez temporairement définir LogLevel DEBUG dans /etc/ssh/sshd_config et redémarrer sshd. N'oubliez pas de rétablir ce paramètre après le dépannage, car les journaux de débogage peuvent être très verbeux et consommer de l'espace disque.

Conclusion

Le diagnostic des échecs d'authentification SSH nécessite une approche systématique, combinant la sortie verbeuse côté client avec l'analyse des journaux côté serveur. En examinant méticuleusement les indices fournis par ssh -vvv et les journaux du démon SSH (auth.log ou secure), vous pouvez identifier efficacement le point exact de l'échec, qu'il s'agisse d'un mot de passe incorrect, d'une clé publique mal configurée, de permissions de fichier strictes ou d'un paramètre côté serveur.

N'oubliez pas de commencer par les vérifications simples, puis de passer à la sortie verbeuse côté client, et enfin, d'exploiter les informations définitives des journaux du serveur. Grâce à ces techniques, vous serez bien équipé pour résoudre même les problèmes d'authentification SSH les plus complexes et maintenir un accès sécurisé à vos systèmes distants.