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

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/

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

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 !

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

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

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

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

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

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

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.

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.

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

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

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