¿Por qué mi conexión SSH es lenta? Cinco soluciones inmediatas para problemas de latencia

SSH lento no es un solo problema. A veces la demora ocurre antes de que aparezca el prompt. A veces el inicio de sesión es rápido, pero cada pulsación de tecla se siente pegajosa. A veces se culpa a SSH por un script de inicio de shell lento, una búsqueda DNS bloqueada o una ruta de red que pierde paquetes entre su laptop y una región en la nube al otro lado del mundo.

Antes de cambiar configuraciones, ejecute una prueba simple:

time ssh -vvv [email protected] exit

La salida de time le indica si la conexión completa es lenta. La salida de -vvv le indica dónde está gastando tiempo el cliente. Busque intentos de clave repetidos, mensajes GSSAPI, pausas relacionadas con DNS o un espacio largo antes de que comience la autenticación. Si ssh usuario@host exit es rápido pero un inicio de sesión interactivo es lento, el problema probablemente está en los archivos de inicio del shell remoto, no en SSH en sí.

Hay tres patrones comunes:

1. Lento antes de la autenticación: Generalmente DNS, GSSAPI, búsqueda de clave de host o un backend de autenticación lento.
2. Lento después de la autenticación pero antes del prompt: Generalmente .bashrc, .profile, .zshrc, directorios home montados en red o plugins de shell.
3. Lento al escribir o usar herramientas de pantalla completa: Generalmente latencia real de red, pérdida de paquetes, endpoints sobrecargados, sobrecarga de compresión o renderizado de terminal.

Las correcciones a continuación están ordenadas por la frecuencia con que resuelven quejas reales de latencia en SSH.

1. Deshabilitar búsquedas DNS inversas en el servidor

DNS inverso es una causa clásica de inicios de sesión SSH lentos en redes internas. El servidor acepta su conexión TCP, luego intenta resolver la dirección IP del cliente conectado de vuelta a un nombre de host. Si el DNS inverso falta, está mal configurado o es manejado por un resolvedor lento, el inicio de sesión puede pausarse por varios segundos.

Esta es una configuración del lado del servidor. Agregue o actualice esta línea en /etc/ssh/sshd_config:

UseDNS no

Luego pruebe y recargue SSH:

sudo sshd -t
sudo systemctl reload sshd

Algunas distribuciones usan ssh como nombre del servicio:

sudo systemctl reload ssh

Mantenga su sesión actual abierta mientras prueba un nuevo inicio de sesión. Si el nuevo inicio de sesión es rápido, encontró la demora. Si nada cambia, deje la configuración en su lugar si coincide con su entorno, pero continúe solucionando problemas.

2. Deshabilitar GSSAPI cuando no use Kerberos

GSSAPI es útil en entornos respaldados por Kerberos. Fuera de esos entornos, puede agregar un intento de autenticación innecesario. El síntoma suele ser una pausa durante la configuración de la conexión antes de que la autenticación de clave pública continúe.

Configure esto en su ~/.ssh/config local:

Host *
    GSSAPIAuthentication no

Si solo ve la demora con un servidor, limite la configuración a ese host:

Host legacy-admin
    HostName legacy-admin.ejemplo.com
    User admin
    GSSAPIAuthentication no

Ejecute ssh -vvv legacy-admin y compare antes y después. Debería ver que el cliente omite GSSAPI y pasa directamente a la autenticación de clave pública o contraseña.

3. Dejar de ofrecer las claves incorrectas

Si su agente SSH tiene un montón de claves, su cliente puede ofrecer varias identidades antes de llegar a la que el servidor acepta. Esto es más lento de lo necesario, y algunos servidores rechazan el inicio de sesión después de demasiados intentos fallidos.

La salida verbose hace esto obvio:

debug1: Offering public key: /Users/me/.ssh/id_personal
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_old_vendor
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_prod

Fije la identidad correcta:

Host prod-api
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

IdentitiesOnly yes es importante. Sin ello, el cliente aún puede ofrecer claves del agente antes o junto al archivo configurado.

También puede verificar qué tiene cargado el agente:

ssh-add -l

Si la lista está desordenada, elimine las claves antiguas del agente y agregue solo las que necesita para el trabajo actual:

ssh-add -D
ssh-add ~/.ssh/id_ed25519_prod

4. Usar compresión solo donde ayude

La compresión no es un interruptor de velocidad universal. Puede ayudar cuando el enlace tiene ancho de banda limitado y los datos son comprimibles, como registros de texto largos a través de una VPN lenta. Puede perjudicar en redes rápidas porque ambos lados gastan CPU comprimiendo y descomprimiendo datos que de otro modo habrían cruzado el cable rápidamente.

Úsela de manera limitada:

Host distant-bastion
    HostName bastion.ejemplo.net
    User ops
    Compression yes

No la habilite globalmente a menos que haya medido que ayuda a sus conexiones diarias. Para SSH normal de nube a laptop, el valor predeterminado suele ser mejor.

Si escribir es lento, la compresión rara vez es la primera solución. Pruebe la ruta de red:

ping servidor.ejemplo.com
mtr servidor.ejemplo.com

Si ve alta latencia o pérdida de paquetes, la configuración de SSH solo puede hacer hasta cierto punto. Muévase a través de un bastión más cercano, arregle la ruta VPN o use una región más cercana al operador.

5. Reutilizar conexiones con multiplexación

Si la primera conexión SSH toma un par de segundos pero cada nueva pestaña de terminal repite ese costo, la multiplexación de conexiones es una solución limpia. SSH mantiene una conexión de control abierta y la reutiliza para sesiones posteriores al mismo usuario, host y puerto.

Agregue esto a ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

Cree el directorio del socket:

mkdir -p ~/.ssh/controlmasters
chmod 700 ~/.ssh/controlmasters

La primera conexión aún paga el costo normal del handshake y la autenticación. La siguiente debería sentirse casi instantánea.

Si una conexión multiplexada se queda atascada después de un cambio de red, cierre el socket maestro:

ssh -O exit [email protected]

O elimine el socket correspondiente de ~/.ssh/controlmasters.

Verificar el inicio del shell antes de culpar a SSH

Esto es fácil de pasar por alto. SSH puede autenticarse rápidamente, luego sus archivos de inicio del shell queman varios segundos antes de que aparezca el prompt.

Compare estos:

time ssh [email protected] true
time ssh [email protected] 'bash --noprofile --norc -i -c exit'

Luego inspeccione .bashrc, .bash_profile, .profile, .zshrc y cualquier cosa que carguen. Las ralentizaciones comunes incluyen temas de prompt que ejecutan comandos Git en directorios grandes, completaciones de kubectl o CLI de nube que consultan una API remota, inicialización de gestores de paquetes, directorios home NFS bloqueados y scripts que llaman a servicios internos durante el inicio de sesión.

La solución SSH más rápida es la que coincide con la pausa que realmente puede ver. Use -vvv, cambie una cosa a la vez y pruebe desde una segunda terminal mientras deja su sesión actual abierta.