web-dev-qa-db-fra.com

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

J'ai un compte hostgator avec l'accès ssh activé et 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 [email protected]: .ssh/allowed_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 octets reçus jusqu'à présent) [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'à ce que je réussisse. Mais maintenant, il semble que le compteur d’échecs d’authentification ne se réinitialise pas (cela fait plus de 12 heures que nous attendons, le support technique "suppose" qu’il se réinitialise de 30 minutes à une 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'avais même installé ceci sur un serveur personnalisé Slicehost et j'avais moins de problèmes qu'avec ces gars-là. Une astuce? C'est peut-être quelque chose côté client et pas côté serveur.

sshauthentication
248
Gabriel A. Zorrilla

Il s’agit généralement de causé par 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'indicateur -v à votre commande ssh 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 pair" .

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 fichier ~/.ssh/config (sur l'ordinateur client) en ajoutant IdentitiesOnly comme 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 -D pour effacer les identités.

Si vous n'utilisez aucune configuration d'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/

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

ou

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

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

ssh -o PubkeyAuthentication=no [email protected]

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

Référence

179
Ben West

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

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

En plus de définir le IdentitiesOnly yes dans votre fichier ~/.ssh/config, vous avez deux autres options.

  1. Augmentez la MaxAuthTries (sur le serveur ssh)
  2. supprimez certaines des paires de clés présentes dans votre répertoire ~/.ssh/ et exécutez ssh-add -D
  3. associe explicitement une clé à un hôte donné dans votre fichier ~/.ssh/config

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!

24
slm

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.

7
Евгений Шаповалов

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 [email protected]
6
Greg Rundlett

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 optionnel '-o'.

Par exemple:

$ ssh -o PubkeyAuthentication=no root@Host
5
Will Verna

En quittant @ David en disant, ajoutez simplement ce IdentitiesOnly yes à votre .ssh/config, il fait la même chose que ssh -o PubkeyAuthentication=no.

Une fois 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

3
Alan Dong

Je sais que c’est un vieux fil de discussion, 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
2
Adam

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
1
tbc0

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

Puis 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

0
Deepak Joy

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 pour voir si c'est le cas (vous utilisez trop d'identités).
  • Répertoriez les identités ajoutées par ssh-add -l.
  • Supprimez l'identité en échec de l'agent par: ssh-add -d.
  • Vous pouvez également supprimer toutes les identités par ssh-add -D et ne rajouter que les identités pertinentes.

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

    Article connexe: Qu'est-ce qu'une connexion pour la limite 'MaxAuthTries' de sshd_config?

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

0
kenorb

Ma clé publique était dans .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é.

0
Benedikt Köppel