Ce que vous voyez
user@server's password:
Permission denied, please try again.
user@server's password:
Permission denied, please try again.
user@server's password:
user@server: Permission denied (publickey,password).SSH demande trois fois par défaut, puis affiche la dernière ligne. La liste entre parenthèses est ce que le serveur accepte encore. Si elle n'inclut pas password, ou si vous n'avez jamais eu d'invite de mot de passe, vous avez un autre problème : voir Permission denied (publickey).
Tester seul la connexion par mot de passe
Cela écarte les clés et les agents, et ne demande qu'une fois :
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password -o NumberOfPasswordPrompts=1 user@serverCause 1 : le mauvais nom d'utilisateur
Sans user@, SSH envoie votre nom d'utilisateur local, ou celui de votre configuration :
ssh -G server | grep '^user 'Un utilisateur inexistant reçoit la même invite de mot de passe et le même refus : cela ressemble donc exactement à un mauvais mot de passe. Les images cloud utilisent souvent ubuntu, debian ou ec2-user plutôt que root.
Pour fixer l'utilisateur d'un hôte une fois pour toutes, ajoutez une ligne User dans son bloc du fichier de configuration ssh.
Cause 2 : le mauvais mot de passe
Vérifiez les évidences : disposition du clavier, verrouillage des majuscules, et caractères cachés issus d'un copier-coller. SSH n'affiche rien pendant la saisie. L'invite compte aussi : Enter passphrase for key attend la phrase secrète de votre fichier de clé, tandis que user@server's password: attend le mot de passe du compte sur le serveur.
Lire le journal du serveur
Si vous pouvez atteindre le serveur autrement, par exemple par la console de l'hébergeur, cela tranche la question. Sous Debian et Ubuntu :
sudo journalctl -u ssh -n 30Sur les systèmes de type Red Hat, utilisez -u sshd. Les systèmes plus anciens journalisent dans /var/log/auth.log ou /var/log/secure.
| Ligne de journal | Signification |
|---|---|
Failed password for invalid user name | Cet utilisateur n'existe pas sur le serveur, ou est exclu par AllowUsers |
User name from ... not allowed because not listed in AllowUsers | L'utilisateur existe mais ne figure pas dans la liste |
Failed password for name | L'utilisateur existe et la vérification du mot de passe a échoué. C'est le mauvais mot de passe, ou l'une des causes 3 et 4 |
| Aucune ligne | Vous joignez un autre serveur ou un autre port. Vérifiez ssh -G server | grep -E '^(hostname|port) ' |
Cause 3 : root n'a pas le droit de se connecter avec un mot de passe
La valeur par défaut de PermitRootLogin est prohibit-password. Avec ce réglage, sshd affiche quand même l'invite et répond avec ce message même si le mot de passe de root est correct, et le journal indique Failed password for root. Le journal ne révèle donc pas la vraie raison. Interrogez directement sshd :
sudo sshd -T -C user=root,host=server,addr=203.0.113.10 | grep -i '^permitrootlogin'Un résultat prohibit-password ou son ancien nom without-password le confirme. Connectez-vous avec un utilisateur normal et utilisez sudo, ou utilisez une clé pour root. Voir Désactiver la connexion root.
Cause 4 : le compte est verrouillé
sudo passwd -S nameLe deuxième champ vaut L pour verrouillé, P pour un mot de passe utilisable et NP pour aucun mot de passe. Un compte verrouillé donne le même refus, et le journal dit encore seulement Failed password. Déverrouillez-le ou définissez un nouveau mot de passe :
sudo passwd -u name
sudo passwd nameUn compte expiré donne un autre texte, Your account has expired; please contact your system administrator. Vérifiez-le avec sudo chage -l name. Un shell nologin vous connecte puis affiche This account is currently not available.
Cause 5 : AllowUsers, DenyUsers et leurs versions pour les groupes
Ces règles refusent un utilisateur même avec le bon mot de passe. Regardez ce qui s'applique à cet utilisateur, y compris les blocs Match :
sudo sshd -T -C user=name,host=server,addr=203.0.113.10 | grep -iE '^(allowusers|denyusers|allowgroups|denygroups)'N'oubliez pas de vérifier les fichiers de /etc/ssh/sshd_config.d/. Après modification, lancez sudo sshd -t et rechargez le service.
Trop de tentatives
Des échecs répétés peuvent provoquer un nouveau symptôme : la connexion s'arrête avant l'invite de mot de passe. C'est une pénalité ou un bannissement. Voir kex_exchange_identification et fail2ban.
Questions
Pourquoi SSH affiche Permission denied alors que le mot de passe est bon ?
Souvent le nom d'utilisateur est faux, root n'a pas droit au mot de passe (PermitRootLogin prohibit-password), le compte est verrouillé ou AllowUsers exclut l'utilisateur. Le journal du serveur donne la vraie raison.
Combien d'essais de mot de passe SSH autorise-t-il ?
Le client demande trois fois par défaut (NumberOfPasswordPrompts). Le serveur accepte jusqu'à MaxAuthTries, 6 par défaut, toutes méthodes confondues.
Un mauvais nom d'utilisateur donne-t-il une autre erreur ?
Non. Un utilisateur inexistant reçoit la même demande de mot de passe et le même refus. Seul le journal du serveur indique invalid user.
Sources
- sshd_config(5), PermitRootLogin, AllowUsers
- ssh_config(5), NumberOfPasswordPrompts
- passwd(1), pages de manuel Linux