WardtermCliente SSH
ES
Descargar

SSH "Too many authentication failures": cómo solucionarlo

Tu cliente SSH ofreció más claves de las que permite el servidor, normalmente porque el agente guarda muchas, y cada clave equivocada cuenta como un intento fallido. El límite por defecto es 6. Conéctate con ssh -o IdentitiesOnly=yes -i ~/.ssh/the_right_key user@server y después pon IdentitiesOnly yes e IdentityFile en un bloque Host.

Actualizada el . Reproducido con OpenSSH 10.3 en macOS y un ssh-agent de prueba aparte con 8 claves, contra OpenSSH 10.0 en Debian 13 con el MaxAuthTries por defecto de 6 y con un valor más bajo.

El mensaje

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

En el servidor, el registro dice:

maximum authentication attempts exceeded for user from 203.0.113.20 port 47120 ssh2 [preauth]

A menudo nunca te llegaron a pedir una contraseña. En nuestra prueba, una cuenta con una contraseña válida falló con este mensaje antes de cualquier prompt, porque las claves gastaron antes todos los intentos.

Comprueba la causa

Cuenta las claves de tu agente:

ssh-add -l

Después mira qué se ofrece realmente:

ssh -v user@server 2>&1 | grep -E 'Offering|Too many'
debug1: Offering public key: key1 ED25519 SHA256:...
debug1: Offering public key: key2 ED25519 SHA256:...
debug1: Offering public key: key3 ED25519 SHA256:...
debug1: Offering public key: key4 ED25519 SHA256:...
debug1: Offering public key: key5 ED25519 SHA256:...
debug1: Offering public key: key6 ED25519 SHA256:...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Cada clave que el servidor no acepta cuenta como un fallo, y el límite es MaxAuthTries, 6 por defecto. En nuestra prueba la sexta clave todavía tuvo su turno: con la clave correcta en sexto lugar el acceso funcionó, y con seis claves incorrectas por delante falló. Un servidor con un límite más bajo falla antes.

La solución: dile a ssh qué clave usar

Para un intento:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_server user@server

Para dejarlo fijo, añade esto a ~/.ssh/config:

Host server
    HostName 203.0.113.10
    User user
    IdentityFile ~/.ssh/id_ed25519_server
    IdentitiesOnly yes

-i solo no basta. Lo probamos: sin IdentitiesOnly, las claves del agente seguían yendo primero y volvía el mismo error. IdentitiesOnly yes es lo que limita ssh a las claves que nombraste.

Hay más ajustes por host en estos ejemplos de archivo ssh config.

Si la clave existe solo en el agente

IdentityFile puede apuntar al archivo de la clave pública. ssh usa entonces ese archivo para elegir la clave, y el agente hace la firma:

Host server
    IdentityFile ~/.ssh/id_ed25519_server.pub
    IdentitiesOnly yes

Si entras con contraseña

Aquí las claves solo estorban, así que desactívalas para este acceso:

ssh -o PubkeyAuthentication=no user@server

En un archivo de configuración, es PubkeyAuthentication no en el bloque del host.

Otras opciones

Guarda menos claves en el agente

ssh-add -l                      # list
ssh-add -d ~/.ssh/old_key       # remove one
ssh-add -D                      # remove all

Esto quita claves solo del agente y deja los archivos en paz. Si usas una clave distinta para cada servidor, la lista crece rápido, así que la configuración de arriba es la respuesta duradera.

Saltarte el agente en un host

Host server
    IdentityAgent none
    IdentityFile ~/.ssh/id_ed25519_server

Esto también funciona, pero tendrás que escribir la frase de contraseña de la clave cada vez, si la tiene.

Definir IdentitiesOnly para todos los hosts

Puedes poner IdentitiesOnly yes bajo Host *. Si un host no tiene IdentityFile, ssh prueba los archivos por defecto como ~/.ssh/id_ed25519 e ignora las demás claves del agente. Así que los hosts que dependían de una de esas otras claves necesitan su propia línea IdentityFile.

No subas MaxAuthTries por esto

Puedes subir el límite en un servidor que controlas, pero la causa está en el cliente. Todos los demás servidores a los que te conectes mantienen su límite, y un límite más alto da a cualquiera que esté adivinando más intentos por conexión.

Los fallos repetidos pueden hacer que te bloqueen

Si el servidor ejecuta fail2ban, cada desconexión como esta puede contar contra tu dirección. En nuestra prueba, una desconexión así añadió un fallo a la jail sshd. Si el error pasa a ser Connection refused tras unos pocos intentos, puede que te hayan bloqueado. Mira fail2ban para SSH.

Preguntas

¿Cuál es el valor por defecto de MaxAuthTries?

6. Cada clave que el servidor rechaza cuenta como un intento, así que un agente con muchas claves puede agotarlos antes de llegar a la correcta.

¿Por qué ssh -i no lo arregla?

Sin IdentitiesOnly yes, ssh sigue ofreciendo las claves del agente antes que la indicada con -i.

¿Cómo veo qué claves ofrece ssh?

Ejecuta ssh -v user@server y busca las líneas Offering public key.

Fuentes

Más en Mensajes de error

Todas las guías