Solución al error SSH Too Many Authentication Failures

El error «Too many authentication failures» en SSH indica que el servidor ha terminado la conexión tras alcanzar su límite de intentos de autenticación. Puede aparecer antes de que escribas una contraseña si el cliente está intentando autenticarse con varias identidades.

Una causa habitual es tener numerosas claves disponibles en el agente SSH y no seleccionar la adecuada para ese servidor. Para comprobarlo, conviene indicar expresamente la clave, revisar el registro de conexión y guardar una configuración específica para el destino.

Conecta indicando la clave y limitando las identidades

Si conoces la clave que debe utilizar esa cuenta, prueba desde el equipo cliente:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_servidor [email protected]

Sustituye la ruta de ejemplo por tu archivo de identidad y cambia el usuario y el servidor. Si la conexión utiliza un puerto distinto del habitual, indícalo mediante -p:

ssh -p 2222 -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_servidor [email protected]

La opción -i selecciona el archivo de identidad. El ajuste IdentitiesOnly=yes limita el uso de identidades adicionales que pueda ofrecer el agente.

Si funciona, guarda la selección por servidor. Si continúa fallando, revisa la configuración efectiva: puede haber otras identidades añadidas mediante reglas de SSH.

Por qué aparece el error antes de pedir la contraseña

El cliente puede intentar autenticarse con claves antes de ofrecer otros métodos. Si se acumulan suficientes fallos, el servidor cierra esa conexión antes de llegar a la credencial que esperabas utilizar.

El parámetro del servidor MaxAuthTries controla el máximo de intentos permitidos por conexión. Su valor predeterminado documentado es 6, aunque el administrador puede haber establecido otro y el tratamiento de las ofertas de claves depende de la versión de OpenSSH.

Por tanto, el mensaje no demuestra que hayas escrito mal la contraseña varias veces. Tampoco significa, por sí solo, que la cuenta o la dirección IP estén bloqueadas permanentemente. Otros mecanismos de protección pueden aplicar restricciones adicionales, pero requieren un diagnóstico separado.

Durante la autenticación con clave pública, la clave privada no se envía al servidor. El cliente demuestra que puede utilizarla mediante operaciones criptográficas.

Comprueba qué identidades está intentando utilizar SSH

Añade -v para obtener información de diagnóstico:

ssh -v -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_servidor [email protected]

Busca las líneas que indican qué identidades se ofrecen y qué métodos acepta el servidor. Si necesitas más detalle, puedes aumentar la verbosidad con -vv o -vvv.

Para revisar las identidades cargadas en el agente accesible desde esa terminal, ejecuta:

ssh-add -l

Este comando muestra sus huellas. Un aviso de que el agente no tiene identidades es distinto de un error que indica que no se puede contactar con él. Además, no tener claves en el agente no impide utilizar una clave disponible en un archivo local.

Si compartes el diagnóstico con soporte, revisa antes los nombres de usuario, servidores y rutas que aparecen. No publiques claves privadas ni sus contraseñas de protección.

Guarda una configuración específica para cada servidor

En el archivo de configuración del cliente, normalmente ~/.ssh/config, puedes definir un alias con su identidad:

Host servidor-trabajo
    HostName servidor.example
    User usuario
    Port 22
    IdentityFile ~/.ssh/id_ed25519_servidor
    IdentitiesOnly yes

Después utiliza el alias:

ssh servidor-trabajo

Adapta el nombre, el puerto y la ruta. Mantén una identidad distinta en cada bloque cuando los destinos requieran claves diferentes.

No necesitas aplicar una regla global a todas tus conexiones para resolver un único servidor. Los alias permiten comprobar el cambio con un alcance más concreto.

Revisa si otras reglas añaden claves

Las directivas IdentityFile pueden acumularse entre bloques coincidentes y archivos incluidos. Por eso, una regla general también puede aportar identidades al destino.

Consulta la configuración resultante sin iniciar la conexión:

ssh -G servidor-trabajo

Comprueba especialmente hostname, user, port, identitiesonly y las entradas identityfile. Esto ayuda a detectar diferencias entre el bloque que has escrito y lo que realmente utilizará el cliente.

Gestiona el agente sin vaciarlo innecesariamente

Si identificas una clave que ya no necesitas en el agente, puedes retirar esa identidad concreta utilizando su archivo público:

ssh-add -d ~/.ssh/id_ed25519_antigua.pub

Para cargar una identidad disponible en disco:

ssh-add ~/.ssh/id_ed25519_servidor

También existe ssh-add -D, que retira todas las identidades del agente. No borra sus archivos del disco, pero otras conexiones nuevas que dependan de ese agente pueden dejar de autenticarse hasta que vuelvas a cargarlas.

Por eso, seleccionar la identidad por destino suele ser más práctico que vaciar el agente cada vez. Si un gestor de claves vuelve a cargar identidades, revisa su configuración antes de repetir la limpieza.

Qué revisar si utilizas Ansible

Si la conexión manual funciona pero Ansible falla, compara el usuario, el destino, la clave y los argumentos de conexión. No basta con asumir que la automatización utiliza la misma configuración que tu prueba.

Con el complemento de conexión SSH, puedes añadir argumentos mediante ansible_ssh_common_args. Si ya existen opciones de salto o proxy, consérvalas y añade la selección necesaria.

Para una prueba puntual con un inventario existente:

ansible servidor-trabajo -m ansible.builtin.ping --private-key ~/.ssh/id_ed25519_servidor --ssh-common-args='-o IdentitiesOnly=yes'

Adapta el host al nombre utilizado en tu inventario. La prueba depende también de los requisitos del módulo y del equipo remoto; su resultado no se limita a comprobar la autenticación.

Si el servidor sigue rechazando la conexión

Si ya has limitado las identidades y el acceso continúa fallando, comprueba que el usuario sea correcto y que su cuenta tenga autorizada la clave pública correspondiente.

Un error de ruta de la clave, una credencial rechazada y un exceso de intentos son problemas diferentes. El registro detallado permite distinguirlos. Si administras el servidor, consulta también sus registros de autenticación; en caso contrario, facilita el diagnóstico al responsable.

Aumentar MaxAuthTries no debería ser la primera medida cuando el origen es una selección incorrecta de identidades en el cliente. Tampoco es necesario borrar known_hosts ni desactivar la verificación de la identidad del servidor: esas opciones corresponden a otra fase de la conexión.

Una vez resuelto, abre una conexión nueva mediante el alias y confirma que utiliza la identidad prevista. Así tendrás una configuración reutilizable sin depender de limpiar el agente antes de cada acceso.