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

Secure Shell (SSH) est le fondement de l'administration à distance sécurisée, permettant un accès chiffré aux serveurs et aux équipements 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 provenir d'une multitude 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 explorerons des méthodes de dépannage systématiques, en mettant l'accent sur le rôle critique des sorties détaillées 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 profonde de la plupart des problèmes d'authentification et de rétablir votre accès à distance 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 utilisées par SSH :

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.

Des é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 vous plonger dans les journaux détaillés, il est prudent 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 le nom d'hôte exact ou l'adresse IP du serveur cible.
Connectivité réseau : Pouvez-vous atteindre le serveur ? Utilisez nc -vz host 22 ou ssh -vvv pour tester la joignabilité SSH. ping peut aider, mais de nombreux serveurs bloquent ICMP même lorsque SSH fonctionne.
```
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.

sudo systemctl status sshd # Pour les systèmes basés sur systemd (la plupart des Linux modernes)
sudo service sshd status    # Pour les anciens systèmes init

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 du serveur comme ufw, firewalld ou les groupes de sécurité AWS.
```
sudo ufw status
sudo firewall-cmd --list-all
```

Diagnostics côté client : exploitation du mode verbeux

Le client SSH propose des modes verbeux (-v, -vv, -vvv) qui fournissent des informations de débogage détaillées 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 verbeux

-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 nom_utilisateur@adresse_ip_serveur

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 les méthodes d'authentification que le serveur est prêt à accepter. Si votre méthode souhaitée (par exemple, publickey) n'est pas listée, la configuration du serveur l'empêche.
```
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
```
debug1: Offering public key: : Cela indique que votre client tente d'utiliser une clé publique spécifique pour l'authentification. Si 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 : Cela confirme que le client tente d'utiliser une clé privée spécifique.
debug1: Server accepts key: ... : Cela 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). : Il s'agit de l'erreur finale côté client, résumant le rejet par le serveur de toutes les tentatives.

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

Diagnostics côté serveur : examen des journaux du serveur SSH

Alors que la sortie détaillée côté client montre ce que le client essaie de faire, les journaux du serveur fournissent des informations définitives sur la raison pour laquelle le serveur a rejeté la tentative d'authentification. Il s'agit souvent de l'étape la plus critique de l'analyse des causes profondes.

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 (méthode la plus robuste pour 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 de journal courantes 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 qu'une tentative d'authentification par mot de passe a échoué. Cela peut être dû à un mot de passe incorrect, ou si l'utilisateur n'est pas autorisé à se connecter via un mot de passe.
Authentication refused: bad ownership or modes for directory /home/user/.ssh : Il s'agit d'une erreur d'authentification par clé publique très courante. 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 de clé publique courante, 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 concernant 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 se voit explicitement refuser l'accès SSH par DenyUsers.
input_userauth_request: invalid user username : Le nom d'utilisateur fourni n'existe pas sur le serveur.
Failed publickey for user ou clés proposées à plusieurs reprises suivies d'un mot de passe : la clé publique présentée par le client ne correspondait pas à une clé acceptée pour cet utilisateur, ou le serveur a refusé la clé en raison de permissions ou de politique.
Maximum authentication attempts exceeded for user from IP : Le client a essayé trop de méthodes d'authentification ou a envoyé trop d'identifiants incorrects. 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

Classifions 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. Soyez conscient des dispositions du clavier, du verrouillage des majuscules ou du verrouillage numérique.
Utilisateur non autorisé : Le fichier sshd_config (/etc/ssh/sshd_config) peut restreindre la connexion pour certains utilisateurs.
- PermitRootLogin no : Empêche la connexion 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 sshd_config et redémarrez sshd.
Problèmes PAM : Si le serveur utilise des 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 à davantage d'erreurs liées à la configuration.

Permissions incorrectes des fichiers/répertoires (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 au monde entier (chmod 755 ~ est généralement sûr).
- ~/.ssh : Doit être 700 (rwx pour le propriétaire uniquement).
```
chmod 700 ~/.ssh
```
- ~/.ssh/authorized_keys : Doit être 600 (rw pour le propriétaire uniquement).
```
chmod 600 ~/.ssh/authorized_keys
```
- Le propriétaire de ces fichiers et répertoires doit être l'utilisateur qui tente de se connecter.
```
sudo chown -R username:username ~/.ssh
```
Contenu incorrect de authorized_keys : 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. Un moyen rapide d'assurer un format correct est d'utiliser ssh-copy-id depuis le client.
```
ssh-copy-id -i ~/.ssh/id_rsa.pub nom_utilisateur@adresse_ip_serveur
```
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 a les permissions 600. Sinon, spécifiez-la :
```
ssh -i /chemin/vers/votre/cle_privee nom_utilisateur@adresse_ip_serveur
```
- Si vous utilisez ssh-agent, assurez-vous que votre clé est ajoutée :
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/votre_cle_privee
```
sshd_config interdisant l'authentification par clé publique : Le démon SSH du serveur peut ê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. La valeur par défaut est généralement correcte.
- Solution : Définissez PubkeyAuthentication yes et redémarrez sshd.
Interférence 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 des fichiers sont correctes. Vérifiez les journaux d'audit (/var/log/audit/audit.log ou sudo ausearch -m AVC -ts recent) pour obtenir des indices. C'est un scénario avancé.

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

Bien qu'il ne s'agisse pas strictement d'échecs d'"authentification", ils précèdent souvent les tentatives d'authentification et les empêchent même de démarrer.

Pare-feu bloquant : Vérifiez les pare-feu à la fois sur le client (par exemple, pare-feu du système d'exploitation local) et sur le serveur (par exemple, ufw, firewalld, groupes de sécurité cloud, ACL réseau). Assurez-vous que le port 22 (ou le port personnalisé) est ouvert.
Serveur SSH ne fonctionnant pas : Le service sshd peut ne pas être actif ou avoir planté.
Port/IP incorrect : Tentative de connexion sur le mauvais port ou la mauvaise adresse IP.

Conseils généraux de débogage

Vérifiez sshd_config : Examinez toujours /etc/ssh/sshd_config sur le serveur pour détecter tout paramètre non par défaut qui pourrait interférer. Après avoir effectué des modifications, redémarrez toujours le démon SSH : sudo systemctl restart sshd (ou sudo service sshd restart).
Testez avec un nouvel utilisateur/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.
Isolez le problème : Essayez de vous connecter à partir d'une autre machine cliente. 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.
Augmentez 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 revenir à 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.

À retenir

Utilisez ssh -vvv pour voir ce que votre client propose, puis vérifiez les journaux du serveur pour savoir pourquoi sshd l'a rejeté. La plupart des échecs de clé publique se résument à une mauvaise clé, une entrée authorized_keys manquante, des permissions de fichier strictes ou une règle sshd_config qui bloque l'utilisateur ou la méthode.