web-dev-qa-db-fra.com

SSH abandonne avec trop d'échecs d'authentification

J'essaie d'exécuter ce simple script d'approvisionnement mais je rencontre des erreurs lors de l'exécution de vagrant up et alors vagrant provision commandes.

J'ai lu que je devais créer un /etc/ansible/hosts fichier que j'ai fait, en le remplissant avec:

[vagrant]
192.168.222.111

Ma configuration SSH (certains détails supprimés):

Host default
HostName 127.0.0.1
User vagrant
Port 2222
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile /Users/ashleyconnor/.vagrant.d/insecure_private_key
IdentitiesOnly yes
LogLevel FATAL

Host            server
HostName        XXX.XXX.XXX.XXX
User            ash
PreferredAuthentications publickey
IdentityFile    ~/.ssh/ash_ovh

Host            deployer
HostName        XXX.XXX.XXX.XXX
User            deployer
PreferredAuthentications publickey
IdentityFile    ~/.ssh/deployer_ovh

Host            bitbucket.org
PreferredAuthentications publickey
IdentityFile    ~/.ssh/bitbucket

Host            github.com
PreferredAuthentications publickey
IdentityFile    ~/.ssh/github

Host            staging
HostName        192.168.56.10
User            deployer
PreferredAuthentications publickey
IdentityFile    ~/.ssh/id_rsa

La sortie SSH que je reçois semble parcourir toutes mes clés:

<192.168.222.111> ESTABLISH CONNECTION FOR USER: vagrant
<192.168.222.111> REMOTE_MODULE setup
<192.168.222.111> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/Users/ashleyconnor/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'IdentityFile=/Users/ashleyconnor/.vagrant.d/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', '192.168.222.111', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061 && echo $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061'"]
fatal: [192.168.222.111] => SSH encountered an unknown error. The output was:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/ashleyconnor/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/ashleyconnor/.ansible/cp/ansible-ssh-192.168.222.111-22-vagrant" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.222.111 [192.168.222.111] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug3: timeout: 10000 ms remain after connect
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/ashleyconnor/.vagrant.d/insecure_private_key" as a RSA1 public key
debug1: identity file /Users/ashleyconnor/.vagrant.d/insecure_private_key type -1
debug1: identity file /Users/ashleyconnor/.vagrant.d/insecure_private_key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for Host "192.168.222.111" from file "/Users/ashleyconnor/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ashleyconnor/.ssh/known_hosts:20
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],zlib,none
debug2: kex_parse_kexinit: [email protected],zlib,none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 [email protected]
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 [email protected]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 527/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server Host key: RSA 50:db:75:ba:11:2f:43:c9:ab:14:40:6d:7f:a1:ee:e3
debug3: load_hostkeys: loading entries for Host "192.168.222.111" from file "/Users/ashleyconnor/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ashleyconnor/.ssh/known_hosts:20
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.222.111' is known and matches the RSA Host key.
debug1: Found key in /Users/ashleyconnor/.ssh/known_hosts:20
debug2: bits set: 511/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/ashleyconnor/.ssh/id_rsa (0x7fc212600540),
debug2: key: /Users/ashleyconnor/.ssh/bitbucket (0x7fc212600730),
debug2: key: /Users/ashleyconnor/.ssh/deployer (0x7fc212600a00),
debug2: key: /Users/ashleyconnor/.ssh/github (0x7fc212600c80),
debug2: key: /Users/ashleyconnor/.ssh/ash_ovh (0x7fc212601010),
debug2: key: /Users/ashleyconnor/.ssh/deployer_ovh (0x7fc2126011e0),
debug2: key: /Users/ashleyconnor/.vagrant.d/insecure_private_key (0x0), explicit
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,gssapi-keyex,hostbased,publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred: ,gssapi-keyex,hostbased,publickey
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/bitbucket
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/deployer
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/github
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/ash_ovh
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/deployer_ovh
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Received disconnect from 192.168.222.111: 2: Too many authentication failures for vagrant

Le vagrant ssh la commande fonctionne bien.

sshssh-keysvagrantansible
27
Ashley

Selon une ancienne page de manuel * ssh-config(5), ssh essaiera toujours toutes les clés connues par l'agent en plus des fichiers d'identité:

 IdentitiesOnly

         Specifies that ssh(1) should only use the authentication identity files
         configured in the ssh_config files, even if ssh-agent(1) offers more
         identities.  The argument to this keyword must be “yes” or “no”.  This
         option is intended for situations where ssh-agent offers many different
         identities.  The default is “no”.


 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or RSA authentication
         identity is read.  The default is ~/.ssh/identity for protocol version 1,
         and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol
         version 2.  Additionally, any identities represented by the  
         authentication agent will be used for authentication.  ssh(1) will try
         to load certificate information from the filename obtained by
         appending -cert.pub to the path of a specified IdentityFile.

Pour éviter cela, il faut spécifier IdentitiesOnly=yes en plus de la clé privée explicitement fournie.

Par exemple, en exécutant la commande ssh ci-dessous:

$ ssh -i /home/henk/.vagrant.d/insecure_private_key \
  [email protected] echo ok

produit:

Received disconnect from 192.168.222.111: 2: Too many authentication 
failures for vagrant

Cependant, exécuter la même commande ssh et, en plus, spécifier IdentitiesOnly=yes:

$ ssh -o IdentitiesOnly=yes \
  -i /home/henk/.vagrant.d/insecure_private_key [email protected] echo ok

produit:

ok

* Remarque: Le projet OpenBSD héberge des documents à jour pour IdentitiesOnly et IdentityFile . Il s'agit notamment de texte supplémentaire pour les nouvelles fonctionnalités qui ne changent pas l'essence de cette réponse.

38
Henk Langeveld

J'ai donc eu 5 clés dans mon ssh-agent et malgré l'option explicite d'utiliser la clé ssh vagabonde, il a toujours insisté pour parcourir les clés de mon agent avant d'atteindre facilement max_tries avant d'arriver à la bonne clé.

Pour vérifier que vous avez ce problème: Exécutez ssh-add -l - si cette liste est> 5, vous devez supprimer les clés ou désactiver l'agent.

Pour corriger: Exécutez ssh-add -d ~/.ssh/X où X est la clé que vous souhaitez supprimer.

8
Ashley

Après avoir essayé tous les conseils ici sans succès, j'ai reconnu que mon problème était la nouvelle méthode d'authentification (GSSAPI), qui a toujours échoué.

J'ai résolu cela en modifiant ~/.ssh/config fichier:

Host *
  GSSAPIAuthentication no

J'espère que cela aide quelqu'un aussi.

4
Peter

Pour éviter cela, nous pouvons utiliser ssh en utilisant -o 'IdentitiesOnly yes' par exemple ssh -i privateKey -o 'IdentitiesOnly yes' user@Host

alternativement, nous pouvons ajouter les lignes suivantes au fichier ~/.ssh/config

Host *
IdentitiesOnly yes
2
Jasodeep Chatterjee

Votre agent ssh détient plus de clés que le serveur ssh n'autorise les tentatives d'authentification ("MaxAuthTries", par défaut: 6).

Notez que certains agents ssh, en particulier le trousseau de clés GNOME, chargent automatiquement toutes les clés qu'ils trouvent dans ~/.ssh, et que ces clés ne peuvent pas être déchargées avec "ssh-add - [dD]".

Voici quelques solutions:

  • Vous avez déjà configuré la bonne clé dans votre ~/.ssh/config, vous n'avez donc pas besoin de l'agent. Incitez le client à ignorer l'agent, par ex. unset SSH_AUTH_SOCK ou utilisez "IdentitiesOnly = yes" comme l'a suggéré @ henk-langeveld
  • Déplacez certaines clés de ~/.ssh (un sous-répertoire comme ~/.ssh/noauto fonctionne aussi) pour éviter qu'elles ne se chargent automatiquement. Vous pouvez toujours les ajouter manuellement si vous en avez besoin.
  • Augmentez "MaxAuthTries" côté serveur, le nombre de tentatives d'authentification autorisées
2
Nils Toedtmann

J'ai rencontré cette même erreur en essayant d'exécuter un playbook ansible. J'ai fini par fournir l'option ssh IdentitiesOnly en utilisant --ssh-extra-args:

ansible-playbook -i ../.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml --ssh-extra-args="-o IdentitiesOnly=yes"
1
strictlyk3v

Pour connecter le serveur à l'aide de la commande de correction rapide:

ssh -o IdentitiesOnly=yes -i ~/.ssh/private_key_or_pem_file_name server_user_name@ip_OR_hostname echo ok

La manière recommandée est mentionnée ci-dessous:

Mais si vous avez des recettes capistrano ou d'autres logiciels qui connectent votre serveur ssh, vous devez corriger correctement comme mentionné ci-dessous:

Dans ~/.ssh/config le fichier mentionne l'option "IdentitiesOnly yes" dans la configuration de votre serveur

Host server_domain_OR_ip server_name_your_choice
    User server_user_name
    Hostname server_domain_OR_ip
    RSAAuthentication yes
    Compression yes
    IdentityFile ~/.ssh/private_key_OR_pem_file
    IdentitiesOnly yes
    Port 22

private_key_OR_pem_file: En cas de fichier pem, mentionnez également l'extension ".pem"

1
Taimoor Changaiz

Le message clé est

Received disconnect from 192.168.222.111: 2: 
    Too many authentication failures for vagrant

Vous avez copié la sortie sag-config vagrant en tant qu'hôte par défaut dans .ssh/config mais ceci est ignoré car il a des paramètres en conflit (nom d'hôte, port). Sans entrée correspondante, ssh essaiera simplement toutes les clés qu'il peut trouver.

Testez à nouveau la tentative ssh avec le -i option

$ ssh -i $HOME/.vagrant.d/insecure_private_key [email protected] echo ok

Je pense que c'est ainsi que vous spécifieriez cela dans l'inventaire Ansible:

[vagrant]
192.168.222.111 ansible_ssh_private_key_file=/.../.vagrant.d/insecure_private_key

en abrégé le chemin pour la lisibilité

Réponse originale:

Comparez la sortie de vagrant ssh-config avec l'entrée vagabonde dans votre .ssh/config. Assurez-vous que le chemin d'accès de la clé privée correspond exactement.

Vérifiez également que le fichier de clés ne peut être consulté par aucun autre compte. Nous savons tous ce qu'est cette clé, mais SSH ne sait pas que cette chose est de notoriété publique et essaie de nous protéger contre l'utilisation de clés qui pourraient être compromises.

0
Henk Langeveld