Pourquoi ma connexion SSH est-elle lente ? Cinq correctifs immédiats pour les problèmes de latence

Un SSH lent n'est pas un seul problème. Parfois, le délai survient avant même d'obtenir une invite. Parfois, la connexion est rapide, mais chaque frappe semble collante. Parfois, on accuse SSH d'un script de démarrage lent, d'une recherche DNS bloquée, ou d'un chemin réseau qui perd des paquets entre votre ordinateur portable et une région cloud à l'autre bout du monde.

Avant de modifier les paramètres, exécutez un test simple :

time ssh -vvv [email protected] exit

La sortie de time vous indique si la connexion complète est lente. La sortie de -vvv vous indique où le client passe du temps. Recherchez des tentatives de clés répétées, des messages GSSAPI, des pauses liées au DNS, ou un long intervalle avant le début de l'authentification. Si ssh user@host exit est rapide mais qu'une connexion interactive est lente, le problème vient probablement des fichiers de démarrage du shell distant plutôt que de SSH lui-même.

Il y a trois schémas courants :

Lent avant l'authentification : Généralement DNS, GSSAPI, recherche de clé d'hôte, ou un backend d'authentification lent.
Lent après l'authentification mais avant l'invite : Généralement .bashrc, .profile, .zshrc, répertoires personnels montés sur le réseau, ou plugins de shell.
Lent lors de la frappe ou de l'utilisation d'outils plein écran : Généralement latence réseau réelle, perte de paquets, points de terminaison surchargés, surcharge de compression, ou rendu du terminal.

Les correctifs ci-dessous sont classés par fréquence à laquelle ils résolvent les plaintes réelles de latence SSH.

1. Désactiver les recherches DNS inversées sur le serveur

Le DNS inversé est une cause classique de connexions SSH lentes sur les réseaux internes. Le serveur accepte votre connexion TCP, puis tente de résoudre l'adresse IP du client en un nom d'hôte. Si le DNS inversé est manquant, mal configuré, ou géré par un résolveur lent, la connexion peut marquer une pause de plusieurs secondes.

C'est un paramètre côté serveur. Ajoutez ou mettez à jour cette ligne dans /etc/ssh/sshd_config :

UseDNS no

Ensuite, testez et rechargez SSH :

sudo sshd -t
sudo systemctl reload sshd

Certaines distributions utilisent ssh comme nom de service :

sudo systemctl reload ssh

Gardez votre session existante ouverte tout en testant une nouvelle connexion. Si la nouvelle connexion est rapide, vous avez trouvé le délai. Si rien ne change, laissez le paramètre en place s'il correspond à votre environnement, mais continuez à dépanner.

2. Désactiver GSSAPI lorsque vous n'utilisez pas Kerberos

GSSAPI est utile dans les environnements basés sur Kerberos. En dehors de ces environnements, il peut ajouter une tentative d'authentification inutile. Le symptôme est généralement une pause lors de la configuration de la connexion avant que l'authentification par clé publique ne continue.

Définissez ceci dans votre ~/.ssh/config local :

Host *
    GSSAPIAuthentication no

Si vous ne voyez le délai qu'avec un seul serveur, limitez le paramètre à cet hôte :

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

Exécutez ssh -vvv legacy-admin et comparez avant et après. Vous devriez voir le client ignorer GSSAPI et passer directement à l'authentification par clé publique ou par mot de passe.

3. Cesser de proposer les mauvaises clés

Si votre agent SSH contient un tas de clés, votre client peut en proposer plusieurs avant d'atteindre celle que le serveur accepte. C'est plus lent que nécessaire, et certains serveurs rejettent la connexion après trop de tentatives échouées.

La sortie verbeuse rend cela évident :

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

Épinglez la bonne identité :

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

IdentitiesOnly yes est important. Sans cela, le client peut encore proposer des clés de l'agent avant ou en parallèle du fichier configuré.

Vous pouvez également vérifier ce que l'agent a chargé :

ssh-add -l

Si la liste est désordonnée, supprimez les anciennes clés de l'agent et n'ajoutez que ce dont vous avez besoin pour le travail en cours :

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

4. Utiliser la compression uniquement là où elle aide

La compression n'est pas un interrupteur de vitesse universel. Elle peut aider lorsque le lien est limité en bande passante et que les données sont compressibles, comme de longs journaux texte sur un VPN lent. Elle peut nuire sur les réseaux rapides car les deux côtés dépensent du CPU pour compresser et décompresser des données qui auraient traversé le câble rapidement de toute façon.

Utilisez-la de manière ciblée :

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

Ne l'activez pas globalement à moins d'avoir mesuré qu'elle aide vos connexions quotidiennes. Pour un SSH normal entre un cloud et un ordinateur portable, la valeur par défaut est souvent meilleure.

Si la frappe est lente, la compression est rarement le premier correctif. Testez le chemin réseau :

ping server.example.com
mtr server.example.com

Si vous voyez une latence élevée ou une perte de paquets, la configuration SSH ne peut pas faire grand-chose. Passez par un bastion plus proche, corrigez le chemin VPN, ou utilisez une région plus proche de l'opérateur.

5. Réutiliser les connexions avec le multiplexage

Si la première connexion SSH prend quelques secondes mais que chaque nouvel onglet de terminal répète ce coût, le multiplexage de connexion est un correctif propre. SSH maintient une connexion de contrôle ouverte et la réutilise pour les sessions ultérieures vers le même utilisateur, hôte et port.

Ajoutez ceci à ~/.ssh/config :

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

Créez le répertoire de socket :

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

La première connexion paie toujours le coût normal de la poignée de main et de l'authentification. La suivante devrait être quasi instantanée.

Si une connexion multiplexée reste bloquée après un changement réseau, fermez le socket maître :

ssh -O exit [email protected]

Ou supprimez le socket correspondant de ~/.ssh/controlmasters.

Vérifier le démarrage du shell avant d'accuser SSH

Celui-ci est facile à manquer. SSH peut s'authentifier rapidement, puis vos fichiers de démarrage du shell brûlent plusieurs secondes avant que l'invite n'apparaisse.

Comparez ceci :

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

Ensuite, inspectez .bashrc, .bash_profile, .profile, .zshrc, et tout ce qu'ils sourcent. Les ralentissements courants incluent les thèmes d'invite qui exécutent des commandes Git dans de grands répertoires, les complétions kubectl ou CLI cloud qui interrogent une API distante, l'initialisation du gestionnaire de paquets, les répertoires personnels NFS bloqués, et les scripts qui appellent des services internes lors de la connexion.

Le correctif SSH le plus rapide est celui qui correspond à la pause que vous pouvez réellement voir. Utilisez -vvv, changez une chose à la fois, et testez depuis un deuxième terminal tout en laissant votre session actuelle ouverte.