2010-09-12 17:14:13 +0000 2010-09-12 17:14:13 +0000
264
264

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

J'ai un compte hostgator avec accès ssh activé. Lorsque j'essaie de télécharger le fichier de clé .pub 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 reçois sans cesse :

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 (ça fait plus de 12 heures qu'il attend, le support technique “suppose” qu'il se réinitialise après 30 min à 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. Je l'ai même fait installer sur un serveur personnalisé Slicehost et j'ai eu moins de problèmes qu'avec ces types.

Des conseils ? Peut-être que c'est quelque chose de côté client et non côté serveur.

Réponses (14)

423
423
423
2010-09-12 17:53:29 +0000

Ceci est généralement causé par l'offre par inadvertance de plusieurs clés ssh au serveur. Le serveur rejettera toute clé après qu'un trop grand nombre de clés ait été proposé.

Vous pouvez le constater par vous-même en ajoutant le drapeau -v à votre commande ssh pour obtenir une sortie verbeuse. Vous verrez qu'un paquet de clés est proposé, 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 _"Connection reset by peer”.

Pour empêcher que des clés non pertinentes soient proposées, vous devez le spécifier explicitement dans chaque entrée hôte du fichier ~/.ssh/config (sur la machine cliente) en ajoutant IdentitiesOnly comme suit :

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 aucune configuration des hôtes ssh, vous devez spécifier explicitement la clé correcte dans la commande ssh comme suit :

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

Note : le paramètre ‘IdentitiesOnly yes’ doit être entre guillemets.

ou

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/
195
195
195
2012-03-25 00:14:49 +0000

J'ai trouvé un moyen plus facile de le faire (si l'on utilise l'authentification par mot de passe) :

ssh -o PubkeyAuthentication=no username@hostname.com

Cela oblige à une authentification sans clé. J'ai pu me connecter immédiatement. Référence

27
27
27
2011-06-09 04:56:25 +0000

Je recevais aussi cette erreur et j'ai trouvé qu'elle se produisait b/c le serveur était configuré pour accepter jusqu'à 6 essais :

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

En plus de configurer le IdentitiesOnly yes dans votre fichier ~/.ssh/config vous avez deux autres options.

  1. Augmenter le MaxAuthTries (sur le serveur ssh)
  2. supprimer certaines des paires de clés que vous avez présentes dans votre répertoire ~/.ssh/ & lancer ssh-add -D
  3. lier explicitement une clé à un hôte donné dans votre fichier ~/.ssh/config Comme ceci :
host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. n'est probablement pas une bonne façon de procéder, étant donné que cela affaiblit un peu votre serveur ssh puisqu'il accepte maintenant plus de clés dans une tentative de connexion donnée. Pensez aux vecteurs d'attaque par force brute ici.

  2. C'est une bonne façon de procéder en supposant que vous avez des clés qui ne sont pas nécessaires et qui peuvent être supprimées définitivement.

  3. Et l'approche consistant à paramétrer les Identités seules sont probablement les moyens préférés pour traiter cette question !

7
7
7
2014-07-23 17:29:54 +0000

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 le spécifier avec l'option -i

6
6
6
2013-09-20 21:44:02 +0000

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 à 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. Cependant, sshd interrompt la connexion après cinq mauvaises tentatives de connexion (là encore, 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” en ligne de commande en utilisant l'argument optionnel “-o”.

Par exemple :

$ ssh -o PubkeyAuthentication=no root@host
6
6
6
2015-06-19 14:22:41 +0000

Si vous avez un mot de passe, et que vous voulez simplement l'utiliser pour vous connecter, voici comment procéder.

Pour utiliser UNIQUEMENT l'authentification par mot de passe et NE PAS utiliser la clé publique, et NE PAS utiliser le “keyboard-interactive” (qui est un sur-ensemble comprenant un mot de passe), vous pouvez le faire à partir de la ligne de commande :

ssh -o PreferredAuthentications=password user@example.com
3
3
3
2014-01-25 05:48:51 +0000

En allant sur @David, ajoutez simplement ce IdentitiesOnly yes à votre .ssh/config, cela fait la même chose que ssh -o PubkeyAuthentication=no.

Après vous être connecté, supprimez .ssh/authorized_keys. Maintenant, retournez à la machine locale et tapez le

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys' suivant. Cela devrait réactiver votre ssh avec la clé publique

2
2
2
2014-06-13 17:37:06 +0000

Je sais que c'est une vieille discussion, mais je voulais juste ajouter que j'ai rencontré le même message d'erreur, mais qu'il était causé par le propriétaire du dossier .ssh qui est root plutôt que par l'utilisateur qui utilise la clé. J'ai corrigé le problème en exécutant les commandes suivantes :

sudo chown -R user:user /home/user/.ssh

Je me suis également assuré que les permissions étaient correctes sur le dossier .ssh :

sudo chmod 700 /home/user/.ssh

Les fichiers dans le répertoire .ssh devraient avoir la permission de 600 :

sudo chmod 600 /home/user/.ssh/authorized_keys
1
1
1
2016-02-20 22:57:15 +0000

Dans mon cas, le problème était les autorisations de répertoire. Cela m'a permis de le résoudre :

$ chmod 750 ~;chmod 700 ~/.ssh
0
0
0
2019-11-24 01:41:40 +0000

C'était un moment de plaisir pour moi. Il s'est avéré que j'ai changé mon mot de passe localement alors que j'étais dans un mode de localisation différent de celui d'un clavier que j'utilisais pour me connecter à distance. Cela a effectivement rendu mon mot de passe différent de ce que je pensais qu'il était, probablement parce qu'un de mes caractères spéciaux était différent de ce que le clavier disait qu'il était.

0
0
0
2018-04-12 13:28:15 +0000

Trop d'échecs d'authentification

Ce message est causé par un trop grand nombre d'échecs de tentatives d'authentification compte tenu des limites autorisées appliquées sur le serveur SSH distant. Cela signifie potentiellement que vous avez ajouté trop d'identités dans l'agent SSH.

Voici quelques suggestions :

  • Ajoutez -v pour voir si c'est le cas (vous avez utilisé trop d'identités).
  • Listez les identités ajoutées par ssh-add -l.
  • Supprimez l'identité défaillante de l'agent par : ssh-add -d.
  • Vous pouvez également supprimer toutes les identités par ssh-add -D et n'en ajouter qu'une seule qui soit pertinente.
  • Si vous avez accès au serveur SSH, cochez l'option MaxAuthTries (voir : man sshd_config ).

  • Si rien de tout cela ne vous aide, assurez-vous que vous utilisez les bons identifiants ou le bon fichier.

0
0
0
2017-05-05 07:57:18 +0000

J'avais ma clé publique dans .ssh/authorized_keys2, mais le serveur était configuré pour lire seulement .ssh/authorized_keys :

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

Après avoir déplacé mon fichier vers .ssh/authorized_keys, je peux me connecter avec succès avec ma clé.

0
0
0
2014-11-19 08:10:08 +0000

Dans mon cas, cela se produisait parce que j'utilisais le nom d'utilisateur “ubuntu”, mais le nom d'utilisateur dans ce cas était “ec2-user”

Après avoir fait ce que “John T” a suggéré, j'ai obtenu cette erreur :

Permission refusée (publickey).

Ensuite, j'ai trouvé la solution (c'est-à-dire changer le nom d'utilisateur en “ec2-user”) dans cette réponse : https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

-1
-1
-1
2016-09-26 15:23:15 +0000

Ce message peut apparaître lorsque le nom d'utilisateur et le mot de passe corrects ne sont pas saisis.

Vérifiez d'abord que l'utilisateur est bien répertorié :

vim /etc/passwd