Dépannage des erreurs courantes "Permission denied" et des problèmes de connexion SSH

Secure Shell (SSH) est le pilier de la gestion des serveurs à distance, offrant une communication cryptée pour accéder et contrôler les systèmes distants. Bien que fiable, la configuration de SSH, en particulier avec l'authentification par clé, peut parfois entraîner des échecs de connexion frustrants. Le coupable le plus fréquent est la redoutée erreur Permission denied.

Ce guide complet vous accompagnera dans le diagnostic et la résolution des erreurs SSH les plus fréquentes. Nous nous concentrerons spécifiquement sur la compréhension des causes profondes de Permission denied (publickey) et aborderons les pièges courants liés aux permissions de fichiers, à une configuration incorrecte et aux incompatibilités entre le client et le serveur. La maîtrise de ces étapes de dépannage garantira un accès sécurisé et fiable à votre infrastructure distante.

Comprendre le flux d'authentification SSH

Avant de dépanner, il est crucial de comprendre comment SSH authentifie les utilisateurs. Lorsque vous tentez de vous connecter, le serveur vérifie généralement les identifiants dans l'ordre suivant (selon la configuration) :

Authentification par clé publique : Le client présente une clé publique, et le serveur vérifie si la clé privée correspondante est valide et correspond à une clé autorisée (fichier authorized_keys).
Authentification par mot de passe : Si l'authentification par clé échoue ou est désactivée, le serveur demande un mot de passe.

Lorsque vous recevez Permission denied, cela signifie presque toujours que le serveur a rejeté vos identifiants lors de l'étape 1 ou 2.

Diagnostic des problèmes de connexion : La puissance du mode verbeux

L'outil le plus efficace pour diagnostiquer les problèmes SSH est d'exécuter le client en mode verbeux. En ajoutant les indicateurs -v, -vv, ou -vvv, le client affiche des informations de débogage détaillées sur le processus de négociation.

Utilisation des indicateurs verbeux

Utilisez la structure de commande suivante :

ssh -vvv utilisateur@hote_distant

Ce qu'il faut rechercher dans la sortie :

Échange de clés : Recherchez les lignes indiquant les méthodes d'authentification que le client a essayées (par exemple, Offering RSA key: /chemin/vers/id_rsa).
Réponse du serveur : Portez une attention particulière aux messages de rejet du serveur. Si la sortie indique que le serveur vérifie les clés mais ne parvient pas à les faire correspondre, le problème est probablement lié à la configuration des clés ou aux permissions côté serveur.
Demande de mot de passe : Si la sortie ignore les vérifications de clés et demande immédiatement un mot de passe, l'authentification par clé peut être désactivée sur le serveur.

Résolution de `Permission denied (publickey)`

Cette erreur indique explicitement que le serveur a rejeté l'identifiant de clé publique fourni. La correction réside généralement dans les permissions ou l'appariement des clés.

1. Vérifier les permissions du fichier de clé (côté client)

Pour des raisons de sécurité, les clients SSH sont très stricts quant aux permissions de votre fichier de clé privée (par exemple, ~/.ssh/id_rsa). Si ces fichiers sont trop ouverts, le client refusera de les utiliser.

Correction actionnable (client) : Assurez-vous que votre clé privée n'est lisible que par vous.

chmod 600 ~/.ssh/id_rsa

2. Vérifier l'existence de la clé et son utilisation correcte

Assurez-vous que vous vous connectez avec le bon fichier d'identité, surtout si vous utilisez des clés non standard ou plusieurs paires de clés.

Correction actionnable (client) : Spécifiez la clé privée correcte à l'aide de l'indicateur -i.

ssh -i /chemin/vers/votre/cle_privee_specifique utilisateur@hote_distant

3. Permissions et propriété côté serveur

C'est la source la plus fréquente d'échec. SSH applique des permissions strictes sur les répertoires et les fichiers sur le serveur pour l'utilisateur sous lequel vous essayez de vous connecter.

Chemin sur le serveur	Permissions requises	Propriétaire
Répertoire `~/.ssh`	`700` (rwx------)	Utilisateur
Fichier `~/.ssh/authorized_keys`	`600` (rw-------)	Utilisateur

Correction actionnable (serveur) : Connectez-vous via la console ou l'authentification par mot de passe (si activée) et exécutez ces commandes :

# Définir les permissions du répertoire
chmod 700 ~/.ssh

# Définir les permissions du fichier authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Vérifier la propriété (remplacer 'monutilisateur' par le nom d'utilisateur réel)
chown -R monutilisateur:monutilisateur ~/.ssh

Avertissement : Si les permissions du répertoire personnel de l'utilisateur (~/) sont trop larges (par exemple, inscriptibles par le groupe ou d'autres), SSH peut également échouer pour des raisons de sécurité. Visez 755 ou plus strict sur ~/ si les problèmes persistent.

4. Confirmer que la clé est bien ajoutée

Assurez-vous que la chaîne de clé publique du client correspond exactement à ce qui est collé dans le fichier ~/.ssh/authorized_keys du serveur. Un caractère manquant ou un espace blanc final entraînera un échec d'authentification.

Astuce : Lors de l'ajout d'une clé, utilisez ssh-copy-id si disponible, car il gère automatiquement les permissions et le formatage :

ssh-copy-id utilisateur@hote_distant

Dépannage des problèmes de fichier de configuration (`sshd_config`)

Si les clés et les permissions sont correctes, le problème réside souvent dans le fichier de configuration du démon SSH, généralement situé à /etc/ssh/sshd_config sur le serveur.

1. Vérifier les méthodes d'authentification

Assurez-vous que l'authentification par clé publique est explicitement autorisée.

Vérification de la configuration : Recherchez les lignes suivantes et assurez-vous qu'elles ne sont pas commentées (#) et correctement définies :

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. Statut de l'authentification par mot de passe

Si vous vous reposez temporairement sur la connexion par mot de passe, vérifiez qu'elle est activée. Si elle est définie sur no, vous devez utiliser des clés.

PasswordAuthentication yes

3. PermitRootLogin

Si vous essayez de vous connecter en tant que root, assurez-vous que cela est autorisé. La meilleure pratique est généralement de se connecter en tant qu'utilisateur standard et d'utiliser sudo, mais pour le dépannage, vous pouvez vérifier ce paramètre :

PermitRootLogin yes

Étape cruciale : Après toute modification de /etc/ssh/sshd_config, vous devez redémarrer le service SSH pour que les changements prennent effet :
bash sudo systemctl restart sshd # Ou service ssh restart

Autres erreurs de connexion courantes

Bien que les problèmes de clés soient primordiaux, d'autres erreurs peuvent bloquer l'accès :

A. Délai d'attente de connexion dépassé (Connection Timed Out)

Cela signifie généralement que le client n'a pas pu atteindre le serveur du tout, ce qui indique un problème de réseau, et non un problème d'authentification.

Causes possibles :
* Le serveur est arrêté ou injoignable.
* Un pare-feu (local ou réseau) bloque la connexion sur le port 22 (ou le port SSH personnalisé).
* Adresse IP ou nom d'hôte incorrect.

Dépannage : Utilisez ping pour vérifier la connectivité de base, et telnet ou nc (netcat) pour vérifier si le port est ouvert :

# Vérifier si le port 22 est joignable
telnet hote_distant 22

B. Aucun chemin vers l'hôte (No Route to Host)

Similaire au délai d'attente dépassé, il s'agit d'un problème d'infrastructure réseau. Le client ne trouve pas de chemin vers l'adresse IP du serveur. Vérifiez les tables de routage, l'état du VPN, ou assurez-vous que le serveur distant a une interface réseau valide active.

C. Le serveur a refusé notre clé (Server Refused Our Key)

Si la sortie verbeuse indique que le serveur rejette activement les clés, mais que vous avez vérifié le fichier authorized_keys, vérifiez les contextes de sécurité SELinux ou AppArmor sur le serveur. Ces modules de sécurité peuvent remplacer les permissions de fichiers et bloquer l'accès SSH si les contextes sont incorrects.

Résumé des meilleures pratiques

Utilisez toujours le mode verbeux (-vvv) pour le diagnostic.
Sécurité des clés du client : Assurez-vous que les clés privées sont définies sur 600 (chmod 600).
Intégrité des fichiers serveur : Vérifiez que ~/.ssh est 700 et authorized_keys est 600.
Redémarrer le démon : Redémarrez toujours sshd après avoir modifié /etc/ssh/sshd_config.
Utilisez ssh-copy-id chaque fois que possible pour automatiser le déploiement des clés.