Résolution des erreurs SSH 'Permission refusée' et des problèmes de connexion
Maîtrisez la connectivité SSH en apprenant à surmonter les erreurs 'Permission refusée'. Ce guide détaille l'utilisation du mode verbeux (`-vvv`) pour diagnostiquer les échecs d'authentification, corriger les permissions critiques des fichiers côté serveur (`700`/`600`) pour les répertoires `.ssh`, et vérifier les paramètres de configuration nécessaires dans `sshd_config` pour un accès distant fiable.
Résolution des erreurs SSH 'Permission refusée' et des problèmes de connexion
Une erreur SSH Permission denied signifie généralement que le serveur était joignable, mais qu'il a refusé de vous authentifier. Cela diffère de Connection timed out, Connection refused ou No route to host. Traiter toutes ces erreurs comme "SSH est cassé" fait perdre du temps, alors commencez par distinguer les échecs d'authentification des échecs réseau.
Exécutez la commande qui échoue avec une journalisation verbeuse :
ssh -vvv user@remote_host
Vous cherchez des indices clairs : quel nom d'utilisateur le client a utilisé, quels fichiers de clé il a proposés, si le serveur a accepté une clé, et quelles méthodes d'authentification restent. La plupart des correctifs ci-dessous consistent à faire correspondre ces indices à l'état côté serveur.
Comprendre le flux d'authentification SSH
Lorsque vous tentez de vous connecter, le serveur n'autorise que les méthodes d'authentification activées dans sa configuration. Un serveur typique essaie d'abord l'authentification par clé publique et peut autoriser l'authentification par mot de passe ensuite, selon la politique :
- 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, la connexion TCP a fonctionné. Le serveur n'a tout simplement pas accepté les informations d'identification que vous avez présentées pour cet utilisateur.
Diagnostiquer les 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 user@remote_host
Que rechercher dans la sortie :
- Nom d'utilisateur : Recherchez
Authenticating to ... as 'user'. Un mauvais nom d'utilisateur Linux est l'une des erreurs les plus faciles à manquer. - Clés proposées : Recherchez
Offering public key. Si la clé attendue n'apparaît jamais, corrigez la configuration du client. - Réponse du serveur : Si chaque clé proposée est suivie de
Authentications that can continue, le serveur a rejeté ces clés. - Méthodes d'authentification : Si
publickeyn'est pas listé, le serveur peut ne pas autoriser l'authentification par clé pour ce compte ou ce bloc d'hôte.
Résoudre Permission denied (publickey)
Cette erreur indique explicitement que le serveur a rejeté la clé publique fournie. La solution réside généralement dans les permissions ou l'appariement des clés.
1. Vérifier les permissions des fichiers de clé (côté client)
Pour des raisons de sécurité, les clients SSH sont très stricts concernant les 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.
Assurez-vous que votre clé privée est uniquement lisible par vous :
chmod 600 ~/.ssh/id_rsa
2. Vérifier l'existence de la clé et l'utilisation de la bonne clé
Assurez-vous de vous connecter avec le fichier d'identité correct, surtout si vous utilisez des clés non standard ou plusieurs paires de clés.
Spécifiez la clé privée correcte à l'aide de l'indicateur -i :
ssh -i /path/to/your/specific_private_key user@remote_host
Si votre agent a chargé de nombreuses clés, ajoutez IdentitiesOnly=yes pour ce test :
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod user@remote_host
3. Permissions et propriété côté serveur
C'est la source la plus courante d'échec d'authentification par clé. SSH applique des permissions strictes sur les répertoires et fichiers côté serveur pour l'utilisateur auquel 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 |
Connectez-vous via la console, la console série cloud, l'authentification par mot de passe ou un autre compte administrateur et exécutez ces commandes en tant qu'utilisateur cible ou avec le bon chemin :
# Définir les permissions du répertoire
chmod 700 ~/.ssh
# Définir les permissions de authorized_keys
chmod 600 ~/.ssh/authorized_keys
# Vérifier la propriété (remplacer 'myuser' par le nom d'utilisateur réel)
chown -R myuser:myuser ~/.ssh
Si le répertoire personnel de l'utilisateur est accessible en écriture par le groupe ou d'autres, OpenSSH peut également rejeter la clé lorsque StrictModes est activé. Vérifiez avec :
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
Pour la plupart des répertoires personnels normaux, 755 ou plus strict est acceptable.
4. Confirmer que la clé est effectivement ajoutée
Assurez-vous que la clé publique sur le client correspond à ce qui est collé dans le fichier ~/.ssh/authorized_keys du serveur. Un caractère manquant, une ligne enroulée ou une clé privée copiée entraînera un échec d'authentification.
Lors de l'ajout d'une clé, utilisez ssh-copy-id si l'accès par mot de passe est toujours disponible :
ssh-copy-id user@remote_host
Résoudre les 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 qu'elles sont correctement définies :
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Vérifiez également les blocs Match près du bas du fichier. Un paramètre global peut autoriser les clés publiques, tandis qu'un bloc Match User, Match Group ou Match Address ultérieur peut les désactiver pour la connexion exacte que vous testez.
2. Statut de l'authentification par mot de passe
Si vous comptez 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 prohibit-password
Pour la connexion root, de nombreux systèmes par défaut autorisent l'accès root uniquement par clé ou désactivent complètement la connexion root. Préférez un utilisateur normal avec sudo. Si vous devez modifier les paramètres du démon SSH, validez la syntaxe avant de recharger :
sudo sshd -t
sudo systemctl reload sshd # Certains systèmes utilisent : sudo systemctl reload ssh
Autres erreurs de connexion courantes
Bien que les problèmes de clé soient primaires, d'autres erreurs peuvent bloquer l'accès :
A. Connexion expirée (Connection Timed Out)
Cela signifie généralement que le client n'a pas pu joindre le serveur du tout, indiquant un problème réseau, et non un problème d'authentification.
Causes possibles :
- Le serveur est hors service 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.
Utilisez ping pour un indice de base sur la joignabilité et nc pour vérifier le port SSH :
nc -vz remote_host 22
B. Aucune route vers l'hôte (No Route to Host)
Similaire à un délai d'attente, c'est un problème d'infrastructure réseau. Le client ne peut pas trouver 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 montre 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.
Un ordre pratique qui fonctionne généralement
Vérifiez d'abord le nom d'utilisateur. Ensuite, forcez la clé que vous attendez avec ssh -o IdentitiesOnly=yes -i .... Si le client propose la bonne clé et que le serveur la rejette, inspectez authorized_keys, la propriété et les permissions sur le serveur. Si la clé n'est jamais proposée, corrigez votre ~/.ssh/config local, votre agent ou le chemin de la clé. Si la connexion n'atteint jamais l'authentification, passez au dépannage réseau au lieu de modifier les fichiers de clé.