Solucionar error Connection refused en SSH Linux

¡Hola! Soy tu asistente técnico de confianza. ¿Estás intentando conectarte a tu servidor Linux por SSH y te encuentras con el temido error connection refused ssh? No te preocupes, es un problema muy común, especialmente en servidores nuevos o después de una actualización. En esta guía completa, te explicaré paso a paso cómo diagnosticar y solucionar el error ssh connection refused solucion para que puedas retomar el control de tu máquina. Vamos a desglosar las causas más frecuentes y las soluciones prácticas, desde las más simples hasta las más avanzadas. Al final, tendrás un checklist que te ayudará a resolver este linux ssh error en cuestión de minutos.

¿Qué significa el error "Connection refused" en SSH?

Cuando ves el mensaje ssh: connect to host [IP] port 22: Connection refused, tu cliente SSH está intentando establecer una conexión con el servidor en el puerto 22 (el puerto por defecto para SSH), pero el servidor está rechazando activamente la conexión. Esto no es un problema de red (como un timeout), sino que el servicio SSH en el servidor no está escuchando en ese puerto, no está funcionando, o un firewall lo está bloqueando.

Causas principales:

El servicio SSH (sshd) no está instalado o no se está ejecutando.
El puerto 22 está bloqueado por un firewall (iptables, ufw, firewalld, o el firewall de tu proveedor de nube).
El demonio SSH está configurado para escuchar en un puerto diferente (por ejemplo, 2222 o 2106 si usas Syspanel).
La IP desde la que te conectas no está permitida en el archivo de configuración /etc/ssh/sshd_config.
Problemas con la interfaz de red (la IP del servidor ha cambiado o el servicio no está vinculado a la IP correcta).
El servidor está sobrecargado o se ha quedado sin recursos (memoria, procesos).

Paso 1: Verifica que el servicio SSH esté activo

Lo primero es comprobar si el demonio SSH (sshd) está funcionando. Si tienes acceso al panel de control de tu servidor (como un VPS o un servidor dedicado), usa la consola web (KVM, VNC, o el panel de tu proveedor). Si no, pide ayuda a tu proveedor de hosting.

Conéctate a la consola del servidor (acceso directo)

Accede a tu servidor mediante la consola web que te proporciona tu hosting (por ejemplo, en DigitalOcean, Linode, o AWS). Una vez dentro, ejecuta:

systemctl status sshd

O en distribuciones más antiguas (SysV init):

service sshd status

Resultados posibles:

Active: running → El servicio está funcionando. El problema probablemente es de firewall o configuración.
Inactive (dead) → El servicio no se está ejecutando. Inícialo con:
```
systemctl start sshd
```
Y habilítalo para que arranque automáticamente:
```
systemctl enable sshd
```
Failed → Hay un error en la configuración. Revisa los logs con:
```
journalctl -u sshd -n 50
```
Busca líneas como fatal: Cannot bind any address o error: Bind to port 22 on 0.0.0.0 failed: Permission denied.

[TIP] Si usas Syspanel (HestiaCP), el panel suele gestionar su propio servicio SSH. Asegúrate de que el puerto 2106 esté abierto, ya que es el puerto de acceso a Syspanel. Para SSH normal, el puerto suele seguir siendo el 22, pero verifica en la configuración.

Paso 2: Revisa el firewall del servidor

Un firewall mal configurado es la causa más común del error connection refused ssh. Incluso si el servicio SSH está funcionando, si el firewall bloquea el puerto 22, la conexión será rechazada.

2.1. Firewall a nivel de sistema operativo

Dependiendo de tu distribución, usa uno de estos comandos:

En Ubuntu/Debian (ufw):

sudo ufw status

Si ves Status: active y no aparece 22/tcp o OpenSSH en la lista de reglas, agrega SSH:

sudo ufw allow 22/tcp
sudo ufw reload

En CentOS/RHEL/Fedora (firewalld):

sudo firewall-cmd --list-all

Si no ves ssh o 22/tcp en la lista de servicios, agrégalo:

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

En sistemas con iptables (más antiguos):

sudo iptables -L -n -v | grep :22

Si no hay reglas que permitan el puerto 22, necesitas agregarlas. Un ejemplo básico:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save > /etc/iptables/rules.v4

2.2. Firewall externo (proveedor de nube)

Muchos proveedores (AWS, Google Cloud, Azure, DigitalOcean) tienen firewalls externos (Security Groups, firewalls de red). Revisa que el puerto 22 esté abierto para tu IP o para todas las IPs (0.0.0.0/0) si es necesario. Si lo bloqueaste por error, desde el panel de control de tu proveedor, agrega una regla de entrada para TCP en el puerto 22.

[WARNING] No abras el puerto 22 a todo el mundo (0.0.0.0/0) a menos que sea estrictamente necesario. Es mejor limitarlo a tu IP pública o a un rango de confianza. Si no sabes tu IP, visita https://whatismyip.com.

Paso 3: Verifica la configuración de SSH (sshd_config)

El archivo de configuración del demonio SSH (/etc/ssh/sshd_config) puede estar forzando un puerto diferente o restringiendo las conexiones.

3.1. Comprueba el puerto

Abre el archivo con un editor (nano, vim):

sudo nano /etc/ssh/sshd_config

Busca la línea Port. Por defecto está comentada (con #) y usa el puerto 22. Si está descomentada y tiene otro número (por ejemplo, Port 2222), entonces debes conectarte usando ese puerto:

ssh usuario@IP -p 2222

[INFO] Si usas Syspanel, el puerto de acceso al panel es el 2106, pero el SSH normalmente sigue en el 22. Sin embargo, algunos administradores cambian el puerto SSH por seguridad. Revisa bien este archivo.

3.2. Revisa las restricciones de IP

Busca las directivas AllowUsers, DenyUsers, AllowGroups, DenyGroups. Si están configuradas, asegúrate de que tu usuario o grupo esté incluido. Por ejemplo:

AllowUsers admin usuario1

Si no apareces, la conexión será rechazada.

3.3. Verifica la interfaz de escucha

La línea ListenAddress puede estar forzando a SSH a escuchar solo en una IP específica. Si está configurada para una IP que no es la pública del servidor, no podrás conectarte. Comenta la línea o cámbiala a 0.0.0.0 (todas las interfaces).

Después de cualquier cambio, reinicia el servicio:

sudo systemctl restart sshd

Paso 4: Comprueba la conectividad de red

A veces el problema no es el servidor, sino tu red local o un bloqueo intermedio.

4.1. Prueba desde otro dispositivo o red

Intenta conectarte desde tu móvil (usando una app como Termux) o desde una red diferente (por ejemplo, desde el trabajo o usando datos móviles). Si funciona, el problema está en tu router o firewall local.

4.2. Usa telnet para probar el puerto

Desde tu máquina local, ejecuta:

telnet IP_DEL_SERVIDOR 22

Si ves algo como Trying... Connected to IP, el puerto está abierto y el problema es de configuración del cliente SSH.
Si ves Connection refused, el problema está en el servidor (servicio caído o firewall).
Si ves Connection timed out, hay un bloqueo de red intermedio (firewall de tu ISP, router, etc.).

[TIP] Si no tienes telnet instalado, usa nc -zv IP 22 (netcat).

Paso 5: Soluciones avanzadas (cuando nada funciona)

Si has seguido todos los pasos y sigues con el linux ssh error, prueba estas opciones:

5.1. Reinstala el servicio SSH

En la consola del servidor:

# En Debian/Ubuntu
sudo apt remove --purge openssh-server
sudo apt install openssh-server

# En CentOS/RHEL
sudo yum remove openssh-server
sudo yum install openssh-server

Luego, configura de nuevo el archivo sshd_config y reinicia.

5.2. Comprueba los logs del sistema

Los logs pueden darte pistas precisas:

sudo tail -100 /var/log/auth.log   # Debian/Ubuntu
sudo tail -100 /var/log/secure     # CentOS/RHEL

Busca líneas como Failed password, Connection refused, o error: Could not load host key.

5.3. Desactiva temporalmente SELinux (CentOS/RHEL)

SELinux puede bloquear SSH incluso si el firewall está abierto. Para probar:

sudo setenforce 0

Si el SSH funciona, entonces SELinux está causando el problema. Vuelve a activarlo con setenforce 1 y luego ajusta las políticas.

5.4. Usa SSH con depuración

Desde tu cliente, ejecuta con verbosidad máxima:

ssh -vvv usuario@IP

Esto mostrará cada paso de la negociación. Busca mensajes como Connection refused o No route to host.

FAQ: Preguntas frecuentes sobre el error "Connection refused"

❓ ¿Por qué recibo "Connection refused" después de instalar Syspanel?

Respuesta: Syspanel (HestiaCP) puede cambiar el puerto SSH por defecto o deshabilitar el acceso root. Revisa el archivo /etc/ssh/sshd_config y busca Port. Además, asegúrate de que el puerto 2106 (para el panel) esté abierto, pero el SSH puede estar en otro puerto. Conéctate con ssh -p [puerto] usuario@IP.

❓ ¿Es seguro abrir el puerto 22 en el firewall?

Respuesta: Sí, siempre que limites el acceso a tu IP o a una VPN. No lo dejes abierto a 0.0.0.0/0 a menos que sea un servidor público y uses claves SSH seguras.

❓ ¿Puedo cambiar el puerto SSH para evitar ataques?

Respuesta: Sí, es una práctica común. Edita sshd_config, cambia Port a un número alto (ej. 2222), reinicia el servicio y actualiza tu firewall. Luego conéctate con -p 2222.

❓ ¿Qué hago si no tengo acceso a la consola del servidor?

Respuesta: Contacta a tu proveedor de hosting. La mayoría ofrece acceso por consola web (KVM, VNC) o un panel de rescate. Si no, pide que reinicien el servicio SSH o te den acceso root temporal.

❓ ¿El error puede deberse a que la IP está en una lista negra?

Respuesta: Sí, algunos servidores usan Fail2ban o DenyHosts que bloquean IPs tras varios intentos fallidos. Si tienes acceso, revisa /etc/hosts.deny o los logs de Fail2ban (sudo fail2ban-client status sshd).

Conclusión: Checklist para solucionar el error

Aquí tienes un resumen rápido para que no te pierdas:

Verifica el servicio SSH: systemctl status sshd → Si está caído, inícialo.
Revisa el firewall local: ufw status, firewall-cmd --list-all, o iptables -L.
Revisa el firewall del proveedor de nube: Security Groups, firewalls de red.
Comprueba la configuración de SSH: Puerto, AllowUsers, ListenAddress.
Prueba conectividad: telnet IP 22 y ssh -vvv.
Reinstala SSH si es necesario.
Revisa logs: /var/log/auth.log o /var/log/secure.

Con estos pasos, resolverás el error connection refused ssh en el 99% de los casos. Recuerda que la paciencia y la revisión metódica son tus mejores aliados. Si aún tienes dudas, deja un comentario o contacta a tu proveedor de hosting. ¡Buena suerte y feliz conexión!