Tous les produits
Search
Centre de documentation

:Résoudre l'erreur « Permission denied, please try again » lors des connexions SSH à une instance Linux

Dernière mise à jour :Aug 18, 2026

Description du problème

Lorsque vous vous connectez à une instance Linux via SSH, la connexion échoue avec le message Permission denied, please try again, même si le nom d'utilisateur et le mot de passe sont corrects.

Diagnostic du problème

  1. Connectez-vous à une instance ECS à l'aide d'une connexion VNC.

    1. Accédez à ECS console - Instances. Dans le coin supérieur gauche, sélectionnez la région et le groupe de ressources de l'instance cible.

    2. Accédez à la page de détails de l'instance cible. Cliquez sur Connect et sélectionnez VNC. Saisissez vos identifiants pour vous connecter à l'instance ECS.

  2. Vérifiez la configuration du service SSH.

    Si le paramètre PermitRootLogin ou PasswordAuthentication est défini sur no dans la configuration, reportez-vous à la section Cas d'utilisation 1 : La configuration SSH refuse la connexion pour résoudre le problème.

    • PermitRootLogin : si ce paramètre est défini sur no, il empêche l'utilisateur root de se connecter via SSH.

    • PasswordAuthentication : si ce paramètre est défini sur no, il empêche tous les utilisateurs de se connecter avec une authentification par mot de passe.

    sudo cat /etc/ssh/sshd_config
  3. Vérifiez les journaux de sécurité du système.

    Lorsqu'une politique SELinux bloque une tentative de connexion, elle enregistre un message d'erreur dans le journal de sécurité du système.

    Une politique SELinux est un ensemble de règles de contrôle d'accès obligatoire qui définit les opérations que chaque processus peut effectuer sur des fichiers, des ports ou d'autres ressources.
    # For CentOS/RHEL systems
    sudo grep -iE --color=auto 'Could not get shadow information' /var/log/secure
    
    # For Debian/Ubuntu systems
    sudo grep -iE --color=auto 'Could not get shadow information' /var/log/auth.log

    Si la commande ne renvoie aucune sortie, une politique SELinux en est probablement la cause. Reportez-vous à la section Cas d'utilisation 2 : Une politique SELinux bloque la connexion.

Résolution

Cas d'utilisation 1 : La configuration SSH refuse la connexion

  1. Modifiez la configuration

    sudo vi /etc/ssh/sshd_config

    Ajustez les paramètres selon vos besoins :

    • Autoriser l'authentification par mot de passe : remplacez PasswordAuthentication no par PasswordAuthentication yes.

    • Autoriser la connexion de l'utilisateur root :

      • Autoriser l'authentification par clé (recommandé) : pour utiliser une paire de clés pour la connexion root, définissez PermitRootLogin sur prohibit-password.

      • Autoriser l'authentification par mot de passe : remplacez PermitRootLogin no par PermitRootLogin yes.

        Important

        L'autorisation de la connexion root avec un mot de passe (PermitRootLogin yes) accroît l'exposition de l'instance aux attaques par force brute. Nous vous recommandons d'utiliser l'authentification par clé ou de restreindre l'accès par adresse IP source à la place.

    Après avoir modifié le fichier, appuyez sur Esc, saisissez :wq et appuyez sur Enter pour enregistrer le fichier et quitter.

  2. Vérifiez la configuration et redémarrez le service

    1. Vérifiez la syntaxe du fichier de configuration. L'absence de sortie indique que la syntaxe est correcte.

      sudo sshd -t
    2. Redémarrez le service SSH pour appliquer les modifications.

      sudo systemctl restart sshd
  3. Vérifiez la connexion

    Reconnectez-vous à l'instance via SSH pour vérifier que le problème est résolu.

Cas d'utilisation 2 : Une politique SELinux bloque la connexion

  1. Vérifiez l'état actuel de SELinux

    Vérifiez si SELinux est en mode enforcing.

    sudo sestatus

    Si la sortie affiche SELinux status comme enabled et Current mode comme enforcing, la politique SELinux est active.

  2. Modifiez temporairement le mode SELinux pour rétablir l'accès

    Basculez temporairement SELinux en mode Permissive. Dans ce mode, SELinux enregistre des avertissements mais ne bloque pas les opérations.

    sudo setenforce 0
    Important

    Cette modification est temporaire et sera réinitialisée au redémarrage de l'instance.

    Après avoir exécuté la commande, essayez de vous reconnecter via SSH. Une connexion réussie confirme que SELinux était à l'origine du problème.

  3. Modifiez de manière permanente la configuration SELinux (facultatif)

    1. Modifiez le fichier de configuration. Remplacez le mode par défaut de SELinux de enforcing à permissive.

      sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
    2. Redémarrez l'instance pour appliquer la modification.

  4. Vérifiez la connexion

    Reconnectez-vous à l'instance via SSH pour vérifier la connexion.