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

256

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 [email protected]:.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.

Gabriel A. Zorrilla
la source
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 manqué de mentionner l'adresse source et utilisé le nom d'utilisateur à la fin de la clé.
journaliste du

Réponses:

416

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/
John T
la source
5
il m'est difficile de savoir où mettre cette ligne. Sur le serveur auquel j'essaie de me connecter, .ssh / config ne contient des informations que sur d'autres serveurs. Voulez-vous dire que cela devrait aller dans le fichier .ssh / config de l'ordinateur sur lequel je cherche à ssh? Si tel est le cas, cela n’est pas clair car votre réponse indique "une fois que vous êtes de nouveau connecté ..."
David LeBauer
2
Je dois mettre l'option entre guillemets, comme ceci:ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/
knb
1
Utilisateurs Windows exécutant PAGENT (Putty Agent), vérifiez que seules les clés dont vous avez besoin sont chargées. J'ai rencontré ce problème après avoir chargé accidentellement TOUTES mes clés privées.
Chris Rasco
2
La question demeure: pourquoi ssh"offre-t-il plusieurs clés" (tout en dessous ~/.ssh), même lorsque la règle pour host a un IdentityFile /path/to/private_key_fileparamètre explicite ? Cette clé explicitement spécifiée ne devrait-elle pas (à tout le moins) être offerte en premier? N'est-ce pas un bug / une erreur de fonctionnement dans le client openssh?
arielf
2
Mais ne devrait-il pas utiliser la clé spécifiée avec l' IdentityFileoption? Par exemple, sans l' IdentitiesOnlyoption, il essaie d'utiliser ma githubclé lorsque j'essaie de le faire ssh gitlab.com. Cela n'a aucun sens.
Iulian Onofrei
188

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

Ben West
la source
3
+1, j'aimerais pouvoir vous en donner plus. Raspberry Pi est le seul appareil dans lequel je ssh sans clé publique.
Obtenait
1
Et pour l'utiliser avec rsync:rsync -av -e 'ssh -o PubkeyAuthentication=no' '[email protected]:~/remote_file' 'local_file'
Ciro Santilli Il y a 9 jours 16:16
1
Vous pouvez également créer un alias pour le rendre encore plus rapide pour l’authentification du mot de passe. alias sshp = 'ssh -o PubkeyAuthentication = no'
dhempler
26

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!

slm
la source
Dans votre dernière ligne, vous avez identfile /home/YOU/.ssh/foo mais il devrait s'agir de identityfile (ne pas être f)
Nin
7

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.

Вгений Шаповалов
la source
6

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
Will Verna
la source
C'était exactement ce qui m'arrivait! Merci beaucoup pour l'explication;)
El Ninja Trepador
6

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]
Greg Rundlett
la source
3

@ 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

Alan Dong
la source
2

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
Adam
la source
Je serais prudent d'utiliser ceci sans mise en garde. Les autorisations de clé SSH sont généralement limitées à 400 pour certaines clés, notamment AWS. Si vous tentez de les définir ci-dessus, la clé ne sera pas acceptée et cela vous empêchera d'accéder à votre compte AWS.
Michael Ryan Soileau
1

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
tbc0
la source
0

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

Deepak Joy
la source
0

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

Benedikt Köppel
la source
0

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.

Kenorb
la source
-1

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
Matoeil
la source