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

Tengo una cuenta hostgator con acceso ssh habilitado. Al intentar cargar el archivo de clave .pub generado con este comando:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

Sigo recibiendo:

Desconexión recibida de 111.222.33.44: 2: demasiados errores de autenticación para el nombre de usuario
rsync: conexión inesperadamente cerrada (0 bytes recibidos hasta ahora) [remitente]
Error de rsync: error inexplicable (código 255) en io.c (601) [remitente = 3.0.7]

He estado jugando anteriormente con ssh hasta que tuve la falla de autenticación. Pero ahora parece que el contador de fallas de autenticación no se reinicia (ha estado esperando más de 12 horas ahora, el soporte técnico "supone" que se restablece después de 30 minutos a 1 hora, y otro tipo me dijo "se restablece cada vez que intenta iniciar sesión con el nombre de usuario ", jeesh).

Esto me está volviendo loco. Incluso lo configuré en un servidor personalizado de Slicehost y tuve menos problemas que con estos chicos.

¿Algun consejo? Quizás sea algo del lado del cliente y no del lado del servidor.

Esto generalmente se debe a la oferta inadvertida de múltiples claves ssh al servidor. El servidor rechazará cualquier clave después de que se hayan ofrecido demasiadas claves.

Puede ver esto por sí mismo agregando la -vbandera a su sshcomando para obtener resultados detallados. Verá que se ofrecen un montón de claves, hasta que el servidor rechace la conexión diciendo: "Demasiados errores de autenticación para [usuario]" . Sin el modo detallado, solo verá el mensaje ambiguo "Restablecimiento de la conexión por igual" .

Para evitar que se ofrezcan claves irrelevantes, debe especificar explícitamente esto en cada entrada de host en el ~/.ssh/configarchivo (en la máquina cliente) agregando IdentitiesOnlyasí:

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

Si usa el agente ssh, es útil ejecutarlo ssh-add -Dpara borrar las identidades.

Si no está utilizando ninguna configuración de hosts ssh, debe especificar explícitamente la clave correcta en el sshcomando de la siguiente manera:

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 manera más fácil de hacer esto (si usa autenticación de contraseña):

ssh -o PubkeyAuthentication=no username@hostname.com

Esto fuerza la autenticación sin clave. Pude iniciar sesión de inmediato.

Referencia

También recibí este error y descubrí que estaba sucediendo porque el servidor estaba configurado para aceptar hasta 6 intentos:

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

Además de configurarlo IdentitiesOnly yesen su ~/.ssh/configarchivo, tiene otras opciones.

1. Aumente el MaxAuthTries(en el servidor ssh)
2. elimine algunos de los pares de claves que tiene presentes en su ~/.ssh/directorio y ejecutessh-add -D
3. vincular explícitamente una clave a un host determinado en su ~/.ssh/configarchivo

Al igual que:

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 su 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 manera de asumir que tiene claves que no son necesarias y que pueden eliminarse permanentemente.

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

Agregué a ~ / .ssh / config esto:

Host *
IdentitiesOnly yes

Habilita la opción IdentitiesOnly = yes por defecto. Si necesita conectarse con una clave privada, debe especificarla con la opción -i

Si obtiene el siguiente error SSH:

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

Esto puede suceder si tiene (predeterminado en mi sistema) cinco o más archivos de identidad DSA / RSA almacenados en su directorio .ssh y si la opción '-i' no está especificada en la línea de comandos.

El cliente ssh primero intentará iniciar sesión con cada identidad (clave privada) y luego solicitará la autenticación de contraseña. Sin embargo, sshd corta la conexión después de cinco intentos de inicio de sesión incorrectos (nuevamente, el valor predeterminado puede variar).

Si tiene varias claves privadas en su directorio .ssh, puede deshabilitar la "Autenticación de clave pública" en la línea de comando utilizando el argumento opcional '-o'.

Por ejemplo:

$ ssh -o PubkeyAuthentication=no root@host

Si tiene una contraseña y desea simplemente usar la contraseña para iniciar sesión, así es como lo hace.

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

ssh -o PreferredAuthentications=password user@example.com

Saliendo de @David diciendo, solo agregue esto IdentitiesOnly yes a su .ssh / config, hace lo mismo quessh -o PubkeyAuthentication=no.

Después de iniciar sesión, elimine .ssh/authorized_keys. Ahora, regrese a la máquina local y escriba 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 hilo antiguo, pero solo quería agregar aquí que me encontré con el mismo mensaje de error, pero fue causado por el propietario de la carpeta .ssh como root en lugar del usuario que estaba usando la clave. Corrija 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 deben tener el permiso de 600:

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

En mi caso, el problema eran los permisos de directorio. Esto me lo arregló:

$ chmod 750 ~;chmod 700 ~/.ssh

En mi caso, sucedía porque estaba usando el nombre de usuario "ubuntu", pero el nombre de usuario en este caso era "usuario ec2"

Después de hacer lo que sugirió "John T", recibí este error:

Permiso denegado (clave pública).

Luego 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

Tenía mi clave pública .ssh/authorized_keys2, pero el servidor estaba configurado para solo lectura .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 iniciar sesión con éxito con mi clave.

Demasiadas fallas de autenticación

Este mensaje es causado por tener demasiados intentos fallidos de autenticación dados los límites permitidos impuestos en el servidor SSH remoto. Potencialmente, esto significa que tiene demasiadas identidades agregadas en el agente SSH.

Aquí hay algunas sugerencias:

• Agregue -vpara ver si ese es el caso (ha usado demasiadas identidades).
• Enumerar identidades agregadas por ssh-add -l.
• Retire su defecto la identidad del agente por: ssh-add -d.
• También puede eliminar todas las identidades ssh-add -Dy volver a agregar solo las relevantes.

• Si tiene acceso al servidor SSH, marque la MaxAuthTriesopción (ver:) man sshd_config.

  ^{Publicación relacionada: ¿Qué es una conexión para sshd_configel límite 's' MaxAuthTries '?}

• Si nada de esto ayuda, asegúrese de utilizar las credenciales o el archivo correctos.

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

Primero verifique que el usuario esté en la lista:

vim /etc/passwd