Demasiados fallos de autenticación para *nombre de usuario*

Esto suele ser causado por ofrecer inadvertidamente múltiples claves ssh al servidor. El servidor rechazará cualquier clave después de que se hayan ofrecido demasiadas claves.

Puedes ver esto por ti mismo añadiendo el indicador -v a tu comando ssh para obtener una salida verborreica. Verás que se ofrecen un montón de claves, hasta que el servidor rechaza la conexión diciendo: “Demasiados fallos de autenticación para [usuario]”. Sin el modo verborreico, sólo verá el mensaje ambiguo _“Conexión restablecida por el par”.

Para evitar que se ofrezcan claves irrelevantes, debe especificarlo explícitamente en cada entrada del host en el archivo ~/.ssh/config (en la máquina cliente) agregando IdentitiesOnly de la siguiente manera:

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

Si utiliza el agente ssh, es útil ejecutar ssh-add -D para borrar las identidades.

Si no usas ninguna configuración de hosts ssh, tienes que especificar explícitamente la clave correcta en el comando ssh así:

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

Nota: el parámetro ‘IdentitiesOnly yes’ tenía que estar entre comillas.

o

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

Encontré una forma más fácil de hacerlo (si se usa la autenticación de la contraseña):

ssh -o PubkeyAuthentication=no username@hostname.com

Esto fuerza la autenticación sin clave. Pude iniciar sesión inmediatamente. Referencia

Yo también estaba recibiendo este error y encontré que estaba sucediendo b/c el servidor estaba configurado para aceptar hasta 6 intentos:

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

Además de configurar el IdentitiesOnly yes en tu archivo ~/.ssh/config tienes un par de opciones más.

1. Aumentar el MaxAuthTries (en el servidor ssh)
2. eliminar algunos de los pares de claves que tienes presentes en tu directorio ~/.ssh/ y ejecutar ssh-add -D
3. vincular explícitamente una clave a un host determinado en tu archivo ~/.ssh/config

Así:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo

1. Probablemente no sea una buena manera de hacerlo, dado que debilita un poco tu servidor ssh ya que ahora aceptará más claves en un intento de conexión determinado. Piensa en los vectores de ataque de fuerza bruta aquí.

2. Es una buena forma de hacerlo asumiendo que tienes claves que no se necesitan y que pueden ser borradas permanentemente.

3. Y el enfoque de establecer IdentitiesOnly son probablemente las formas preferidas de tratar este tema!

Añadí a ~/.ssh/config esto:

Host *
IdentitiesOnly yes

Habilita la opción IdentitiesOnly=yes por defecto. Si necesitas conectarte con clave privada, debes especificarlo con la opción -i

Si obtienes el siguiente error de SSH:

$ Received disconnect from host: 2: Too many authentication failures for root

Esto puede suceder si tienes (por defecto en mi sistema) cinco o más archivos de identidad DSA/RSA almacenados en tu directorio .ssh y si la opción ‘-i’ no está especificada en la línea de comandos.

El cliente ssh intentará primero iniciar sesión usando cada identidad (clave privada) y a continuación pedirá la autenticación de la contraseña. Sin embargo, sshd abandona la conexión después de cinco intentos fallidos de ingreso (nuevamente el valor por defecto puede variar).

Si tienes un número de claves privadas en tu directorio .ssh puedes deshabilitar la “Autenticación de clave pública” en la línea de comandos usando el argumento opcional ‘-o’.

Por ejemplo:

$ ssh -o PubkeyAuthentication=no root@host

Si tienes una contraseña, y quieres simplemente usar la contraseña para entrar, así es como lo haces.

Para usar SOLAMENTE la autenticación de la contraseña y NO usar la clave pública, y NO usar el algo engañoso “teclado-interactivo” (que es un superconjunto que incluye la contraseña), puedes hacerlo desde la línea de comandos:

ssh -o PreferredAuthentications=password user@example.com

Saliendo @David diciendo, solo agrega este IdentitiesOnly yes a tu .ssh/config, hace lo mismo que ssh -o PubkeyAuthentication=no.

Después de que te conectes, elimina .ssh/authorized_keys. Ahora, vuelve a la máquina local y escribe lo siguiente

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Esto debería volver a habilitar su ssh con clave pública

Sé que este es un viejo hilo, pero sólo quería añadir aquí que me encontré con el mismo mensaje de error, pero fue causado por el propietario de la carpeta .ssh siendo root en lugar del usuario que estaba usando la clave. Corregí el problema ejecutando los siguientes comandos:

sudo chown -R user:user /home/user/.ssh

También me aseguré de que los permisos fueran correctos en la carpeta .ssh:

sudo chmod 700 /home/user/.ssh

Los archivos dentro del directorio .ssh deberían tener el permiso de 600:

sudo chmod 600 /home/user/.ssh/authorized_keys

En mi caso, el problema eran los permisos del directorio. Esto lo arregló para mí:

$ chmod 750 ~;chmod 700 ~/.ssh

Esto fue divertido para mí. Resulta que cambié mi contraseña localmente mientras estaba en un modo de localización diferente al del teclado que usaba para acceder remotamente. Esto efectivamente hizo que mi contraseña fuera diferente de lo que pensé que era, probablemente porque uno de mis caracteres especiales era diferente de lo que el teclado decía que era.

Demasiados fallos de autenticación

Este mensaje es causado por tener demasiados intentos de autenticación fallidos dados los límites permitidos que se aplican en el servidor SSH remoto. Esto significa potencialmente que tienes demasiadas identidades añadidas en el agente SSH.

Aquí hay algunas sugerencias:

• Añade -v para ver si ese es el caso (has usado demasiadas identidades).
• Lista de identidades añadidas por ssh-add -l.
• Elimina la identidad fallida del agente por: ssh-add -d.
• También puedes borrar todas las identidades por ssh-add -D y volver a añadir sólo la relevante.

• Si tienes acceso al servidor SSH, marca la opción MaxAuthTries (ver: man sshd_config ).

• Si nada de esto ayuda, asegúrate de que estás usando las credenciales o el archivo correcto.

Tenía mi clave pública en .ssh/authorized_keys2, pero el servidor estaba configurado para leer sólo .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

Después de mover mi archivo a .ssh/authorized_keys, puedo entrar con éxito con mi clave.

En mi caso, estaba sucediendo porque estaba usando el nombre de usuario “ubuntu”, pero el nombre de usuario en esta instancia era “ec2-user”

Después de hacer lo que “John T” sugirió, obtuve este error:

Permiso denegado (publickey).

Entonces encontré la solución (es decir, cambiar el nombre de usuario a “ec2-user”) en esta respuesta: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

Este mensaje puede aparecer cuando no se introduce el nombre de usuario y la contraseña correctos.

Primero compruebe que el usuario está en la lista:

vim /etc/passwd