SSH aborta con demasiados errores de autenticación

26

Estoy intentando ejecutar este simple script de aprovisionamiento pero encuentro errores al ejecutar vagrant upy luego vagrant provisioncomandos.

Leí que necesitaba crear un /etc/ansible/hostsarchivo que hice, rellenándolo con:

[vagrant]
192.168.222.111

Mi configuración SSH (algunos detalles eliminados):

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 salida SSH que estoy recibiendo parece agotar todas mis claves:

<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

El vagrant sshcomando funciona bien.

ssh ssh-keys vagrant ansible Ceniza
fuente

Posible duplicado: serverfault.com/questions/139870/…

Henk Langeveld

Ligeramente diferente. Vagrant inyecta su clave cuando ejecuta vagrant sshy esta pregunta solo involucra la autenticación sin clave .

Ash

2

Agregar una nota para otras personas Google esto. Los switches Cisco Nexus sufren este mismo problema. Resuelto de la misma manera que señala @HenkLangeveld a continuación:IdentitiesOnly=yes

Brett Lykins

37

Según ssh-config(5), ssh siempre probará todas las claves conocidas por el agente además de cualquier archivo de identidad:

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

Para evitar esto, se debe especificar IdentitiesOnly=yesademás de la clave privada proporcionada explícitamente.

Por ejemplo, ejecutando el sshsiguiente comando:

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

produce:

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

Sin embargo, ejecuta el mismo sshcomando y, además, especifica IdentitiesOnly=yes:

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

produce:

ok

Henk Langeveld
fuente

Editar: se eliminó la suposición incorrecta sobre la necesidad de agregar la clave vagabunda al agente. Esto reduce la respuesta a su esencia. Veamos si podemos encontrar un duplicado ...

Henk Langeveld

3

¡Gracias por la explicación! Cuando se usa un .ssh/configarchivo, la sintaxis se encuentra IdentitiesOnly yesen las Hostsecciones apropiadas .

davil

Correcto, se ssh -o Option=Valueconvierte Option Valueen el archivo de configuración.

Henk Langeveld

perdone si la pregunta es demasiado básica pero, ¿es "IdentitiesOnly = yes" en el lado del servidor o un argumento para pasar del cliente? Parece el segundo ..

RollRoll

@ThePoet De hecho, lo mencionó como una sshopción de cliente.

Henk Langeveld

8

Así que tenía 5 claves en mi ssh-agenty, a pesar de la opción explícita de usar la clave ssh vagabunda, todavía insistía en recorrer las claves en mi agente antes de llegar a max_tries convenientemente antes de llegar a la clave correcta.

Para comprobar que tiene este problema: Ejecute ssh-add -l: si esta lista es> 5, debe eliminar las claves o deshabilitar el agente.

Para solucionarlo: ejecute ssh-add -d ~/.ssh/Xdónde Xestá la clave que desea eliminar.

Ceniza
fuente

Después de instalar el repositorio mazer-rackham y con esta información, podría reproducir su problema y he agregado una alternativa: asegúrese de que el agente conozca la clave vagabunda.

Henk Langeveld

Lo agregué al agente pero aún así tuve que eliminar las claves. ¿Tal vez la orden que agregas al agente es importante? EDITAR: solo lea su edición.

Ash

Tengo el mismo problema, pero no entiendo cómo lo solucionó. No puedo eliminar ninguna de las claves de mi ~/.ssh/carpeta, necesito entonces

rubo77

No está eliminando las claves de su ~.sshcarpeta, está eliminando las claves de ssh-agent daemon. Siempre puedes volver a agregarlos más tarde. Ver aquí para más información.

Ash

4

Después de probar todos los consejos aquí sin éxito, reconocí que mi problema era el nuevo método de autenticación (GSSAPI), que siempre no tenía éxito.

Resolví esto editando el ~/.ssh/configarchivo:

Host *
  GSSAPIAuthentication no

Espero que esto ayude a alguien también.

Peter
fuente

¡Esto parece formar una ranura al menos! Mi configuración con 5 teclas a través de ssh-agent funciona nuevamente. Sin embargo, supongo que fallará con 6 teclas ...

Robert Siemer

2

Su agente ssh tiene más claves de las que el servidor ssh permite intentos de autenticación ("MaxAuthTries", predeterminado: 6).

Tenga en cuenta que algunos agentes ssh, en particular el Llavero GNOME, cargan automáticamente todas las claves que encuentran en ~ / .ssh, y que estas claves no se pueden descargar con "ssh-add - [dD]".

Aquí hay algunas soluciones:

Ya ha configurado la clave correcta en su ~ / .ssh / config, por lo que no necesita el agente. Haga que el cliente ignore al agente, por ejemplo, unset SSH_AUTH_SOCKo use "IdentitiesOnly = yes" como sugirió @ henk-langeveld
Mueva algunas teclas fuera de ~ / .ssh (un subdirectorio como ~ / .ssh / noauto también funciona) para evitar que se carguen automáticamente. Todavía puede ssh-agregarlos manualmente si los necesita.
Aumente "MaxAuthTries" en el lado del servidor, el número de intentos de autenticación permitidos

Nils Toedtmann
fuente

2

Para evitar esto, podemos usar ssh usando -o 'IdentitiesOnly yes'egssh -i privateKey -o 'IdentitiesOnly yes' user@host

alternativamente, podemos agregar las siguientes líneas al archivo ~ / .ssh / config

Host *
IdentitiesOnly yes

Jasodeep Chatterjee
fuente

1

Para conectar el servidor usando el comando de reparación rápida:

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

La forma recomendada se menciona a continuación:

Pero si tiene recetas capistrano u otros softwares que están conectando su servidor ssh, entonces debe solucionarlo de la manera adecuada como se menciona a continuación:

En el archivo ~ / .ssh / config , mencione la opción "IdentitiesOnly yes" en la configuración de su servidor

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 caso de que el archivo pem mencione la extensión también ".pem"

Taimoor Changaiz
fuente

1

Me encontré con este mismo error al intentar ejecutar un libro de jugadas ansible. Terminé suministrando la opción IdentitiesOnly ssh usando --ssh-extra-args:

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

estrictamentek3v
fuente

0

Mensaje clave es

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

Copiaste la salida ssh-config vagabunda como host predeterminado, .ssh/configpero se omite porque tiene parámetros en conflicto (nombre de host, puerto). Sin una entrada coincidente, ssh solo probará todas las claves que pueda encontrar.

Pruebe el intento de ssh nuevamente con la -iopción

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

Creo que así es como lo especificaría en el inventario de Ansible:

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

Abreviado el camino para la legibilidad

Respuesta original:

Compare la salida de vagrant ssh-configcon la entrada vagabunda en su .ssh/config. Asegúrese de que la ruta de la clave privada coincida exactamente.

Verifique también que ninguna otra cuenta pueda acceder al archivo de claves. Todos sabemos cuál es esa clave, pero SSH no sabe que esto es de conocimiento público y trata de protegernos del uso de claves que pueden verse comprometidas.

Henk Langeveld
fuente

Originalmente copié la configuración, vagrant ssh-configpero la revisé nuevamente y es idéntica. También puedo cat /Users/ashleyconnor/.vagrant.d/insecure_private_keyy tengo los permisos adecuados.

Ash

Asegúrese de que nadie más pueda leer o escribir el archivo.

Henk Langeveld

1

Solo tengo permisos rw. No tuve suerte con las otras sugerencias, traté de correr ssh -i $HOME/.vagrant.d/insecure_private_key -l vagrant 192.168.222.111todavía obteniendoReceived disconnect from 192.168.123.123: 2: Too many authentication failures for vagrant

Ash

¿El host remoto tiene un usuario vagrant?

Henk Langeveld

Sí. Cuando lo ejecuto vagrant sshse conecta como usuario vagabundo

Ash

SSH aborta con demasiados errores de autenticación

Respuestas: