Pregunta Demasiadas fallas de autenticación para * nombre de usuario *


Tengo una cuenta de hostgator con acceso ssh habilitado y cuando intento 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:

Recibido desconectado de 111.222.33.44: 2: Demasiadas fallas de autenticación para el nombre de usuario
rsync: conexión inesperadamente cerrada (0 bytes recibidos hasta ahora) [remitente]
error rsync: error inexplicado (código 255) en io.c (601) [sender = 3.0.7]

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

Esto me está volviendo loco. Incluso había configurado esto en un servidor personalizado Slicehost y tenía menos problemas que con estos tipos. ¿Algún consejo? Tal vez es algo del lado del cliente y no del lado del servidor.


223


origen




Respuestas:


Esto usualmente es causado por ofrecer inadvertidamente varias claves ssh al servidor. El servidor rechazará cualquier clave después de que se hayan ofrecido demasiadas claves.

Puede ver esto usted mismo agregando el -v bandera a tu ssh comando para obtener una salida detallada. Verás que se ofrecen varias teclas hasta que el servidor rechaza la conexión y dice: "Demasiadas fallas de autenticación para [usuario]". Sin modo detallado, solo verá el mensaje ambiguo "Restablecimiento de conexión por pares".

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

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

Si usa ssh-agent, ayuda a ejecutar ssh-add -D para borrar las identidades.

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

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

Nota: el parámetro 'IdentitiesOnly yes' debe estar entre comillas.

o

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

359



no me queda claro dónde poner esta línea. En el servidor en el que estoy intentando iniciar sesión, .ssh / config solo tiene información para otros servidores. ¿Quiere decir que esto debería ir en el archivo .ssh / config en la computadora que estoy tratando de eliminar? Si es así, esto no está claro porque tu respuesta dice "una vez que hayas iniciado sesión de nuevo ..." - David LeBauer
Tengo que poner la opción entre comillas dobles, así: ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/ - knb
Usuarios de Windows ejecutando PAGENT (Putty Agent), verifique que solo tenga las claves que necesita cargar. Me encontré con este problema después de cargar accidentalmente TODAS mis claves privadas. - Chris Rasco
Sin embargo, para sshfs (fusible) Tengo que escribir la opción con un signo igual obligatorio, como este: sshfs -o "IdentitiesOnly=yes" -o IdentityFile=~/.ssh/id_dsa them@there/var/tmp /mnt/tmp  (Ubuntu 13.10) - knb
se puede usar sin comillas, así: -o IdentitiesOnly=yes - Valentin Kantor


Encontré una manera más fácil de hacer esto (si uso la autenticación con contraseña):

ssh -o PubkeyAuthentication=no username@hostname.com

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

Referencia


159



+1, desearía poder darle más. Raspberry Pi es el único dispositivo con el que me meto sin clave pública. Estaba recibiendo: "Demasiadas fallas de autenticación para pi" - blak3r
Y para usar eso con rsync: rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file' - Ciro Santilli 新疆改造中心 六四事件 法轮功
También puede crear un Alias ​​para hacerlo aún más rápido para la autenticación de contraseña. alias sshp = 'ssh -o PubkeyAuthentication = no' - dhempler


Recibí este error también y descubrí que sucedía porque el servidor estaba configurado para aceptar hasta 6 intentos:

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

Además de configurar el IdentitiesOnly yes en tus ~/.ssh/config archivo tiene un par de otras opciones.

  1. Aumenta el MaxAuthTries (en el servidor ssh)
  2. borre algunos de los pares de claves que tiene presentes en su ~/.ssh/ directorio y ejecutar ssh-add -D 
  3. vincular explícitamente una clave a un host dado en su ~/.ssh/config archivo

Al igual que:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Probablemente no sea una buena forma 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 ir asumiendo que tiene claves que no son necesarias y que pueden eliminarse permanentemente.

  3. ¡Y el enfoque de establecer IdentitiesOnly es probablemente la forma preferida de tratar este problema!


24



En su última línea tiene el archivo de identificación /home/YOU/.ssh/foo pero debe ser un archivo de identidad (a t not an f) - Nin
@Nin - gracias, arreglado. - slm


Si tiene una contraseña y desea simplemente usar la contraseña para iniciar sesión, aquí está cómo lo hace.

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

ssh -o PreferredAuthentications=password user@example.com

6





Si obtiene el siguiente error SSH:

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

Esto puede suceder si tiene (por defecto 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 comando.

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

Si tiene varias claves privadas en su directorio .ssh, puede desactivar 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

5



¡Esto era exactamente lo que me estaba sucediendo! Muchas gracias por la explicación;) - El Ninja Trepador


Saliendo de @David diciendo, simplemente agrega esto IdentitiesOnly yes a su .ssh / config, hace lo mismo que ssh -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


2





Sé que este es un hilo viejo, pero solo quería agregar aquí que encontré el mismo mensaje de error, pero fue causado por el propietario de la carpeta .ssh que era el usuario root que como el 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 deben tener el permiso de 600:

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

2



Tendría cuidado al usar esto sin una advertencia. Los permisos de clave SSH generalmente están restringidos a 400 para algunas claves, particularmente AWS. Si intenta establecerlos arriba, la clave no se aceptará y eso puede bloquearlo de su cuenta de AWS. - Michael Ryan Soileau


Agregué a ~ / .ssh / config esto:

Host *
IdentitiesOnly yes

Permite la opción IdentitiesOnly = yes de forma predeterminada. Si necesita conectarse con una clave privada, debe especificarla con la opción -i


2





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 sugirió "John T", obtuve este error:

Permiso denegado (publickey).

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


0





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

$ chmod 750 ~;chmod 700 ~/.ssh

0