Trop d'échecs d'authentification pour nom d'utilisateur.

Question

Trop d'échecs d'authentification pour nom d'utilisateur.

Demandé el 12 de Septembre, 2010: Quand la question a-t-elle été
359776 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

J'ai un compte hostgator avec un accès ssh activé. Lorsque j'essaie de télécharger le fichier .pub key généré avec cette commande :

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

Je n'arrête pas de recevoir :

Received disconnect from 111.222.33.44: 2: Too many authentication failures for username
rsync: connection unexpectedly closed (0 bytes received so far) \[sender\]
rsync error: unexplained error (code 255) at io.c(601) \[sender=3.0.7\]

J'ai déjà joué avec ssh jusqu'à ce que j'obtienne l'échec de l'authentification. Mais maintenant il semble que le compteur d'échec d'authentification ne se réinitialise pas (j'attends depuis plus de 12 heures maintenant, le support technique "suppose" qu'il se réinitialise après 30 minutes à 1 heure, et un autre gars m'a dit "il se réinitialise chaque fois que vous essayez de vous connecter avec le nom d'utilisateur", jeesh).

Ça me rend dingue. J'ai même eu cette configuration dans un serveur personnalisé Slicehost et j'ai eu moins de problèmes qu'avec ces gars-là.

Des conseils ? Peut-être s'agit-il d'un problème côté client et non côté serveur.

Demandé el 12 de Septembre, 2010 par Gabriel

0 votes

Dans mon cas, il y avait une erreur dans la génération de la clé. J'ai généré une clé et j'ai oublié de mentionner l'adresse de la source et le nom d'utilisateur utilisé à la fin de la clé.

Commenté el 29 de Août, 2019 par Reporter

Answer 1

5 Réponses

Answer 2

459voto

Dalroth Points 2468

C'est généralement causé par l'offre par inadvertance de plusieurs clés ssh au serveur. Le serveur rejettera toute clé après que trop de clés aient été proposées.

Vous pouvez le constater par vous-même en ajoutant l'élément -v à votre ssh pour obtenir une sortie verbeuse. Vous verrez qu'un tas de clés sont proposées, jusqu'à ce que le serveur rejette la connexion en disant : "Trop d'échecs d'authentification pour [utilisateur]" . Sans mode verbeux, vous ne verrez que le message ambigu "Connexion réinitialisée par l'homologue" .

Pour éviter que des clés non pertinentes ne soient proposées, vous devez le spécifier explicitement dans chaque entrée d'hôte dans la section ~/.ssh/config (sur la machine cliente) en ajoutant IdentitiesOnly comme ça :

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

Si vous utilisez le ssh-agent, il est utile d'exécuter ssh-add -D pour effacer les identités.

Si vous n'utilisez pas de configuration d'hôtes ssh, vous devez spécifier explicitement la bonne clé dans le champ ssh comme suit :

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Note : le paramètre 'IdentitiesOnly yes' devait être entre guillemets.

o

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

Répondu el 12 de Septembre, 2010 par Dalroth (2468 Points )

5 votes

Je ne vois pas très bien où placer cette ligne. Sur le serveur auquel j'essaie de me connecter, le fichier .ssh/config ne contient que des informations relatives aux autres serveurs. Voulez-vous dire que cette ligne doit être placée dans le fichier .ssh/config de l'ordinateur à partir duquel j'essaie de me connecter ? Si c'est le cas, ce n'est pas clair car votre réponse dit "une fois que vous vous êtes reconnecté...".

Commenté el 7 de Juin, 2012 par David LeBauer

2 votes

Je dois mettre l'option entre guillemets, comme ceci : ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/

Commenté el 23 de Avril, 2013 par Mithaldu

1 votes

Utilisateurs de Windows utilisant PAGENT (Putty Agent), vérifiez que vous n'avez chargé que les clés dont vous avez besoin. J'ai rencontré ce problème après avoir accidentellement chargé TOUTES mes clés privées.

Commenté el 19 de Novembre, 2013 par Chris Rasco

Afficher 11 autres commentaires

Answer 3

218voto

Ben West Points 2486

J'ai trouvé un moyen plus simple de le faire (si vous utilisez l'authentification par mot de passe) :

ssh -o PubkeyAuthentication=no username@hostname.com

Cela force l'authentification sans clé. J'ai pu me connecter immédiatement.

Référence

Répondu el 25 de Mars, 2012 par Ben West (2486 Points )

3 votes

+1, j'aimerais pouvoir vous donner plus. Raspberry Pi est le seul appareil auquel je me connecte sans clé publique. J'obtenais : "Trop d'échecs d'authentification pour Pi"

Commenté el 22 de Décembre, 2013 par asteri

1 votes

Et pour utiliser cela avec rsync : rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file'

Commenté el 9 de Mars, 2016 par Ciro Santilli Путлер Капут 六四事

2 votes

Vous pouvez également créer un alias pour rendre l'authentification par mot de passe encore plus rapide. alias sshp='ssh -o PubkeyAuthentication=no '

Commenté el 27 de Avril, 2017 par dhempler

Answer 4

31voto

Batur Points 11

Je recevais aussi cette erreur et j'ai découvert que cela se produisait parce que le serveur était configuré pour accepter jusqu'à 6 essais :

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

En plus de fixer le IdentitiesOnly yes dans votre ~/.ssh/config vous avez quelques autres options.

Augmenter le MaxAuthTries (sur le serveur ssh)
supprimer certaines des paires de clés que vous avez présentes dans votre ~/.ssh/ répertoire et exécution ssh-add -D
lier explicitement une clef à un hôte donné dans votre ~/.ssh/config fichier

Comme ça :

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo

Ce n'est probablement pas une bonne façon de procéder, étant donné que cela affaiblit un peu votre serveur ssh puisqu'il acceptera désormais plus de clés lors d'une tentative de connexion donnée. Pensez aux vecteurs d'attaque par force brute ici.
C'est une bonne solution si vous avez des clés qui ne sont pas nécessaires et qui peuvent être supprimées définitivement.
Et l'approche consistant à définir IdentitiesOnly est probablement la meilleure façon de traiter ce problème !

Répondu el 9 de Juin, 2011 par Batur (11 Points )

0 votes

Dans votre dernière ligne vous avez identifyfile /home/YOU/.ssh/foo mais ce devrait être identityfile (un t pas un f)

Commenté el 26 de Septembre, 2014 par tbarbe

2 votes

Dans mon cas, il suffit de lancer ssh-add -D sur ma machine a fonctionné. Merci !

Commenté el 20 de Août, 2020 par Pranit More

Answer 5

9voto

Tommy Points 301

J'ai ajouté à ~/.ssh/config ceci :

Host *
IdentitiesOnly yes

Il active l'option IdentitiesOnly=yes par défaut. Si vous avez besoin de vous connecter avec une clé privée, vous devez la spécifier avec l'option -i.

Répondu el 23 de Juillet, 2014 par Tommy (301 Points )

Answer 6

6voto

Will Verna Points 61

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 répertoire .ssh et si l'option '-i' 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 demandera ensuite une authentification par mot de passe. Toutefois, sshd interrompt la connexion après cinq tentatives de connexion infructueuses (la valeur par défaut peut varier).

Si vous avez un certain nombre de clés privées dans votre répertoire .ssh, vous pouvez désactiver "Public Key Authentication" à la ligne de commande en utilisant l'argument optionnel '-o'.

Par exemple :

$ ssh -o PubkeyAuthentication=no root@host

Répondu el 20 de Septembre, 2013 par Will Verna (61 Points )

0 votes

C'était exactement ce qui m'arrivait ! Merci beaucoup pour l'explication ;)

Commenté el 4 de Octobre, 2016 par El Ninja Trepador

Trop d'échecs d'authentification pour nom d'utilisateur.

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

Trop d'échecs d'authentification pour *nom d'utilisateur*.

Réponses

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by:

Trop d'échecs d'authentification pour nom d'utilisateur.