Watch at EaseHistorias. Respuestas. Perspectiva.

Tecnología · GUÍA PRÁCTICA

¿SSH dice “too many authentication failures”? Cuenta las claves ofrecidas antes de cambiar el servidor

La clave correcta puede existir y aun así no llegar a probarse. Demuestra el host, usuario, lista de identidades y orden de oferta efectivos; luego haz una prueba con una sola clave antes de vaciar el agente o aumentar MaxAuthTries.

Ilustración técnica original: Ilustración técnica original de varias claves del cliente consumiendo el límite SSH antes de la clave prevista y una prueba acotada con una clave.
Ilustración técnica original: El servidor puede cortar antes de la clave prevista; la prueba de una clave demuestra la selección sin borrar las demás. Watch at Ease

“Too many authentication failures” indica que se agotó el presupuesto de intentos de una conexión; no demuestra que alguien escribiera mal la contraseña repetidamente. Un cliente OpenSSH puede ofrecer varias claves públicas desde la configuración y el agente, y cada rechazo consume parte del límite del servidor.

Conserva la terminal que falló y comprueba la ruta real. No empieces con`ssh-add -D`,`IdentitiesOnly yes`global, borrando archivos de claves ni aumentando`MaxAuthTries`de forma general. Esos cambios borran pruebas, rompen otros hosts o debilitan una protección sin demostrar la causa.

1. Fija el destino fallido y la configuración efectiva

Usa la misma terminal, alias y usuario que fallaron. Registra el comando sin secretos. Si Git, un IDE o una automatización lanzó SSH, extrae primero el host y usuario que realmente pasó.

Ejecuta`ssh -G your-host | grep -Ei "^(hostname|user|identityfile|identityagent|identitiesonly|preferredauthentications) "`. Comprueba HostName y User antes de las claves, y revisa todos los IdentityFile; los Includes y bloques coincidentes pueden acumularlos.

Si el host o usuario es incorrecto, corrige esa ruta y repite el diagnóstico. No borres identidades para compensar una cuenta equivocada.

2. Compara identidades disponibles con el orden ofrecido

Ejecuta`ssh-add -l -E sha256`en la terminal fallida. Lista huellas del agente contactado; no significa que todas se ofrecerán ni incluye cada archivo cargado directamente por el cliente.

Haz un intento con`ssh -vvv user@your-host`. De cada línea “Offering public key”, anota solo tipo y huella SHA256 en orden. Oculta direcciones, usuarios y rutas privadas antes de compartir. La pregunta es si la huella prevista aparece antes del corte.

Si varias claves inesperadas aparecen primero, es un problema de selección. Si solo se ofrece la clave prevista y se rechaza, investiga usuario, authorized_keys, principals de certificado, firma del agente o política del servidor.

3. Prueba una sola clave sin borrar nada

Confirma la huella con`ssh-keygen -lf /path/to/key.pub -E sha256`y ejecuta`ssh -o IdentitiesOnly=yes -i /path/to/key user@your-host`. Limita solo esta conexión y conserva el agente y las otras claves.

Si funciona, servidor, cuenta y clave son compatibles; el fallo estaba en la selección u orden del contexto más amplio. Guarda un bloque Host estrecho con HostName, User, IdentityFile y`IdentitiesOnly yes`, y vuelve a verificar con`ssh -G`y`ssh -vvv`.

Si falla, conserva la traza. Permission denied después de una clave prevista o un rechazo de firma del agente son ramas distintas. Subir MaxAuthTries o vaciar el agente no demuestra autorización ni capacidad de uso.

4. Aplica la reparación duradera más pequeña

Para un host usa un bloque específico. No pongas IdentityFile fuera de su ámbito ni hagas global`IdentitiesOnly yes`sin auditar cada destino. GitHub y GitLab documentan selección por host para varias claves o cuentas.

Conserva identidades del agente que sirvan a otros sistemas. Retira una clave solo tras decidir por separado que está obsoleta, no como atajo. Si un cliente gráfico ignora OpenSSH, identifica sus propios controles de agente e identidad.

Cambia MaxAuthTries solo en una revisión independiente de política del servidor. El criterio de cierre es que el cliente ofrezca la huella correcta y sea aceptada, no obtener más intentos.

Tabla de decisión

HostName o User incorrectos — Corrige el destino y conserva las claves.

Muchas huellas inesperadas antes del corte — Prueba una clave y usa un bloque Host estrecho.

Una huella prevista se ofrece y se rechaza — Pasa a autorización o firma.

La prueba de una clave funciona — Conserva las demás identidades y verifica la configuración.

El cliente no es OpenSSH o ignora ssh_config — Identifica sus controles propios antes de cambiar el servidor.

Ilustración técnica original: Ilustración técnica original que asigna la configuración SSH efectiva y las claves ofrecidas a cuatro ramas de reparación estrechas.
Ilustración técnica original: Cambia solo el primer límite que falla: destino, orden, autorización o implementación del cliente. Watch at Ease