Comment récupérer de «trop d'échecs d'authentification pour l'utilisateur root»


64

J'ai déjà tenté à plusieurs reprises d'établir une connexion SSH pour l'utilisateur root @ host à l'aide d'un terminal Putty. Ce faisant, j’ai spécifié plusieurs informations d’identité erronées à plusieurs reprises, après quoi je les ai correctement spécifiées, puis, après acceptation des informations d’identification, les pauses de session ssh avec

"Connexion réseau fermée de manière inattendue par le serveur".

Cette erreur est signalée par le terminal à mastic. Lorsque vous essayez de ssh root @ localhost à partir de la console locale, cela fonctionne correctement. Cela fonctionne aussi très bien quand 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 qui se pose est la suivante: comment remédier à cette erreur et laisser le mastic se connecter à nouveau? Redémarrer sshd semble ne pas aider



1
Assurez-vous de désactiver votre agent ssh (par exemple pageant sur Windows) si vous recevez une Too many Authentication Failureserreur avant de pouvoir vous connecter.
Mahn

Réponses:


8

Ê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.


121

"Trop d'échecs d'authentification pour l'utilisateur root" signifie que la limite MaxAuthTries de votre serveur SSH a été dépassée . Il arrive que votre client tente de s’authentifier avec toutes les clés possibles stockées dans /home/USER/.ssh/.

Cette situation peut être résolue par les moyens suivants:

  1. ssh -i / chemin / vers / id_rsa racine @ hôte
  2. Spécifiez la paire hôte / fichier d' identité dans /home/USER/.ssh/config .
    • Host host
    • IdentityFile /home/USER/.ssh/id_rsa
    • Host host2
    • IdentityFile /home/USER/.ssh/id_rsa2
  3. Augmentez la valeur MaxAuthTries sur le serveur SSH dans / etc / ssh / sshd_config (non recommandé).

9
Cela devrait vraiment être la réponse acceptée!
Benjamin

4
Pour être une réponse acceptée, la réponse devrait en réalité concerner le logiciel mentionné dans la question. =)
rakslice le

4
Une autre cause de dépassement de la limite pourrait être votre agent ssh. ssh -vvmontrait plusieurs versions de deux clés (fournies par ssh-agent) en cours d’essai. Je suppose que cela est dû à mon redémarrage peu fréquent et au remplacement de certaines clés ayant expiré; Apparemment, ssh-agent ne remplace pas les anciennes clés par de nouvelles. J'ai tué ssh-agent et le problème a disparu.
Marc

Quel inconvénient y aurait-il d’augmenter MaxAuthTries? Je doute que de nombreuses attaques soient effectuées en essayant beaucoup de clés différentes. De plus, si un attaquant veut le faire, il peut simplement fermer la connexion et en ouvrir une nouvelle à chaque fois qu'il atteint la limite. Ils ne vont pas réussir à forcer une clé de toute façon.
kasperd

@ Mark Merci! Le redémarrage de ssh-agent a corrigé le problème pour moi!
Winduptoy

92

Si vous obtenez l'erreur SSH suivante:

$ Received disconnect from host: 2: Too many authentication failures for root

Cela peut se produire si (par défaut, sur mon système) au moins cinq fichiers d'identité DSA / RSA sont stockés dans votre .sshrépertoire. Dans ce cas, si l' -ioption 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 d'authentification par mot de passe. Cependant, sshd interrompt la connexion après cinq tentatives de connexion infructueuses (à nouveau, la valeur par défaut peut varier).

Donc, si vous avez plusieurs clés privées dans votre répertoire .ssh, vous pouvez les désactiver Public Key Authenticationen ligne de commande en utilisant l’ -oargument optionnel.

Par exemple:

$ ssh -o PubkeyAuthentication=no root@host

1
Merci beaucoup! Utiliser Ubuntu Server ici auquel je ne peux accéder que par SSH. J'avais réglé "MaxAuthTries 1" après avoir suivi à l'aveuglette un tutoriel sur internet.
André Figueiredo

Tu viens de sauver ma vie! Ne pas utiliser d'authentification clé pour que les autres réponses ne nous aident pas. Cela l'a résolu tellement facilement !!
George Green

5
C'est la réponse
smac89

J'ai simplement copié à nouveau ma clé, en utilisant l'authentification par mot de passe, et maintenant cela fonctionne à chaque fois. J'ai beaucoup de clés dans mon .sshrépertoire, je ne pense pas que ce soit le montant qui compte.
Ken Sharp

C’est la réponse la plus pertinente et devrait être le comportement par défaut de ssh-copy-id. Par conséquent, si j’aime copier mon identifiant sur un serveur, il n’est généralement pas là. Mais si ssh tente d’abord de s’authentifier auprès du serveur à l’aide de la clé pubkey, le serveur interrompt la connexion avant de pouvoir entrer le mot de passe.
Sprinterfreak le

17

Sur la machine distante, ouvrez / etc / sshd_config et modifiez la valeur

MaxAuthTries 30

Ceci est un problème typique lorsque vous avez installé plusieurs clés ou ouvert plusieurs connexions. Le serveur vérifie pas à pas chaque clé et si MaxAuthTries est configuré sur 3, il vous déconnectera après les 3e premiers essais. Sécurité typique en ssh.

Je vous suggère d'utiliser le mode commenté lors de la connexion à une machine distante pour analyser le problème.

ssh -v -p numéro_port utilisateur @ nom_serveur

Deviner, comme le font la plupart des gens sur ce forum, est FAUX et sa perte de temps. Essayez d’abord d’analyser le problème, de collecter des informations puis de demander.

S'amuser.


Dans mon cas spécifique, le problème était que j'étais connecté avec le transfert d'agent, en essayant d'exécuter un script qui utilisait sa propre identité SSH. Lorsque je l'ai exécuté avec le transfert d'agent, il y avait trop d'identités avant d'essayer sa propre identité. J'ai donc configuré le script pour jeter l'environnement de l'agent, ce qui l'a clarifié. J'aurais aussi pu augmenter les MaxAuthTries, mais je n'en avais pas besoin dans ce cas.
Sean Reifschneider

1
Merci. -va montré mon client ssh essayant d'utiliser plusieurs clés (j'en ai plusieurs maintenant). Je les ai nettoyés de l'agent avecssh-add -D
joeytwiddle

12

C'est une mauvaise pratique. Il suffit d'avoir un utilisateur régulier sur le boîtier distant et de se connecter via ssh en l'utilisant, puis d'obtenir un accès root en utilisant su / sudo.


10

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 dû au fait que j'ai trop de clés SSH dans mon ~/.sshdossier, environ 16 ou plus. Et sans ces deux directives IdentityFileAND IdentitiesOnlydans la configuration, ma machine essayait apparemment toutes les clés ~/.sshet atteignait le nombre maximal d'essais avant d'essayer le fichier IdentityFile correct.


6

Comme Anon ci-dessus, nous vous recommandons d'utiliser un autre utilisateur pour obtenir un accès SSH, puis d'utiliser la sucommande pour obtenir un rootaccès.

Assurez-vous également d'activer PermitRootLoginle /etc/ssh/sshd_configfichier sur le serveur.


5

J'ai également fait face au même problème. Cela peut facilement arriver si vous utilisez Pageant et que vous y avez un grand nombre de clés , car ces serveurs considèrent chaque offre d'une clé publique comme une tentative d'authentification.

(Ce conseil est pris d' ici .)


1
Nous n’aimons pas beaucoup les réponses de lien seulement ici, car les liens pourrissent et la réponse devient inutile. Gardez le lien, bien sûr, mais si vous pouviez résumer la solution en un ou deux paragraphes, vous auriez peut-être une réponse positive ici.
MadHatter

2
J'espère que vous pardonnerez ma modification ultérieure; maintenant (j'espère), il est clair que le conseil que vous mentionnez est le conseil que vous donnez, tout en reconnaissant la source d'origine. +1 de moi pour avoir essayé d'améliorer votre réponse!
MadHatter

J'ai eu aussi un problème "Trop d'échecs d'authentification" dans Putty. Après avoir supprimé toutes les autres clés de PageAnt, je me suis finalement connecté avec succès.
Klor

4

J'ai résolu ce problème dans mes systèmes en exécutant les commandes suivantes:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Puis essayer ssh sur une machine distante


3

Pour résoudre temporairement ce problème jusqu'à ce que tout soit résolu comme indiqué ailleurs, vous pouvez réinitialiser le décompte PAM d'un utilisateur afin qu'il puisse à nouveau essayer:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

2

J'ai été piqué par un problème similaire. Cependant, la vraie cause était que j'avais ForwardAgent yesdans 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 apparaissait dans la tentative ssh de B -> C, mais il était causé par le fait que le transfert était actif. Donc C a été d'abord servi toutes les clés de A, et alors seulement celles de B.

Il est apparu soudainement lorsque j'ai ajouté une clé supplémentaire à A.


1

J'ai résolu ce problème sur mon Mac en:

  1. définir le mot de passe root avec "sudo passwd root" puis
  2. éditer et sauvegarder le fichier de configuration ssh avec "nano / etc / ssh_config" et
  3. changer l’authentification RSAA en "non" plutôt qu’en oui.

0

OK, donc dans mon cas, c'était assez bizarre, ça y est ...

J'ai une machine virtuelle vagabonde standard avec une clé SSH et je peux utiliser SSH à l'aide de Putty. En essayant de l'obtenir pendant le déploiement dans PHPStorm, j'obtiens une too many authentication failureserreur. Alors j'ai augmenté le MaxAuthTriesdans mon sshd_configet puis j'ai été frappé d' Auth failederreur et 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 de PHPStorm. Donc c'était 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 suis pas sûr de ce que fait ce point, mais utiliser le .ppkfichier ne fonctionne pas, alors je suppose que c'est un peu magique;) Oh, je pourrais me débarrasser des MaxAuthTries après ce "tour de passe".


0

D’autres réponses vous indiquent le meilleur moyen 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 le mastic se reconnecter?

Vous mentionnez lors de votre dernière connexion que le serveur distant a interrompu la connexion.

Ce que je pense que vous pourriez trouver, c'est que le serveur distant est en train d'exécuter fail2ban (*) et qu'il a "jeté" votre adresse 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 existe deux solutions: vous pouvez soit attendre la prison, soit revenir à la normale, mais la prison pourrait être n'importe quoi. Ou vous pouvez trouver un autre ordinateur pour vous connecter, faites-le et "libérez" votre adresse IP, dans ce cas, "différent" est du point de vue du serveur distant, de sorte qu'un autre ordinateur derrière le même pare-feu ne fonctionnera probablement pas non plus .

(*) fail2ban est un démon extrêmement pratique qui peut vérifier périodiquement divers fichiers journaux et ajuster les règles de pare-feu pour que le serveur "disparaisse" lorsqu'il détecte un comportement potentiellement malveillant d'un client. Sur debian, il est prêt à l'emploi et configuré pour détecter plusieurs connexions ssh échouées à partir d'une adresse IP donnée. Après 3 (je pense), tous les paquets de cette adresse IP seront supprimés. Fonctionne avec brio pour arrêter ces attaques par force brute scriptées.


0

Comme @sufferer mentionné dans une autre réponse, quelques distributions Linux incluent des moniteurs pour protéger contre les attaques par force brute sur les services externes visibles comme SSH, par exemple DenyHostsou fail2ban. Ces moniteurs vérifient les fichiers journaux à la recherche de tentatives infructueuses et ajoutent des filtres pour bloquer les adresses IP comportant trop d'échecs (ce nombre est configurable et indépendant de la configuration sshd).

Si votre distribution inclut fail2ban, qui protègent les services en ajoutant des règles au pare-feu iptables, vous pouvez vérifier quels services ou "jails" sont supervisés à l'aide de la commande:

sudo fail2ban-client status

La prison pour le service SSH est sshd. Pour vérifier s’il existe des adresses IP interdites, vous pouvez utiliser:

sudo fail2ban-client status sshd

et pour libérer une adresse IP abcd:

sudo fail2ban-client set sshd unbanip a.b.c.d

Si vous l’avez DenyHosts, la liste des bannis se trouve dans le fichier /etc/hosts.deny; vous pouvez éditer ce fichier directement en tant que root. Pour accorder un accès permanent à abcd IP, vous pouvez ajouter la ligne sshd:a.b.c.dau fichier /etc/hosts.allow.

Comme toujours, la mancommande 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 tentatives autorisées dans la configuration de sshd ne libère pas les adresses IP interdites, mais autorise davantage 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.

La liste des interdictions a été intégrée à d’autres services (comme le montre la réponse de Rajnesh Thakur sur le redémarrage du serveur VNC).


-2

J'ai résolu ce problème en deux étapes simples sur mon serveur Ubuntu 16.04 -

D'abord arrêtez mon serveur vnc ou tuez le processus -

vncserver -kill :1

et ensuite le redémarrer -

vncserver

Après cela, connectez-le à partir du client Remote Desktop -

192.0.2.99:5901

Terminé !!


Cela n'a rien à voir avec la question.
Ken Sharp

-3

veuillez suivre les étapes ci-dessous pour la résolution

  1. Sauvegarder / etc / ssh / sshd_config
  2. Augmenter la valeur de MaxAuthTries dans sshd_config
  3. stopsrc -s sshd; startsrc -s sshd

Et vérifiez à nouveau après les modifications ci-dessus


-4

J'ai eu le même problème où je continuais à avoir "SServer a envoyé un message de type 2 déconnecté (erreur de protocole): Trop d'échecs d'authentification pour l'utilisateur"

J'ai résolu ce problème en supprimant toutes mes clés SSH (.ppk), puis connecté au serveur intégré AD.


Cette réponse n'est pas utile, et recommander la suppression des fichiers .ppk est dangereux. S'il vous plaît, s'il vous plaît, si vous pensez que vous devez supprimer des fichiers .ppk (et que je ne vois pas pourquoi vous voudriez le faire), renommez-les d'une autre manière, ne les supprimez pas. Ils contiennent vos clés, dont vous avez probablement besoin.
Law29
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.