Solución de problemas de SSH — errores de conexión más comunes en Linux

Este artículo fue publicado originalmente en go2linux.org. El dominio ya no me pertenece, pero soy el autor original. Lo republico aquí en garron.me con correcciones y mejoras.

SSH es una de esas herramientas que funciona tan bien que solo la notas cuando falla. Cuando falla, los mensajes de error suelen ser crípticos. Esta guía cubre las causas más comunes y cómo resolverlas.

Paso 1: ejecutar SSH en modo verbose

Antes de cualquier otra cosa, ejecuta tu comando SSH con -vvv para ver exactamente dónde falla:

ssh -vvv usuario@servidor

La salida muestra el proceso de conexión paso a paso. Busca la primera línea que diga debug1: ... failed o Connection refused — ese es tu punto de partida.

Conexión rechazada

Si obtienes ssh: connect to host servidor port 22: Connection refused, el demonio SSH no está corriendo o está escuchando en un puerto diferente.

Verifica en el servidor:

sudo systemctl status sshd

Si no está corriendo, inícialo:

sudo systemctl start sshd
sudo systemctl enable sshd

Si sshd usa un puerto no estándar, conéctate con:

ssh -p 2222 usuario@servidor

Firewall bloqueando el puerto 22

Incluso con sshd corriendo, un firewall puede bloquear la conexión.

Con ufw (Ubuntu/Debian):

sudo ufw status

Permitir SSH:

sudo ufw allow ssh

Con firewalld (Fedora/RHEL/CentOS):

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Con iptables directo, verifica si el puerto 22 está bloqueado:

sudo iptables -L INPUT -n --line-numbers | grep 22

hosts.allow y hosts.deny

Una causa que se pasa por alto: TCP wrappers. Si /etc/hosts.deny contiene ALL: ALL, bloquea toda conexión entrante incluyendo SSH.

Revisa el archivo:

cat /etc/hosts.deny

Si ves ALL: ALL, comenta la línea o agrega un permiso explícito en /etc/hosts.allow:

sshd: ALL

Haz este cambio con cuidado — un /etc/hosts.deny mal configurado en un servidor remoto puede dejarte sin acceso permanentemente.

Permission denied (publickey)

Los fallos de autenticación por clave generalmente son un problema de permisos en el servidor. SSH rechaza silenciosamente las claves si el directorio .ssh o el archivo authorized_keys tiene permisos demasiado abiertos.

Corrige los permisos:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

También verifica que la clave pública fue copiada:

cat ~/.ssh/authorized_keys

Si está vacío, copia la clave desde el cliente:

ssh-copy-id usuario@servidor

Demasiados intentos de autenticación

Si tienes muchas claves en tu agente SSH, puede que SSH las pruebe todas y alcance el límite MaxAuthTries del servidor antes de llegar a la correcta.

Fuerza SSH a usar una clave específica:

ssh -i ~/.ssh/mi_clave usuario@servidor

O agrega esto a ~/.ssh/config:

Host miserv
    HostName servidor.ejemplo.com
    User usuario
    IdentityFile ~/.ssh/mi_clave
    IdentitiesOnly yes

IdentitiesOnly yes evita que SSH pruebe otras claves del agente.

Revisar los registros del servidor

Cuando todo lo demás falla, revisa los registros del demonio SSH en el servidor:

sudo journalctl -u sshd -n 50

O en sistemas más antiguos:

sudo tail -50 /var/log/auth.log

El registro del servidor generalmente explica la razón exacta por la que se rechazó una conexión o una clave fue denegada.