Cómo recuperarse de "Demasiadas fallas de autenticación para el usuario root"

He hecho varios intentos para establecer la conexión SSH para el usuario root @ host usando terminal de masilla. Al hacerlo, especifiqué las credenciales incorrectas varias veces y después de eso las especifiqué correctamente, y luego, una vez aceptadas las credenciales, la sesión ssh se rompe con

"El servidor cerró inesperadamente la conexión de red".

Este error es reportado por la terminal de masilla. Cuando intente ssh root @ localhost desde la consola local, funciona bien. También funciona bien cuando ssh otheruser @ host de otro host. Por lo tanto, los problemas de conectividad de red no son culpables. El único error en el que estoy pensando es: "Demasiadas fallas de autenticación para el usuario root", aunque Putty informó un error diferente.

La pregunta es: ¿cómo recuperarse de esta condición de error y dejar que Putty vuelva a iniciar sesión? Reiniciar sshd parece no ayudar

¿Estás seguro de que el inicio de sesión raíz en ssh está permitido?

Verifique sshd_config y verifique que el inicio de sesión raíz esté permitido. sshd deberá reiniciarse si cambia la configuración.

"Demasiadas fallas de autenticación para el usuario root" significa que se ha excedido el límite MaxAuthTries de su servidor SSH . Ocurre para que su cliente intente autenticarse con todas las claves posibles almacenadas en /home/USER/.ssh/.

Esta situación se puede resolver de esta manera:

1. ssh -i / ruta / a / id_rsa root @ host
2. Especifique el par Host / IdentityFile en /home/USER/.ssh/config .
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. Aumente el valor de MaxAuthTries en el servidor SSH en / etc / ssh / sshd_config (no recomendado).

Si obtiene el siguiente error SSH:

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

Esto podría suceder si tiene (por defecto en mi sistema) cinco o más archivos de identidad DSA / RSA almacenados en su .sshdirectorio. En este caso, si la -iopción no se especifica en la línea de comando, 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).

Por lo tanto, si tiene varias claves privadas en su directorio .ssh, puede deshabilitarlas Public Key Authenticationen la línea de comando utilizando el -oargumento opcional.

Por ejemplo:

$ ssh -o PubkeyAuthentication=no root@host

En la máquina remota, abra / etc / sshd_config y cambie el valor

MaxAuthTries 30

Este es un problema típico cuando ha instalado varias claves o abre múltiples conexiones. El servidor verifica paso a paso cada tecla y si MaxAuthTries está configurado en 3, luego de los primeros 3 intentos, se desconectará. Típica seguridad ssh.

Le sugiero que use el modo detallado durante la conexión a la máquina remota para analizar el problema.

ssh -v -p número_puerto usuario @ nombre del servidor

Adivinar como hacen la mayoría de las personas en este foro es INCORRECTO y es una pérdida de tiempo. Primero intente analizar el problema, recopile información y luego pregunte.

Que te diviertas.

Esta es una mala práctica. Simplemente tenga un usuario regular en la caja remota y conéctese a través de ssh usándolo, luego obtenga acceso de root usando su / sudo.

Para mí, este problema se resolvió creando el siguiente ssh_config para el host al que me estaba conectando.

(~ / .ssh / config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

El problema ocurrió porque tengo demasiadas claves ssh en mi ~/.sshcarpeta, como 16 más o menos. Y sin ambas directivas IdentityFileAND IdentitiesOnlyen la configuración, mi máquina aparentemente estaba probando todas las claves ~/.sshy alcanzando el número máximo de intentos antes de intentar el IdentityFile correcto.

Le recomendaría, como Anon publicó anteriormente, use otro usuario para obtener acceso ssh y luego use el sucomando para obtener rootacceso.

También asegúrese de habilitar PermitRootLoginen el /etc/ssh/sshd_configarchivo en el servidor.

También enfrenté el mismo problema. Esto puede suceder fácilmente si está utilizando Pageant y tiene una gran cantidad de claves cargadas , ya que estos servidores cuentan cada oferta de clave pública como un intento de autenticación.

(Este consejo está tomado de aquí ).

Solucioné este problema en mis sistemas ejecutando los siguientes comandos:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Luego probando ssh en la máquina remota

Para abordar este problema temporalmente hasta que las cosas se puedan solucionar por completo como se indica en otra parte, puede restablecer la cuenta PAM de un usuario para que pueda volver a intentarlo:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>

Me mordió un problema similar. Sin embargo, la verdadera causa fue que tenía ForwardAgent yesen el archivo de configuración de una máquina a lo largo de la tubería. Me estaba conectando de la máquina A a la máquina B a la máquina C.

El mensaje de error se mostró en el intento de ssh de B -> C, pero fue causado por A con el reenvío activo. Entonces C recibió primero todas las claves de A, y solo luego las de B.

De repente apareció cuando agregué una clave más a A.

Solucioné este problema en mi Mac:

1. configurando la contraseña de root con "sudo passwd root"
2. editar y guardar el archivo de configuración ssh con "nano / etc / ssh_config" y
3. cambiando la autenticación RSA a "no" en lugar de sí.

OK, en mi caso esto fue bastante extraño, aquí va ...

Tengo una máquina virtual vagabunda estándar con una clave SSH y puedo usar SSH con Putty. Al intentar acceder durante la implementación en PHPStorm, recibo un too many authentication failureserror. Así que aumenté MaxAuthTriesmi sshd_configy luego recibí un Auth failederror y luego Auth cancel.

Ahora, no sé exactamente por qué intenté esto, pero ... agregué el punto al final de mi ruta de clave SSH en la ventana de implementación en PHPStorm. Entonces fue así:

C:\Users\Deadpool\\.ssh\chimichanga

y ahora es así:

C:\Users\Deadpool\\.ssh\chimichanga.

Y funciona ... En mi carpeta ".ssh" tengo más archivos:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

No estoy seguro de lo que hace ese maldito punto, pero usar el .ppkarchivo no funciona, así que supongo que es una especie de magia;) Ah, y podría deshacerme de MaxAuthTries después de ese "truco de puntos".

Otras respuestas le dicen la mejor manera de conectarse como root, y las implicaciones de seguridad de eso, pero su pregunta explícita fue

¿Cómo recuperarse de esta condición de error y dejar que Putty vuelva a iniciar sesión?

Menciona la última vez que se conectó y el servidor remoto interrumpió la conexión.

Lo que creo que puede encontrar es que el servidor remoto está ejecutando fail2ban (*) y "encarceló" su IP después de su inicio de sesión exitoso. Puede probar esto intentando iniciar sesión nuevamente, y ni siquiera recibirá el mensaje de inicio de sesión.

Hay dos soluciones, puede esperar el tiempo en la cárcel, en ese momento las cosas simplemente vuelven a la normalidad, pero el tiempo en la cárcel podría ser cualquier cosa. O puede encontrar una computadora diferente desde la que iniciar sesión, hacer eso y "liberar" su IP, en este caso "diferente" es desde la perspectiva del servidor remoto, por lo que otra computadora detrás del mismo firewall probablemente tampoco funcionará .

(*) fail2ban es un demonio súper práctico que puede verificar periódicamente varios archivos de registro y ajustar las reglas del firewall para hacer que el servidor "desaparezca" cuando detecta un comportamiento potencialmente malicioso de un cliente. En debian, sale de la caja configurada para detectar múltiples inicios de sesión ssh fallidos de una IP particular, y después de 3 (creo), descartará todos los paquetes de esa IP. Funciona de manera brillante para detener esos ataques de fuerza bruta con guión.

Como @sufferer mencionó en otra respuesta, algunas distribuciones de Linux incluyen monitores para proteger de ataques de fuerza bruta en servicios externos visibles como SSH, por ejemplo DenyHostso fail2ban. Estos monitores comprueban los archivos de registro en busca de intentos fallidos y agregan filtros para bloquear las direcciones IP que tienen demasiadas fallas (el número es configurable e independiente de la configuración sshd).

Si su distribución incluye fail2ban, que protegen servicios que agregan reglas al cortafuegos de iptables, puede verificar qué servicios o "cárceles" se supervisan utilizando el comando:

sudo fail2ban-client status

La cárcel para el servicio SSH es sshd, por lo que para verificar si hay direcciones IP prohibidas, puede usar:

sudo fail2ban-client status sshd

y para desbancar algunos abcd de IP:

sudo fail2ban-client set sshd unbanip a.b.c.d

Si es así DenyHosts, la lista prohibida está en el archivo /etc/hosts.deny; Puede editar este archivo directamente como root. Para otorgar acceso permanente a IP abcd, puede agregar la línea sshd:a.b.c.dal archivo /etc/hosts.allow.

Como siempre, el mancomando es tu amigo:

man fail2ban
man hosts.deny

Deberían existir otras utilidades similares, pero solo las he usado.

Tenga en cuenta que aumentar el número de reintentos permitidos en la configuración sshd no libera las IP prohibidas, solo permite más fallas en la misma conexión. Si se excede el número permitido, el usuario / atacante simplemente se vuelve a conectar para intentar n veces más.

Otros servicios tenían la lista de prohibición integrada (como se muestra en la respuesta de Rajnesh Thakur sobre reiniciar el servidor VNC).

Resolví este problema con dos simples pasos en mi servidor Ubuntu 16.04:

Primero pare mi servidor vnc o elimine el proceso -

vncserver -kill :1

y luego comenzar de nuevo

vncserver

Después de eso, conéctelo desde el cliente de Escritorio remoto:

192.0.2.99:5901

Hecho !!

siga los pasos a continuación para la resolución

1. Copia de seguridad / etc / ssh / sshd_config
2. Aumente el valor de MaxAuthTries en sshd_config
3. stopsrc -s sshd; startrc -s sshd

Y verifique nuevamente después de los cambios anteriores

Tuve el mismo problema en el que seguía recibiendo "SServer envió un mensaje desconectado tipo 2 (error de protocolo): demasiados errores de autenticación para el usuario"

Resolví este problema eliminando todos mis ssh (claves .ppk) y luego inicié sesión en el servidor integrado de AD.