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

J'ai un compte hostgator avec l'accès ssh activé. Lorsque vous essayez 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 continue à recevoir:

Déconnexion reçue à partir de 111.222.33.44: 2: Trop d'échecs d'authentification pour le nom d'utilisateur
rsync: connexion fermée de manière inattendue (0 octet reçu à ce jour) [expéditeur]
Erreur rsync: erreur inexpliquée (code 255) à io.c (601) [expéditeur = 3.0.7]

J'ai déjà joué avec ssh jusqu'à l'échec de l'authentification. Mais maintenant, il semble que le compteur d'échecs d'authentification ne réinitialise pas (attend depuis plus de 12 heures maintenant, le support technique "suppose" qu'il réinitialise après 30 min à 1 heure, et un autre mec m'a dit "il 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 installation dans un serveur personnalisé Slicehost et eu moins de problèmes que ces gars-là.

Des conseils? C'est peut-être quelque chose côté client et pas côté serveur.

Cela est généralement dû à l’offre par inadvertance de plusieurs clés ssh au serveur. Le serveur rejettera toute clé si trop de clés ont été proposées.

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

Pour empêcher que des clés non pertinentes ne soient proposées, vous devez explicitement spécifier cela dans chaque entrée d'hôte du ~/.ssh/configfichier (sur la machine cliente) en ajoutant IdentitiesOnlycomme suit:

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

Si vous utilisez ssh-agent, il est utile d’exécuter ssh-add -Dpour effacer les identités.

Si vous n'utilisez aucune configuration d'hôtes ssh, vous devez spécifier explicitement la clé correcte dans la sshcommande, comme suit:

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

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

ou

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

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

Je recevais aussi cette erreur et j'ai constaté qu'il se produisait car le serveur était configuré pour accepter jusqu'à 6 tentatives:

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

En plus de définir le IdentitiesOnly yesdans votre ~/.ssh/configfichier, vous avez deux autres options.

1. Augmenter le MaxAuthTries(sur le serveur ssh)
2. supprimer certaines des paires de clés présentes dans votre ~/.ssh/répertoire et exécuterssh-add -D
3. associer explicitement une clé à un hôte donné dans votre ~/.ssh/configfichier

Ainsi:

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

1. Ce n’est probablement pas un bon moyen de s’y prendre, é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 ici à des vecteurs d’attaque par force brute.

2. C'est un bon moyen de partir en supposant que vous avez des clés inutiles et que vous pouvez les supprimer définitivement.

3. Et l'approche consistant à définir IdentitiesOnly sont probablement les moyens privilégiés de traiter ce problème!

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

Host *
IdentitiesOnly yes

Il active l'option IdentitiesOnly = yes par défaut. Si vous devez 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 arriver si (par défaut sur mon système) au moins cinq fichiers d'identité DSA / RSA sont 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 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).

Si vous avez plusieurs clés privées dans votre répertoire .ssh, vous pouvez désactiver "Authentification par clé publique" sur la ligne de commande à l'aide de l'argument facultatif '-o'.

Par exemple:

$ ssh -o PubkeyAuthentication=no root@host

Si vous avez un mot de passe et souhaitez simplement vous en servir pour vous connecter, voici comment procéder.

Pour utiliser UNIQUEMENT l'authentification par mot de passe et NON pour utiliser la clé publique et NE PAS utiliser le "clavier interactif" quelque peu trompeur (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

@ David dit: ajoutez simplement ceci IdentitiesOnly yes à votre .ssh / config, cela fait la même chose quessh -o PubkeyAuthentication=no.

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

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

Je sais que c’est un vieux sujet, mais je voulais simplement ajouter ici que j’ai rencontré le même message d’erreur, mais que le propriétaire du dossier .ssh était root plutôt que l’utilisateur qui utilisait la clé. J'ai corrigé le problème en lançant les commandes suivantes:

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

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

sudo chmod 700 /home/user/.ssh

Les fichiers du répertoire .ssh doivent avoir l'autorisation de 600:

sudo chmod 600 /home/user/.ssh/authorized_keys

Dans mon cas, le problème était les autorisations de répertoire. Cela a résolu le problème pour moi:

$ chmod 750 ~;chmod 700 ~/.ssh

Dans mon cas, cela se passait parce que j'utilisais le nom d'utilisateur "ubuntu", mais le nom d'utilisateur dans cette instance était "ec2-user"

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

Autorisation refusée (publickey).

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

Ma clé publique était entrée .ssh/authorized_keys2, mais le serveur était configuré pour lire uniquement .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é.

Trop d'échecs d'authentification

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

Voici quelques suggestions:

• Ajoutez -và voir si c'est le cas (vous utilisez trop d'identités).
• Liste des identités ajoutées par ssh-add -l.
• Retirer l' identité de l'agent ne par: ssh-add -d.
• Vous pouvez également supprimer toutes les identités ssh-add -Det ne rajouter que celles pertinentes.

• Si vous avez accès au serveur SSH, cochez l' MaxAuthTriesoption (voir:) man sshd_config.

  ^{Article connexe: Qu'est-ce qu'une connexion pour sshd_configla limite 's' MaxAuthTries '?}

• Si cela ne vous aide pas, assurez-vous que vous utilisez les bonnes informations d'identification ou le bon fichier.

Ce message peut apparaître lorsque le nom d'utilisateur et le mot de passe correct ne sont pas entrés.

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

vim /etc/passwd