Comment récupérer à partir de "Trop d'échecs d'authentification pour l'utilisateur root"
J'ai fait plusieurs tentatives pour établir une connexion SSH pour l'utilisateur root @ Host à l'aide du terminal PuTTY. Ce faisant, j'ai spécifié plusieurs fois des informations d'identification erronées, puis je les ai correctement spécifiées, puis après l'acceptation des informations d'identification, la session ssh rompt avec
"Connexion réseau inopinément fermée du serveur".
Cette erreur est signalée par le terminal PuTTY. Lorsque vous essayez de ssh root @ localhost à partir de la console locale - cela fonctionne très bien. Cela fonctionne également très bien lorsque je ssh otheruser @ Host d'un autre hôte. Les problèmes de connectivité réseau ne sont donc pas coupables. La seule erreur à laquelle je pense est: "Trop d'échecs d'authentification pour l'utilisateur root" bien que PuTTY ait signalé une erreur différente.
La question est: comment récupérer de cette condition d'erreur et laisser PuTTY se connecter à nouveau? Le redémarrage de sshd ne semble pas aider
Êtes-vous sûr que la connexion root à ssh est autorisée?
Vérifiez sshd_config et vérifiez que la connexion root est autorisée. sshd devra être redémarré si le paramètre change.
"Trop d'échecs d'authentification pour l'utilisateur root" signifie que votre serveur SSH la limite MaxAuthTries a été dépassée. Cela se produit afin que votre client essaie de s'authentifier avec toutes les clés possibles stockées dans /home/USER/.ssh/.
Cette situation peut être résolue de ces manières:
- ssh - i/chemin/vers/id_rsa root @ Host
- Spécifiez Host/IdentityFile paire / home/USER/.ssh/config.
Host hostIdentityFile /home/USER/.ssh/id_rsaHost host2IdentityFile /home/USER/.ssh/id_rsa2
- Augmentez MaxAuthTries valeur sur le serveur SSH dans / etc/ssh/sshd_config (non recommandé).
Si vous obtenez l'erreur SSH suivante:
$ Received disconnect from Host: 2: Too many authentication failures for root
Cela peut se produire si vous avez (par défaut sur mon système) cinq fichiers d'identité DSA/RSA ou plus stockés dans votre .ssh répertoire. Dans ce cas, si le -i L'option n'est pas spécifiée sur la ligne de commande, le client ssh tentera d'abord de se connecter en utilisant chaque identité (clé privée) et la prochaine invite pour l'authentification par mot de passe. Cependant, sshd abandonne la connexion après cinq tentatives de connexion incorrectes (là encore, la valeur par défaut peut varier).
Donc, si vous avez un certain nombre de clés privées dans votre répertoire .ssh, vous pouvez désactiver Public Key Authentication sur la ligne de commande en utilisant le -o argument facultatif.
Par exemple:
$ ssh -o PubkeyAuthentication=no root@Host
Sur la machine distante, ouvrez/etc/sshd_config et modifiez la valeur
MaxAuthTries 30
Il s'agit d'un problème typique lorsque vous avez installé plusieurs clés ou ouvert plusieurs connexions. Le serveur vérifiant étape par étape chaque clé et si MaxAuthTries est configuré sur 3, puis après les 3 premiers essais vous déconnectera. Sécurité ssh typique.
Je vous suggère d'utiliser le mode verbeux lors de la connexion à la machine distante pour analyser le problème.
ssh -v -p numéro_port utilisateur @ nomserveur
Deviner comme le font la plupart des gens sur ce forum est MAUVAIS et sa perte de temps. Essayez d'abord d'analyser le problème, de recueillir des informations, puis de demander.
S'amuser.
Pour moi, ce problème a été résolu en créant le ssh_config ci-dessous pour l'hôte auquel je me connectais.
(~/.ssh/config)
Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes
Le problème est survenu car j'ai trop de clés ssh dans mon ~/.ssh dossier, comme 16 environ. Et sans ces deux directives IdentityFile ET IdentitiesOnly dans la configuration, ma machine essayait apparemment toutes les clés de ~/.ssh et atteindre le nombre maximal de tentatives avant de tenter le fichier d'identité correct.
C'est une mauvaise pratique. Il suffit d'avoir un utilisateur régulier sur la boîte distante et de se connecter via ssh en l'utilisant, puis d'accéder à la racine en utilisant su/Sudo.
J'ai également fait face au même problème. Cela peut facilement se produire si vous utilisez Pageant et qu'un grand nombre de clés y est chargé , car ces serveurs comptent chaque offre d'une clé publique comme une tentative d'authentification.
(Ce conseil est tiré de ici .)
Je vous recommande, comme Anon l'a indiqué ci-dessus, d'utiliser un autre utilisateur pour obtenir un accès ssh puis d'utiliser la commande su pour obtenir un accès root.
Assurez-vous également d'activer PermitRootLogin dans le /etc/ssh/sshd_config fichier sur le serveur.
J'ai résolu ce problème dans mes systèmes en exécutant les commandes suivantes:
eval $(ssh-agent)
ssh-add ~/.ssh/keyname
Ensuite, essayez ssh dans la machine distante
Pour résoudre temporairement ce problème jusqu'à ce que les choses puissent être résolues comme indiqué ailleurs, vous pouvez réinitialiser le décompte PAM d'un utilisateur afin qu'il puisse réessayer:
pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>
J'ai été mordu par un problème similaire. Cependant, la vraie cause était que j'avais ForwardAgent yes dans le fichier de configuration d'une machine le long du tuyau. Je me connectais de la machine A à la machine B à la machine C.
Le message d'erreur a été affiché dans la tentative ssh de B -> C, mais il a été provoqué par A ayant la transmission active. Donc C a d'abord reçu toutes les clés de A, puis seulement celles de B.
Il est soudainement apparu lorsque j'ai ajouté une clé de plus à A.
J'ai résolu ce problème sur mon Mac en:
- définir le mot de passe root avec "Sudo passwd root" puis
- éditer et enregistrer le fichier de configuration ssh avec "nano/etc/ssh_config" et
- changer la RSAAuthentication en "non" plutôt qu'en oui.
D'autres réponses vous indiquent la meilleure façon de vous connecter en tant que root, et les implications en termes de sécurité, mais votre question explicite était
comment récupérer de cette condition d'erreur et laisser PuTTY se reconnecter?
Vous mentionnez la dernière fois que vous vous êtes connecté, le serveur distant a interrompu la connexion.
Ce que je pense que vous pourriez trouver, c'est que le serveur distant exécute fail2ban (*) et qu'il a "emprisonné" votre IP après votre connexion réussie. Vous pouvez tester cela en essayant de vous reconnecter, et vous ne recevrez même pas l'invite de connexion.
Il y a deux solutions, vous pouvez soit attendre le temps de prison, à quel point les choses retournent simplement à la normale, mais le temps de prison peut être n'importe quoi. Ou vous pouvez trouver un ordinateur différent à partir duquel vous connecter, le faire et "libérer" votre adresse IP, dans ce cas, "différent" est du point de vue du serveur distant, donc un autre ordinateur derrière le même pare-feu ne fonctionnera probablement pas non plus .
(*) fail2ban est un démon super pratique qui peut vérifier périodiquement divers fichiers journaux et ajuster les règles de pare-feu pour faire "disparaître" le serveur lorsqu'il détecte un comportement potentiellement malveillant d'un client. Sur debian, il sort de la boîte configuré pour détecter plusieurs connexions ssh ayant échoué à partir d'une IP particulière, et après 3 (je pense), il supprimera tous les paquets de cette IP. Fonctionne avec brio pour arrêter ces attaques par force brute scriptées.
J'ai résolu ce problème en deux étapes simples sur mon serveur Ubuntu 16.04 -
Arrêtez d'abord mon serveur vnc ou tuez le processus -
vncserver -kill :1
puis recommencez -
vncserver
Après cela, connectez-le à partir du client Bureau à distance -
999.99.99.99:5901
Terminé !!
OK, donc dans mon cas, c'était assez bizarre, ça y est ...
J'ai un vagabond standard VM avec une clé SSH et je peux SSH dedans en utilisant PuTTY. Tout en essayant d'y accéder pendant le déploiement dans PHPStorm, j'obtiens too many authentication failures Erreur. J'ai donc augmenté le MaxAuthTries dans mon sshd_config puis j'ai été frappé avec Auth failed erreur puis Auth cancel.
Maintenant, je ne sais pas exactement pourquoi j'ai même essayé, mais ... J'ai ajouté le point à la fin de mon chemin de clé SSH dans la fenêtre de déploiement dans PHPStorm. C'était donc comme ça:
C:\Users\Deadpool\\.ssh\chimichanga
et maintenant c'est comme ça:
C:\Users\Deadpool\\.ssh\chimichanga.
Et ça marche ... Dans mon dossier ".ssh" j'ai plus de fichiers:
chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub
Je ne sais pas ce que fait ce point fcuking mais en utilisant le .ppk le fichier ne fonctionne pas, donc je suppose que c'est une sorte de magie;) Oh, et je pourrais me débarrasser des MaxAuthTries après ce "dot trick".
Comme @sufferer l'a mentionné dans une autre réponse, certaines distributions Linux incluent des moniteurs pour se protéger des attaques par force brute sur des services visibles externes comme SSH, par exemple DenyHosts ou fail2ban. Ces moniteurs vérifient les fichiers journaux à la recherche d'échecs et ajoutent des filtres pour bloquer les adresses IP qui ont trop d'échecs (le nombre est configurable et indépendant de la configuration sshd).
Si votre distribution comprend fail2ban, qui protège les services en ajoutant des règles au pare-feu iptables, vous pouvez vérifier quels services ou "prisons" sont supervisés à l'aide de la commande:
Sudo fail2ban-client status
La prison pour le service SSH est sshd, donc pour vérifier s'il y a des IP interdites, vous pouvez utiliser:
Sudo fail2ban-client status sshd
et pour démanteler certaines adresses IP a.b.c.d:
Sudo fail2ban-client set sshd unbanip a.b.c.d
Si vous avez DenyHosts, la liste interdite se trouve dans le fichier /etc/hosts.deny; vous pouvez modifier ce fichier directement en tant que root. Pour accorder à certains IP un accès permanent a.b.c.d, vous pouvez ajouter la ligne sshd:a.b.c.d dans le fichier /etc/hosts.allow.
Comme toujours, la commande man est votre amie:
man fail2ban
man hosts.deny
Il devrait exister d'autres utilitaires similaires, mais je ne les ai utilisés que.
Notez que l'augmentation du nombre de nouvelles tentatives autorisées dans la configuration sshd ne libère pas les adresses IP interdites, mais autorise uniquement plus d'échecs dans la même connexion. Si le nombre autorisé est dépassé, l'utilisateur/attaquant se reconnecte simplement pour essayer n fois plus.
D'autres services ont intégré la liste des interdictions (comme le montre la réponse de Rajnesh Thakur au sujet du redémarrage du serveur VNC).