Conexión a un servidor mediante SSH¶

En este artículo

• Conexión a un servidor vía SSH desde Linux
• Conexión a un servidor vía SSH desde Windows
• Resolución de problemas de conexión SSH

Conexión a un servidor vía SSH desde Linux¶

Para conectarse a su servidor vía SSH desde Linux, siga estos pasos:

1. Compruebe la dirección IP del servidor. Asegúrese de conocer la dirección IP del servidor. Si no la conoce, puede encontrarla en el Invapi Control Panel.

2. Instale un cliente SSH (si es necesario). Normalmente, un cliente SSH ya está instalado por defecto en la mayoría de las distribuciones Linux. Para comprobarlo, abra una terminal y ejecute el comando:

   ssh --version
   

   Si el cliente está instalado, verá la versión del programa.

   Si el cliente SSH no está instalado, instálelo utilizando el gestor de paquetes de su distribución:

   • Para Ubuntu/Debian:

     sudo apt update
     sudo apt install openssh-client
     

   • Para CentOS/RHEL:

     sudo yum install openssh-clients
     

3. Conéctese al servidor. Abra una terminal e introduzca el siguiente comando:

   ssh <username>@<server IP address>
   

   Por ejemplo:

   ssh [email protected]
   

4. Introduzca su contraseña. Tras la conexión, el sistema le pedirá que introduzca la contraseña para el usuario especificado. El login y la contraseña del servidor se le envían por correo electrónico cuando se realiza la entrega.

Conexión a un servidor vía SSH desde Windows¶

1. Compruebe la dirección IP del servidor. Asegúrese de conocer la dirección IP del servidor. Si no la conoce, puede encontrarla en el Invapi Control Panel en el sitio web de HOSTKEY.com en https://invapi.hostkey.com.

2. En Windows 11, existen varias formas de conectarse a un servidor vía SSH:

Uso de OpenSSH (aplicación integrada)¶

• A partir de la actualización de octubre de 2018 de Windows 10, el cliente SSH se incluye de forma predeterminada. Para comprobarlo, ejecute PowerShell y ejecute:

  ssh
  

  Si el cliente está instalado, verá las opciones de salida para su uso.

• Si el cliente SSH no está instalado, habilítelo a través de Settings:

  1. Vaya a **Settings** > **System** > **Additional components**.
  
  2. Busque `OpenSSH Client` e instálelo.
  

• Conéctese al servidor. Abra PowerShell e introduzca el siguiente comando:

  ssh <username>@<server IP address>
  

  Por ejemplo:

  ssh root@192.168.0.100
  

• Introduzca su contraseña. Tras la conexión, el sistema le pedirá que introduzca la contraseña para el usuario especificado. El login y la contraseña del servidor se le envían por correo electrónico cuando se realiza la entrega.

Uso de PuTTY (cliente alternativo):¶

• Descargue PuTTY desde el sitio web oficial https://www.putty.org.

• Inicie PuTTY e introduzca la dirección IP del servidor en el campo "Host Name (or IP address)".

• Especifique el tipo de conexión como SSH y haga clic en Open.

• Conéctese al servidor:

  • Introduzca la dirección IP del servidor en el campo Host Name (or IP address).

  • Especifique el puerto 22 para SSH si ha sido cambiado.

  • Haga clic en Open. En la ventana que se abra, introduzca su nombre de usuario y contraseña.

• Introduzca su contraseña. Tras la conexión, el sistema le pedirá que introduzca la contraseña para el usuario especificado. El login y la contraseña del servidor se le envían por correo electrónico cuando se realiza la entrega.

Resolución de problemas de conexión SSH¶

Al realizar este diagnóstico, podrá determinar dónde se pierde la conexión SSH: en su lado, en el servidor (sshd, firewall, configuración) o en el lado de su proveedor. Realice los pasos en orden y guarde la salida de los comandos; se la requerirá al soporte técnico.

Paso 1. Comprobación desde su ordenador¶

El objetivo es determinar si el servidor es alcanzable y si el puerto 22 responde. Estos comandos se ejecutan en el ordenador desde el que se está conectando.

1. Disponibilidad de red del servidor

   ping -c 4 SERVER_IP
   

   La falta de respuesta no significa necesariamente un error: el protocolo ICMP suele estar bloqueado por un firewall. La comprobación principal es el siguiente paso.

2. ¿Responde el puerto 22?

   nc -vz -w 5 SERVER_IP 22
   
   # si nc no está instalado:
   timeout 5 bash -c '</dev/tcp/SERVER_IP/22' && echo OPEN || echo CLOSED
   

   Resultado	Significado
   succeeded / open	El puerto está abierto, la red funciona bien; el problema es la autenticación o la configuración de sshd (Paso 4)
   Connection refused	El servidor es alcanzable, pero nada está escuchando en el puerto 22 o el firewall está enviando un REJECT (Pasos 2–3)
   timed out	Se están perdiendo paquetes: firewall DROP, filtro del proveedor o un bloqueo en la ruta (Pasos 3 y 5)
   No route to host	No hay ruta al servidor o el servidor está apagado (compruebe su estado en el panel)

3. Comprobación precisa mediante nmap

   Muestra el estado del puerto y qué se está ejecutando en él. Instalación: sudo apt install nmap o sudo dnf install nmap.

   # estado del puerto 22 y versión del servidor SSH
   sudo nmap -Pn -sV -p 22 SERVER_IP
   
   # con motivo del estado y ruta al servidor
   sudo nmap -Pn -p 22 --reason --traceroute SERVER_IP
   
   # comparar el 22 con otros puertos (¿filtra solo el 22 o todo?)
   sudo nmap -Pn -p 22,80,443,2222 --reason SERVER_IP
   
   # algoritmos SSH – si el script se ejecuta, el intercambio de claves está funcionando
   nmap -Pn -p 22 --script ssh2-enum-algos SERVER_IP
   

   Se requiere -Pn para que nmap no asuma que el servidor está caído si el ping está bloqueado.

   Estado de nmap	Significado
   open (reason syn-ack)	El puerto está abierto, sshd está respondiendo; -sV debería mostrar una versión de OpenSSH
   closed (reason reset)	El servidor es alcanzable, pero sshd no está escuchando en el puerto (Paso 2)
   filtered (reason no-response)	Se están perdiendo paquetes: firewall DROP o un bloqueo en la ruta (Pasos 3 y 5)
   filtered (reason admin-prohibited)	El firewall responde con un rechazo: regla REJECT en el servidor o en el proveedor (Paso 3)
   open, pero -sV no muestra versión o tcpwrapped	La conexión TCP pasa, pero no se recibe el banner SSH: TCP Wrappers, fail2ban o DPI (Pasos 4–5)

   Si las respuestas de --traceroute se cortan en los nodos de su proveedor mientras que el 80/443 permanecen abiertos, es una señal clara de filtrado específicamente en el puerto 22. Guarde la salida para el soporte: añada -oN nmap.txt al comando.

4. Log detallado de la conexión

   Muestra en qué etapa se corta la conexión:

   ssh -vvv -o ConnectTimeout=10 user@SERVER_IP 2>&1 | tee ssh_debug.log
   

   • Se queda colgado en Connecting to — problema de red.
   • Desconexión tras Connection established (por ejemplo, en SSH2_MSG_KEXINIT o Connection reset by peer) — señal típica de filtrado por DPI o fail2ban.
   • Permission denied — la red funciona bien, pero la clave o la contraseña son incorrectas.

5. Ruta al servidor específicamente a través del puerto TCP 22

   sudo traceroute -T -p 22 SERVER_IP
   
   # o un resumen de la pérdida de paquetes:
   sudo mtr -T -P 22 -r -c 50 SERVER_IP > mtr.txt
   

   Observe en qué nodo dejan de llegar las respuestas. Una desconexión dentro de la red de su proveedor indica un filtrado a lo largo de la ruta en lugar de un problema con el servidor.

6. Descartar su propia red

   Repita el Paso 2 utilizando un punto de acceso móvil y compruebe si el puerto 22 de salida está bloqueado en su firewall laboral/corporativo.

Paso 2. ¿Está ejecutándose el servidor SSH?¶

Se realiza en el servidor (a través de la consola web de hosting). En Debian/Ubuntu, el servicio se llama ssh; en CentOS/RHEL/Alma/Rocky, es sshd.

1. Estado del servicio

   systemctl status ssh || systemctl status sshd
   

   Debería aparecer como active (running). Si está como inactive o failed, inicie el servicio y habilítelo para que se inicie al arrancar:

   sudo systemctl enable --now ssh   # o sshd
   

   Si el servicio no arranca, el motivo aparecerá en los logs.

2. Paquete no instalado

   Error Unit ssh.service could not be found:

   sudo apt install openssh-server   # Debian/Ubuntu
   sudo dnf install openssh-server   # CentOS/RHEL/Alma/Rocky
   

3. ¿En qué puerto y dirección está escuchando sshd?

   sudo ss -tlnp | grep -E 'sshd|:22'
   

   Salida	Significado
   0.0.0.0:22 o [::]:22	Todo está bien; escuchando en todas las interfaces
   127.0.0.1:22	Escuchando solo localmente — corrija ListenAddress (Paso 4)
   Otro puerto, ej. :2222	Conéctese usando ese puerto: ssh -p 2222 user@SERVER_IP
   Vacío	sshd no se está ejecutando o no pudo vincularse al puerto — vea los logs anteriores

4. Ubuntu 22.10+ y activación de socket

   En estas versiones, el puerto se define en ssh.socket además de en sshd_config. Para comprobarlo:

   systemctl status ssh.socket
   

   Después de cambiar el puerto, ejecute:

   sudo systemctl daemon-reload && sudo systemctl restart ssh.socket
   

5. Prueba desde el propio servidor

   ssh -v localhost
   

   Si funciona localmente pero no desde el exterior, el problema reside en el firewall o en la red (Pasos 3 y 5).

Paso 3. Firewall del servidor¶

Normalmente, se está ejecutando uno de estos tres firewalls en el servidor: ufw (Ubuntu), firewalld (CentOS/RHEL) o iptables/nftables puro. Compruebe los tres; a veces hay dos activos simultáneamente.

ufw

sudo ufw status verbose

# si 22/tcp no está en la lista ALLOW:
sudo ufw allow 22/tcp

firewalld

sudo firewall-cmd --state
sudo firewall-cmd --list-all

# si ssh no está en services:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

iptables / nftables

sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

Busque reglas con dpt:22 o tcp dport 22 y la acción DROP / REJECT, así como una policy DROP sin una regla de permiso para el puerto 22. Preste atención a las reglas que restringen el acceso por origen (-s) o por país (usando módulos geoip o listas ipset): debido a estas, es posible que el servidor sea accesible desde todas partes excepto desde su país.

Para permitir SSH temporalmente al principio de la cadena (hasta el reinicio):

sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

Si la conexión funciona tras esto, se ha encontrado la causa; guarde la regla a través de su firewall (ufw/firewalld) o usando iptables-save.

Paso 4. Configuración de sshd y herramientas de seguridad¶

Si el puerto está abierto pero la conexión se corta o la autenticación falla, compruebe su configuración y cualquier bloqueo.

1. Configuración final de sshd

   Teniendo en cuenta los archivos en sshd_config.d/:

   sudo sshd -T | grep -Ei '^(port|listenaddress|permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups|denyusers|maxstartups)'
   

   Compruebe:

   • port 22;
   • listenaddress 0.0.0.0 (no 127.0.0.1);
   • que su usuario esté en allowusers, si ese parámetro está configurado;
   • permitrootlogin y passwordauthentication — asegúrese de que estén configurados con los valores que requiere.

2. Comprobación de sintaxis antes de reiniciar

   Después de cualquier modificación en /etc/ssh/sshd_config, compruebe siempre la sintaxis antes de reiniciar:

   sudo sshd -t && sudo systemctl restart ssh   # o sshd
   

3. fail2ban

   Podría haber bloqueado su IP tras intentos fallidos de inicio de sesión:

   sudo fail2ban-client status sshd
   
   # para desbloquear su IP:
   sudo fail2ban-client set sshd unbanip YOUR_IP
   

   Puede encontrar su IP externa desde su máquina cliente usando el comando curl -4 ifconfig.me. Del mismo modo, compruebe CrowdSec o sshguard si están instalados.

4. TCP Wrappers (en sistemas antiguos)

   cat /etc/hosts.allow /etc/hosts.deny 2>/dev/null
   

   Una línea como sshd: ALL en hosts.deny bloquea a todos los que no estén especificados en hosts.allow.

5. Lo que el servidor ve durante su intento de conexión

   Ejecute esto en el servidor y luego intente conectarse desde el cliente:

   sudo journalctl -u ssh -u sshd -f
   
   # en una segunda ventana – compruebe si los paquetes llegan al servidor:
   sudo tcpdump -ni any tcp port 22 and host YOUR_IP
   

   • Si tcpdump no muestra nada, los paquetes no están llegando al servidor; el problema está en la ruta de red (Paso 5).
   • Si los paquetes llegan pero el log de sshd está vacío, están siendo descartados por el firewall del servidor (Paso 3).

Paso 5. Indisponibilidad específicamente desde su país¶

Si todo está bien en el servidor (Pasos 2–4) pero los paquetes de su país no llegan, debe comparar la disponibilidad del puerto desde su país frente a otros países.

1. Compruebe el puerto desde ubicaciones externas

   Use el servicio check-host.net → pestaña TCP port, introduzca SERVER_IP:22. Compruebe los resultados para su país y nodos internacionales.

   Desde su país	Desde otros países	Conclusión
   Falla	Funciona	Filtrado de enrutamiento desde su país o geobloqueo en el lado del servidor/host
   Falla	Falla	Problema en el servidor — vuelva a los Pasos 2–4
   Funciona	Funciona	Problema con su ISP o red local

2. Compare proveedores dentro de su país

   La internet doméstica y los operadores móviles suelen comportarse de forma distinta. Si funciona a través de uno pero no a través del otro, el bloqueo está en el lado del proveedor específico.

3. Compruebe si es específicamente el puerto 22 el afectado

   Añada temporalmente un segundo puerto a /etc/ssh/sshd_config en el servidor (la línea original Port 22 permanece):

   Port 22
   Port 2222
   

   Permita 2222/tcp en su firewall (Paso 3), luego ejecute:

   sudo sshd -t && sudo systemctl restart ssh
   

   Y conéctese:

   ssh -p 2222 user@SERVER_IP
   

   En sistemas con SELinux (CentOS/RHEL), realice este paso adicional:

   sudo semanage port -a -t ssh_port_t -p tcp 2222
   

   Si funciona en el 2222 pero no en el 22, el puerto estándar está siendo filtrado.

4. Señales de filtrado por DPI

   La conexión TCP se establece (nc muestra que está abierto), pero ssh -vvv termina durante el intercambio de claves; o la conexión funciona durante unos segundos y luego se queda colgada. En este caso, la configuración del servidor no es la causa; por favor, envíe los logs al soporte.

Qué incluir en su mensaje de soporte¶

Si el problema no se resuelve, envíenos lo siguiente; esto reducirá el tiempo de diagnóstico:

• IP del servidor y su IP pública (curl -4 ifconfig.me), ciudad e ISP;
• archivo nmap.txt y el resultado de nc -vz -w 5 SERVER_IP 22;
• archivo ssh_debug.log (Paso 1, ítem 4);
• archivo mtr.txt o la salida de traceroute -T -p 22;
• Salida del servidor: systemctl status ssh, ss -tlnp | grep :22, y reglas del firewall (ufw status verbose / firewall-cmd --list-all / iptables -L INPUT -n -v);
• Un enlace al resultado de la comprobación del puerto TCP de check-host.net;
• Si la conexión funciona mediante internet móvil y en el puerto 2222 (si lo ha probado).