termalLos mensajes de error de SSH son escuetos a propósito — el protocolo no le dirá a un desconocido por qué lo rechazó. Eso es buena seguridad y mala ergonomía: el mensaje que ves suele estar a dos pasos del problema real. Esta es una guía de campo de los trece errores que te encontrarás de verdad, qué significa cada uno en realidad, y la ruta más rápida a una solución.
Una herramienta antes de empezar: ssh -v user@host (añade hasta -vvv — leer esa salida (en inglés)). Casi todo misterio de aquí abajo deja de serlo en cuanto ves en qué paso del handshake se muere.
Los errores de un vistazo
| Error | Qué significa | Primer paso |
|---|---|---|
Connection refused | El host respondió; nada escucha en ese puerto | Comprueba que sshd está activo y en el puerto que marcaste |
Connection timed out | Los paquetes desaparecieron en el camino | Revisa el firewall / grupo de seguridad de la nube |
Permission denied (publickey) | No se aceptó ninguna clave que ofreciste | Verifica el usuario, luego la clave, luego authorized_keys |
Permission denied (sin preguntar contraseña) | La auth por contraseña está desactivada; debe funcionar una clave | Usa una clave, o entra por la consola del proveedor |
Host key verification failed | La clave del servidor cambió desde que confiaste en ella | Verifica por otra vía, luego ssh-keygen -R |
Too many authentication failures | El agente ofreció demasiadas claves | -o IdentitiesOnly=yes con -i |
UNPROTECTED PRIVATE KEY FILE | Otros pueden leer el archivo de clave | chmod 600 a la clave privada |
Broken pipe | Se cortó una conexión inactiva | Añade ServerAliveInterval |
no matching key exchange method | Servidor heredado, cliente moderno | Reactiva un algoritmo solo para ese host |
Connection reset by peer | TCP se cerró de golpe antes del saludo SSH | Revisa fail2ban / MaxStartups |
Bad configuration option | Tu cliente es demasiado antiguo para una línea de config | Actualiza ssh, o protege la línea |
did not receive identification string | Algo se conectó pero no envió banner | Normalmente un escáner; ignóralo en el servidor |
Unspecified GSS failure | Un intento de Kerberos falló y recurrió a otra vía | Ignóralo si el inicio de sesión igual tiene éxito |
1. Connection refused
La máquina es alcanzable, pero nada escucha en el puerto que tocaste. Este casi nunca es culpa tuya:
- sshd no está corriendo —
systemctl status sshddesde una consola (los proveedores de VPS tienen una consola web para justo este momento); - escucha en un puerto no estándar — prueba
ssh -p 2222, o revisaPorten/etc/ssh/sshd_config; - un firewall está rechazando activamente (en vez de descartar) el puerto.
Si acabas de reconstruir el servidor, es el firewall. Si ayer funcionaba, sshd se cayó o cambió el puerto.
Solución completa: connection refused vs timed out, explicado.
2. Connection timed out
Distinto de refused: tus paquetes se desvanecen. El host está caído, la IP es incorrecta, o — lo más habitual en máquinas en la nube — un grupo de seguridad / ACL de red descarta el puerto 22 en silencio. Revisa primero las reglas de firewall del proveedor, luego si estás en una red que bloquea el 22 saliente (las Wi-Fi de invitados de hoteles y oficinas adoran esto; prueba un acceso basado en el puerto 443 o una red distinta para confirmarlo).
Solución completa: el mismo recorrido de refused vs timed out tiene la rama de timed-out paso a paso.
3. Permission denied (publickey)
El campeón de todos los tiempos. El servidor solo acepta auth por clave, y no aceptó ninguna clave que ofreciste. Por orden de probabilidad:
- Usuario equivocado.
ubuntuen imágenes de Ubuntu,ec2-useren Amazon Linux,rooten la mayoría de los VPS pelados. La misma clave con el nombre de usuario equivocado produce justo este error — cada imagen de la nube elige su propio usuario de inicio de sesión, que es la mitad del primer inicio de sesión en EC2/VPS (en inglés). - No se ofreció tu clave.
ssh -vmuestra cada clave probada. Si tu clave no está en la lista, apúntala explícitamente:ssh -i ~/.ssh/id_ed25519 user@host. - La clave no está en el servidor. Su mitad pública debe ser una línea en
~user/.ssh/authorized_keys— de ese usuario, no del de root. - Permisos del lado del servidor. sshd se niega a respetar
authorized_keyssi el directorio home,~/.ssh(700) o el propio archivo (600) tienen permiso de escritura de grupo. Este es el clásico «copié la clave y sigue sin funcionar».
Solución completa: Permission denied (publickey), una solución sistemática rápida (en inglés) repasa cada culpable en orden.
4. Permission denied cuando esperabas que te pidiera contraseña
Si querías auth por contraseña y nunca te la pidió, el servidor tiene PasswordAuthentication no — la mayoría de las imágenes de la nube vienen así, y es el valor por defecto correcto. Usa la consola del proveedor o tu clave existente para entrar, y luego añade la clave nueva como es debido en lugar de reactivar las contraseñas.
5. Host key verification failed / REMOTE HOST IDENTIFICATION HAS CHANGED
El banner que asusta, con esa energía de calavera ASCII. El servidor presentó una clave distinta de la que confiaste antes. Dos explicaciones: la máquina se reconstruyó/reinstaló legítimamente (con diferencia, el caso común), o algo entre tú y el servidor lo está suplantando (el caso para el que existe el aviso).
Si — y solo si — sabes que el servidor se reconstruyó: ssh-keygen -R hostname quita la entrada obsoleta, y la siguiente conexión vuelve a confiar. No metas esa eliminación a ciegas en un script dentro de tu flujo; la única vez que el aviso es real, es el único aviso que tendrás.
Solución completa: Host key verification failed, y la forma correcta de arreglarlo (en inglés).
6. Too many authentication failures
Tu agente ofreció con entusiasmo seis claves, y el MaxAuthTries del servidor dijo basta. Dile al cliente que ofrezca solo la clave que quieres:
ssh -o IdentitiesOnly=yes -i ~/.ssh/the_right_key user@host…o hazlo permanente en ~/.ssh/config por host. Si llevas muchas claves, IdentitiesOnly yes bajo Host * te ahorrará este error para siempre.
7. WARNING: UNPROTECTED PRIVATE KEY FILE
Tu clave privada la pueden leer otros, y el cliente se niega a usarla. chmod 600 ~/.ssh/id_ed25519. En Windows esto aparece tras copiar claves entre máquinas o sacarlas de una unidad en la nube — corrígelo en las propiedades de Seguridad del archivo, o mantén las claves fuera de las carpetas sincronizadas del todo.
8. client_loop: send disconnect: Broken pipe (la sesión que se muere cuando apartas la vista)
Conexiones inactivas que corta un router NAT o un firewall agresivo entre tú y el servidor. Los keepalives lo arreglan desde el cliente:
Host *
ServerAliveInterval 30
ServerAliveCountMax 4Dos minutos de silencio tolerados, paquetes cada 30 segundos para que la tabla NAT nunca te olvide. Si las sesiones se mueren bajo carga en vez de inactivas, eso es otra bestia — mira la MTU (sobre todo con VPN) en lugar de los keepalives.
9. no matching key exchange method found / no matching cipher
Estás hablando con algo viejo — un router, un switch, un appliance atascado en criptografía heredada. OpenSSH moderno quitó esos algoritmos por buenas razones. Reactívalos solo para ese host, nunca de forma global:
Host ancient-switch
KexAlgorithms +diffie-hellman-group14-sha1
Ciphers +aes256-cbcEl mensaje de error nombra los algoritmos que ofreció el servidor; añade el menos malo que liste.
10. ssh_exchange_identification: read: Connection reset by peer
La conexión TCP se abrió y se cerró de golpe de inmediato, antes de que SSH siquiera saludara. Sospechosos habituales: fail2ban o DenyHosts ha baneado tu IP (revisa /etc/hosts.deny y la jail de fail2ban desde una consola), sshd está sobrecargado (MaxStartups agotado por un escáner martilleando el puerto), o la comprobación de salud de un balanceador de carga se está comiendo las conexiones. Si es fail2ban y es tu propio servidor, la solución es un inicio de sesión por consola y fail2ban-client unban <your-ip> — y luego saca SSH del radar de los escáneres o endurece la jail para no ser el daño colateral de la semana que viene.
11. Bad configuration option: pubkeyacceptedalgorithms
No es un problema del servidor — tu ssh local es demasiado antiguo para tu archivo de configuración. PubkeyAcceptedAlgorithms llegó en OpenSSH 8.5 (reemplazó a PubkeyAcceptedKeyTypes); dale esa línea a un cliente más antiguo — el ssh de serie de macOS de cierta edad, una distro vieja, una imagen de contenedor mínima — y se niega a parsear el archivo del todo. Tres salidas: actualiza el cliente (ssh -V te dice en qué punto estás); usa la grafía antigua PubkeyAcceptedKeyTypes, que las versiones nuevas aún aceptan como alias; o protege la línea para que solo la lean los clientes capaces:
Match all
# only OpenSSH >= 8.5 gets here via Include ordering— en la práctica, la protección más simple es mantener las opciones sensibles a la versión en un archivo aparte incorporado con Include, para que un cliente viejo con los mismos dotfiles simplemente lo salte. La misma forma de error (Bad configuration option: <algo>) siempre significa lo mismo: esa palabra es desconocida para este binario — comprueba primero la grafía de la opción, y segundo la versión del binario.
12. did not receive identification string / invalid ssh identification string
Ambos viven en el primerísimo paso de SSH — el intercambio de banner, antes de cualquier criptografía. did not receive identification string from <ip> lo registra sshd del lado del servidor cuando algo abrió una conexión TCP al puerto 22 pero nunca envió la línea SSH-2.0-...: un escáner de puertos, la comprobación de salud de un balanceador de carga, una sonda de monitorización, o un cliente que se rindió. En los registros de tu servidor casi siempre es ruido de fondo, no un fallo — a menos que sea tu cliente el que no logra conectar, en cuyo caso algo en el camino (un proxy, un TCP wrapper, un IDS) se está comiendo el banner.
kex_exchange_identification: ... invalid ssh identification string es la imagen espejo: algo sí respondió, pero con datos que no son SSH. Causas habituales, en orden: apuntaste ssh al puerto equivocado — un servidor HTTP, una base de datos, un portal cautivo que devuelve HTML; un middlebox en el camino está interceptando la conexión y respondiendo en lugar del servidor; o un error de configuración de ProxyCommand/ProxyJump está canalizando hacia el cliente algo que no es un flujo SSH — la página de error de un proxy llegando donde debería ir un banner. Confirma que de verdad estás hablando con un sshd: nc <host> 22 debería imprimir un banner SSH-2.0-OpenSSH... de inmediato. Si imprime HTML o nada, el puerto (o el host, o el salto del proxy) es el equivocado, no tu clave.
13. Unspecified GSS failure / debug1: unspecified GSS failure. Minor code may provide more information
Ruido de Kerberos. OpenSSH intenta auth GSSAPI (Kerberos) antes que tu clave por defecto, y si no estás en un dominio Kerberos — que es la mayoría de la gente — falla y lo registra a nivel debug, luego recurre a la auth por clave y conecta sin problema. Si la conexión acaba teniendo éxito, esta línea es inofensiva; ignórala. Solo importa si de verdad dependes del SSO de Kerberos y la auth está fallando, en cuyo caso es un problema real de ticket/dominio (revisa klist, el desfase de reloj y el SPN del host en DNS). Para callar el ruido en una configuración sin Kerberos, añade GSSAPIAuthentication no a tu config.
Haz que las soluciones se queden
La mitad de estos son arreglos de una sola vez; la otra mitad merece una línea en ~/.ssh/config para que no vuelvan nunca — keepalives, IdentitiesOnly, puertos e identidades por host. La configuración le gana a la memoria.
La otra cosa que le gana a la memoria es un cliente que guarda el estado por ti. Termalin guarda los ajustes por host — puerto, usuario, clave, keepalives — con el propio host, verifica los servidores en la primera conexión y avisa a voces cuando cambia una huella, y su barra de estado muestra las constantes vitales de la máquina en vivo, así que «¿la máquina siquiera está encendida?» deja de ser un paso del diagnóstico. El plan Free no tiene límite de hosts — agárralo y jubila unos cuantos de estos errores para siempre.