- Diagnóstico sistemático basado en la lectura precisa de los mensajes de error del cliente SSH.
- Verificación integral de la capa de red, reglas de firewall y estado del demonio sshd.
- Gestión correcta de permisos de claves públicas y privadas para evitar denegaciones de acceso.
- Uso de herramientas de trazado como strace y logs del sistema para resolver cuellos de botella y bloqueos.
Tener un servidor Linux es una maravilla hasta que, de repente, intentas conectar por SSH y te encuentras con un muro. Es una situación frustrante, sobre todo porque el propio error de acceso es lo que te impide entrar a arreglar el problema. Ya sea que estés gestionando un Droplet en la nube o un servidor multimedia en el salón de tu casa, saber moverse por los fallos de SSH es fundamental para no tirar la toalla y acabar reinstalando todo sin necesidad.
Para no dar palos de ciego, lo más inteligente es seguir un orden lógico de descarte. No sirve de nada pelearse con las claves de cifrado si el servidor está apagado o si un firewall te está bloqueando la entrada. Vamos a desgranar desde los fallos más tontos, como una errata en la IP, hasta cosas más rebuscadas como retrasos por DNS inverso o problemas de sockets en versiones modernas de Ubuntu.
Analizando el síntoma: ¿Qué nos dice el error?
Antes de tocar nada, hay que leer la última línea del error. Si ves un Connection timed out, lo más probable es que tus paquetes se estén perdiendo por el camino. Esto suele pasar porque la IP es incorrecta, el servidor ha muerto o hay un cortafuegos bloqueando el puerto. Si, por el contrario, recibes un Connection refused, el servidor sí responde, pero te dice que en ese puerto no hay nadie escuchando.
Para salir de dudas con la red, puedes usar el comando nc (netcat) para ver si el puerto TCP está abierto. Si el puerto responde pero el login falla, es momento de activar el modo verbose usando ssh -vvv. Esta opción es oro puro, ya que te muestra exactamente en qué fase se rompe el apretón de manos: si es durante el intercambio de claves, si el servidor rechaza tu llave pública o si hay demasiados intentos de autenticación fallidos.
Verificación del Servicio y el Puerto
Si tienes acceso mediante una consola web o física, lo primero es mirar si el demonio SSH (sshd) está vivo. En sistemas modernos usamos systemctl status ssh o sshd. Si ves que está inactivo, un simple systemctl start ssh debería bastar. Ojo con Ubuntu 24.04, que utiliza activación por sockets, por lo que debes revisar tanto el servicio como el ssh.socket.
Otro punto crítico es el puerto. Aunque el estándar es el 22, mucha gente lo cambia por seguridad. Puedes comprobar cuál está usando el servidor mirando el archivo /etc/ssh/sshd_config o ejecutando ss -tulpn | grep sshd. Si has cambiado el puerto y no funciona, recuerda que en algunas distros debes hacer un daemon-reload de systemd para que el socket reconozca el nuevo puerto.
El muro del Firewall y la Seguridad
Es muy común que el firewall esté haciendo su trabajo demasiado bien y te deje fuera. Si usas UFW, comprueba que el puerto esté permitido con ufw status. Si falta, añádelo rápidamente. También conviene echar un ojo a SELinux en distribuciones como Red Hat o CentOS, ya que sus políticas pueden bloquear conexiones SSH si no están configuradas correctamente.
Si todo parece estar bien pero el servidor te expulsa, puede que Fail2Ban te haya metido en la lista negra tras varios intentos fallidos. Verifica si tu IP pública está baneada revisando el jail de SSH y, si es así, libérala con el comando de unban correspondiente para recuperar el acceso.
Claves SSH y Permisos: El dolor de cabeza habitual
Cuando el error es Permission denied (publickey), el problema suele estar en las llaves o en los permisos de las carpetas. SSH es extremadamente quisquilloso con la seguridad: si tu carpeta .ssh o el archivo authorized_keys tienen permisos demasiado abiertos (que otros usuarios puedan escribir), SSH rechazará la conexión por seguridad.
La configuración ideal es dejar la carpeta .ssh con permisos 700 y el archivo de llaves autorizadas con 600. Además, asegúrate de que la clave pública esté correctamente pegada en el servidor en una sola línea, ya que a veces al copiar y pegar desde la consola se introducen saltos de línea que rompen la llave.
Técnicas Avanzadas: Solucionando lentitud y cuellos de botella
¿Te pasa que el login tarda siempre unos 10 segundos exactos? Esto suele ser un síntoma clásico de un problema de DNS inverso. El servidor intenta averiguar el nombre de dominio de tu IP y, si el servidor DNS no responde, se queda colgado hasta que salta el timeout. Puedes diagnosticar esto usando strace para rastrear las llamadas al sistema y ver dónde se pierde el tiempo.
Si ves que el proceso se detiene en una llamada poll hacia el puerto 53, ya tienes al culpable. La solución es corregir el archivo /etc/resolv.conf con un servidor DNS que funcione o desactivar la búsqueda de DNS en la configuración de SSH cambiando UseDNS no.
Para mantener el control total, es vital gestionar bien el archivo known_hosts. Si reinstalas el servidor, la huella digital cambiará y el cliente SSH te avisará de un posible ataque. No ignores esto desactivando el chequeo; lo correcto es borrar la entrada antigua con ssh-keygen -R IP_DEL_SERVIDOR y validar la nueva huella manualmente.
Dominar la resolución de problemas en SSH implica transitar desde la comprobación básica de conectividad y el estado del servicio, pasando por la auditoría de reglas de firewall y la corrección de permisos de archivos, hasta llegar al análisis de logs y trazas del sistema para optimizar el rendimiento y garantizar un acceso remoto seguro y fluido.