Primero mira en qué caso estás:

Si la autenticación falla nada más conectar, consulta: VPS SSH Permission denied: qué hacer.

Si no puedes conectarte en absoluto tras activar el cortafuegos, consulta: VPS SSH inaccesible tras activar UFW: qué hacer.

El resto del artículo trata principalmente el caso de "conecta pero se corta a mitad de sesión".

El caso más común: dejas la ventana SSH inactiva unos minutos, vuelves, pulsas una tecla y se corta.

Normalmente esto ocurre porque un dispositivo de red intermedio considera la conexión inactiva y recicla la sesión TCP. Los routers domésticos, las pasarelas de empresa, el NAT del operador y los puntos de acceso móvil pueden hacerlo.

Primero añade esto a la configuración SSH de tu ordenador local:

mkdir -p ~/.ssh
nano ~/.ssh/config

Escribe:

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3

El significado es simple: el cliente envía un paquete keepalive al servidor cada 30 segundos; solo tras 3 respuestas ausentes consecutivas considera que la conexión está muerta.

Guarda y vuelve a conectar:

ssh root@your_server_ip

Si usas un puerto personalizado:

ssh -p 2222 root@your_server_ip

Si tu síntoma anterior era "se corta tras estar inactivo un rato", este paso por sí solo suele mejorar notablemente la situación.

Si no quieres cambiar la configuración primero, puedes añadir parámetros temporalmente para probar:

ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 root@your_server_ip

Si así la conexión es estable, entonces escríbelo en ~/.ssh/config.

También puedes hacer que se aplique solo a un VPS:

Host my-vps
    HostName your_server_ip
    User root
    Port 22
    ServerAliveInterval 30
    ServerAliveCountMax 3

Conecta después con:

ssh my-vps

Esto es menos engorroso que escribir los parámetros cada vez y menos fácil de olvidar.

Cuando el keepalive del cliente no basta, revisa la configuración del lado del servidor del VPS.

Abre la configuración de sshd:

sudo nano /etc/ssh/sshd_config

Confirma o añade:

ClientAliveInterval 60
ClientAliveCountMax 3
TCPKeepAlive yes

Luego prueba primero si la configuración tiene errores de sintaxis:

sudo sshd -t

Sin salida normalmente significa que está bien. Después recarga SSH:

sudo systemctl reload ssh

En algunos sistemas el servicio se llama sshd:

sudo systemctl reload sshd

No reinicies la máquina de inmediato. Primero sshd -t, luego reload. Una configuración de sshd incorrecta puede dejarte fuera, sobre todo si no tienes consola.

Si la desconexión no se debe a inactividad, los registros del servidor darán pistas.

Ubuntu / Debian:

sudo journalctl -u ssh --since "1 hour ago"
sudo tail -n 100 /var/log/auth.log

CentOS / Rocky / AlmaLinux:

sudo journalctl -u sshd --since "1 hour ago"
sudo tail -n 100 /var/log/secure

Fíjate en estas palabras clave:

sudo journalctl -u ssh --since "1 hour ago" | grep -Ei "disconnect|reset|timeout|error|kex|fatal|oom"

Si en los registros puedes ver Received disconnect, significa que el servidor sabe que la conexión se cortó.

Si en los registros no hay ningún registro correspondiente, pero el cliente recibe directamente Broken pipe, es más probable que se haya roto la red intermedia o que el enlace local sea inestable.

La información de depuración del cliente es muy útil:

ssh -vvv root@your_server_ip

Antes y después de la desconexión, fíjate en:

debug1: client_input_channel_req: channel 0 rtype [email protected]
packet_write_wait: Connection to x.x.x.x port 22: Broken pipe
Connection reset by peer

Si antes de la desconexión el keepalive recibe repetidamente ninguna respuesta, significa que el cliente envía paquetes pero no recibe respuesta del servidor. En ese momento no te apresures a cambiar sshd; primero prueba la pérdida de paquetes de red.

En tu ordenador local, prueba:

ping your_server_ip

Observa durante 1-2 minutos para ver si hay pérdida de paquetes o un aumento repentino de la latencia.

Se recomienda más usar mtr:

mtr -rw your_server_ip

Si no tienes mtr localmente, en macOS puedes instalarlo con Homebrew y en Linux con el gestor de paquetes:

sudo apt install mtr-tiny

Al leer los resultados, no te fijes solo en el último salto. La pérdida de paquetes en un salto intermedio no indica necesariamente un problema; lo clave es si los últimos saltos tienen pérdida de paquetes sostenida y si la latencia sube de forma regular.

Si solo se corta por la noche y casi nunca de día, puedes leer también: Por qué el VPS se pone lento en hora punta nocturna. A veces la desconexión del SSH no es un problema de configuración sino fluctuación de la ruta en hora punta nocturna.

Si el VPS tiene mucha presión de CPU, memoria o E/S de disco, las sesiones SSH también pueden atascarse o incluso cortarse. Especialmente en máquinas de bajas prestaciones que ejecutan Docker, bases de datos, compresión de copias de seguridad o escritura de registros.

Tras iniciar sesión, ejecuta:

uptime
free -h
df -h

Ver procesos en tiempo real:

top

Si tienes htop es más intuitivo:

sudo apt install htop
htop

Comprueba si el sistema tiene OOM o errores de disco:

dmesg -T | grep -Ei "oom|killed process|i/o error|reset|ext4|nvme"

Si la máquina ya estaba claramente lenta antes de que el SSH se cortara, y la entrada de comandos también tenía retardo, el problema puede no ser SSH sino el propio VPS con demasiada presión.

Si cada desconexión ocurre a una hora fija, por ejemplo cada día al amanecer, puede deberse a recargas del servicio, actualizaciones automáticas, tareas del panel o rotación de registros.

Mira el estado reciente del servicio ssh:

sudo systemctl status ssh
sudo journalctl -u ssh --since "24 hours ago"

En sistemas de la familia CentOS:

sudo systemctl status sshd
sudo journalctl -u sshd --since "24 hours ago"

Si ves que sshd se reinicia con frecuencia, sigue investigando qué lo provoca:

sudo journalctl --since "24 hours ago" | grep -Ei "ssh|sshd|restart|reload|apt|dnf|yum|unattended"

Las actualizaciones automáticas en general no deberían cortar el SSH con frecuencia, pero si las actualizaciones de paquetes del sistema, las herramientas de gestión de configuración o los paneles están modificando sshd, hay que tener cuidado.

Aunque arregles el keepalive, no se recomienda ejecutar tareas largas directamente en una sesión SSH en pelado. La red siempre fluctúa.

Instala tmux:

sudo apt update
sudo apt install tmux

Crea una sesión nueva:

tmux new -s work

Ejecuta tareas dentro. Sal temporalmente sin terminar la tarea:

Ctrl+b 然后按 d

Vuelve la próxima vez:

tmux attach -t work

Si vas a ejecutar compilaciones, copias de seguridad, migraciones o importaciones de bases de datos, tmux es mucho más fiable que rezar para que el SSH no se corte.

Si usas a menudo puntos de acceso móvil, redes de aeropuerto o enlaces transfronterizos, SSH no es amigable con el cambio de IP y las redes débiles. mosh resiste mejor la fluctuación.

Instalación en el servidor:

sudo apt install mosh

Instala mosh también localmente y luego conecta:

mosh root@your_server_ip

Nota: mosh necesita puertos UDP, y el rango predeterminado suele ser 60000-61000/udp. Si activaste UFW o un cortafuegos cloud, debes permitirlos:

sudo ufw allow 60000:61000/udp

Si solo administras VPS de forma normal, configurar el keepalive de SSH y tmux es suficiente; mosh es más adecuado para redes débiles y escenarios móviles.

~/.ssh/config local:

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3
    TCPKeepAlive yes

/etc/ssh/sshd_config del servidor:

ClientAliveInterval 60
ClientAliveCountMax 3
TCPKeepAlive yes

Tras cambiar el lado del servidor, recuerda:

sudo sshd -t
sudo systemctl reload ssh

Si el nombre del servicio no es correcto, usa entonces:

sudo systemctl reload sshd

Un método de juicio sencillo:

• Solo se corta el SSH; el sitio web, ping y mtr van bien: mira primero keepalive y sshd
• SSH, sitio web y conexiones de base de datos fluctúan juntos: mira primero la carga del VPS o la ruta de red
• Solo se corta en un entorno de red concreto: mira primero la red local, la pasarela de la empresa o el punto de acceso móvil
• Solo se corta en hora punta nocturna: mira primero la congestión del enlace y la pérdida de paquetes
• No conecta nunca: mira primero el cortafuegos, el grupo de seguridad, el puerto y la autenticación

SSH es solo el primer lugar donde se manifiesta el problema; no necesariamente es la causa raíz real.

• ¿VPS inaccesible? Solución al fallo de inicio de sesión SSH: si ahora no puedes conectarte en absoluto, empieza por el puerto y el cortafuegos.
• VPS SSH Permission denied: qué hacer: si es un fallo de autenticación, fíjate en claves, usuarios y permisos.
• VPS SSH inaccesible tras activar UFW: qué hacer: si el SSH se cortó justo después de activar el cortafuegos, trata primero UFW.
• Por qué el VPS se pone lento en hora punta nocturna: si las desconexiones SSH tienen una franja horaria clara, diagnostica la ruta de red y los recursos del host.

Por último, una sugerencia práctica: siempre que inicies sesión en VPS con frecuencia, configura ServerAliveInterval y tmux. El primero reduce las desconexiones por inactividad; el segundo garantiza que las tareas sigan ahí tras la desconexión. La conexión SSH puede cortarse; las tareas no deben cortarse con ella.