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


J'ai un compte hostgator avec un accès ssh activé et 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 nomutilisateur@111.222.33.44: .ssh / authorized_keys

Je continue à recevoir:

Reçu déconnexion de 111.222.33.44: 2: Trop d'échecs d'authentification pour le nom d'utilisateur
rsync: connexion inopinément fermée (0 octet reçu 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 j'obtienne l'authentification. Mais semble maintenant que le compteur d'échec d'authentification ne se réinitialise pas (il attend maintenant plus de 12 heures, le support technique "suppose" qu'il se réinitialise après 30 min à 1 heure, et un autre gars m'a dit qu'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 configuré ceci dans un serveur personnalisé Slicehost et avait moins de problèmes qu'avec ces gars-là. Un conseil? Peut-être que c'est quelque chose côté client et pas côté serveur.


223
2017-09-12 17:14


origine




Réponses:


C'est généralement causé par inadvertance offrant plusieurs clés SSH au serveur. Le serveur rejettera toutes les clés une fois que trop de clés auront été proposées.

Vous pouvez le voir par vous-même en ajoutant le -v drapeau à votre ssh commande pour obtenir une sortie détaillée. Vous verrez qu'un tas de clés est offert, 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 "Réinitialisation de la connexion par paire".

Pour empêcher l’offre de clés non pertinentes, vous devez le spécifier explicitement dans chaque entrée d’hôte du ~/.ssh/config (sur la machine cliente) fichier en ajoutant IdentitiesOnly ainsi:

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

Si vous utilisez ssh-agent, cela aide à exécuter ssh-add -D effacer les identités.

Si vous n'utilisez pas de configuration d'hôtes ssh, vous devez spécifier explicitement la clé correcte dans le ssh commande comme ça:

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

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

ou

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

359
2017-09-12 17:53



il n'est pas clair pour moi où mettre cette ligne. Sur le serveur sur lequel je tente de me connecter, .ssh / config ne contient que des informations pour les autres serveurs. Voulez-vous dire que cela devrait aller dans le fichier .ssh / config sur l'ordinateur à partir duquel j'essaie de ssh? Si c'est le cas, cela n'est pas clair car votre réponse dit "une fois que vous êtes connecté à nouveau ..." - David LeBauer
Je dois mettre l'option entre guillemets, comme ceci: ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/ - knb
Les utilisateurs de Windows exécutant PAGENT (Agent de mastic) vérifient que vous ne disposez que des clés à charger. J'ai rencontré ce problème après avoir accidentellement chargé TOUTES mes clés privées. - Chris Rasco
Cependant, pour sshfs (fusible) Je dois écrire l'option avec un signe d'égalité obligatoire, comme ceci: sshfs -o "IdentitiesOnly=yes" -o IdentityFile=~/.ssh/id_dsa them@there/var/tmp /mnt/tmp  (Ubuntu 13.10) - knb
il peut être utilisé sans guillemets, comme ceci: -o IdentitiesOnly=yes - Valentin Kantor


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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Référence


159
2018-03-25 00:14



+1, j'aimerais pouvoir vous donner plus. Raspberry Pi est le seul périphérique dans lequel je ssh sans clé publique. Obtenait: "Trop d'échecs d'authentification pour pi" - blak3r
Et pour l'utiliser avec rsync: rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file' - Ciro Santilli 新疆改造中心 六四事件 法轮功
Vous pouvez également créer un alias pour le rendre encore plus rapide pour l'authentification par mot de passe. alias sshp = 'ssh -o PubkeyAuthentication = no' - dhempler


J'avais aussi cette erreur et j'ai constaté que cela se passait b / c le serveur était configuré pour accepter jusqu'à 6 essais:

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

En plus de définir le IdentitiesOnly yes dans ton ~/.ssh/config fichier vous avez quelques 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 ~/.ssh/ répertoire et run ssh-add -D 
  3. lier explicitement une clé à un hôte donné dans votre ~/.ssh/config fichier

Ainsi:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Ce n'est probablement pas un bon moyen d'y parvenir, car cela affaiblit un peu votre serveur ssh car il acceptera maintenant plus de clés dans une tentative de connexion donnée. Pensez aux vecteurs d'attaque en force brute ici.

  2. Est-ce une bonne façon de faire en supposant que vous avez des clés qui ne sont pas nécessaires et peuvent être supprimées de manière permanente.

  3. Et l'approche de la définition d'IdentitiesOnly est probablement la manière préférée de traiter ce problème!


24
2018-06-09 04:56



Dans votre dernière ligne, vous avez le fichier d'identification /home/YOU/.ssh/foo mais il doit s'agir d'un fichier d'identité (et non d'un f) - Nin
@Nin - merci, corrigé. - slm


Si vous avez un mot de passe et souhaitez simplement utiliser le mot de passe 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 "clavier interactif" quelque peu trompeur (qui est un sur-ensemble avec mot de passe), vous pouvez le faire depuis la ligne de commande:

ssh -o PreferredAuthentications=password user@example.com

6
2018-06-19 14:22





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) au moins cinq fichiers d'identité DSA / RSA 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 essaiera d'abord de se connecter en utilisant chaque identité (clé privée) et l'invite suivante pour l'authentification par mot de passe. Cependant, sshd supprime la connexion après cinq tentatives de connexion incorrectes (à nouveau, 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 l'authentification par clé publique sur la ligne de commande en utilisant l'argument facultatif '-o'.

Par exemple:

$ ssh -o PubkeyAuthentication=no root@host

5
2017-09-20 21:44



C'était exactement ce qui m'arrivait! Merci beaucoup pour l'explication;) - El Ninja Trepador


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


3
2017-07-23 17:29





En partant de @David, ajoutez simplement ceci IdentitiesOnly yes à votre .ssh / config, il 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 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 la clé publique


2
2018-01-25 05:48