Accélérer SSH : Mettre en œuvre le multiplexage de connexion pour des sessions plus rapides

Le multiplexage de connexion SSH rend les commandes SSH répétées beaucoup plus rapides car la deuxième commande peut réutiliser une connexion authentifiée existante. Si vous exécutez ssh host uptime, puis ssh host df -h, puis scp un fichier vers le même hôte, seule la première connexion nécessite l'intégralité de la poignée de main et du processus d'authentification.

Ceci est particulièrement utile pour les administrateurs, les développeurs et les outils d'automatisation qui ouvrent de nombreuses sessions courtes. Ce n'est pas magique et cela ne rendra pas une commande distante lente plus rapide. Cela supprime le coût de configuration répété.

Comprendre la surcharge de connexion SSH

Par défaut, chaque session SSH standard établit une toute nouvelle connexion TCP et effectue une poignée de main complète. Ce processus comprend :

1. Échange de clés : Détermination des secrets partagés et des algorithmes cryptographiques.
2. Authentification : Vérification des identifiants de l'utilisateur (mots de passe, fichiers de clés ou jetons à deux facteurs).
3. Configuration de la session : Initialisation du terminal ou du canal de commande.

Ce coût de configuration est faible sur un LAN proche et très perceptible sur les liaisons à haute latence, les VPN, les hôtes bastion ou les comptes nécessitant des clés matérielles ou des invites multi-facteurs. Le multiplexage de connexion évite de répéter une grande partie de ce travail en maintenant une connexion maître ouverte et en acheminant les nouvelles sessions à travers elle.

Comment fonctionne le multiplexage

Le multiplexage de connexion utilise un socket de domaine Unix local (un fichier sur votre machine locale) pour communiquer entre le processus SSH maître et les nouveaux processus esclaves.

• La connexion maître : La première commande SSH que vous exécutez crée la connexion persistante et configure le socket de communication.
• Le chemin de contrôle : Le chemin de fichier local désigné (le socket) utilisé par les sessions suivantes pour vérifier et se connecter au maître.
• La connexion réutilisée : Toute commande SSH ultérieure ciblant le même hôte, utilisateur et port effectifs se connecte au maître via le socket local, évitant une nouvelle configuration SSH complète.

Directives de configuration clés

Pour activer le multiplexage de connexion, vous configurez les paramètres de votre client SSH, généralement dans le fichier de configuration spécifique à l'utilisateur (~/.ssh/config). Les trois directives critiques sont ControlMaster, ControlPath et ControlPersist.

1. ControlMaster

Cette directive spécifie si SSH doit tenter de créer une connexion maître ou de réutiliser une connexion existante.

Valeur	Description
no	(Par défaut) Mode de connexion unique standard.
yes	Force la session à devenir le maître et à attendre les esclaves. (Rarement utilisé seul aujourd'hui).
auto	Paramètre préféré. Si une connexion maître existe, la réutiliser ; sinon, initier une nouvelle connexion maître.

Pour la plupart des configurations, ControlMaster auto est la valeur par défaut pratique.

2. ControlPath

Le chemin vers le fichier de socket de domaine Unix utilisé pour la communication. Ce chemin doit être unique par combinaison d'hôte distant, d'utilisateur et de port pour éviter que les sessions ne mélangent les canaux de contrôle.

L'utilisation de variables dans le chemin garantit l'unicité :

Variable	Description
%r	Nom d'utilisateur distant
%h	Nom d'hôte distant
%p	Port distant

Exemple de ControlPath :

ControlPath ~/.ssh/sockets/%r@%h:%p

Astuce : Créez toujours un répertoire dédié pour ces sockets (mkdir -p ~/.ssh/sockets) et assurez-vous qu'il a des permissions sécurisées (chmod 700 ~/.ssh/sockets).

3. ControlPersist

Cette directive indique au maître combien de temps rester ouvert après la fin de la commande initiale.

Avant ControlPersist (introduit dans OpenSSH 5.6), la connexion maître devait rester attachée à une session de terminal. Avec ControlPersist, le processus maître se détache et reste actif en arrière-plan.

Valeur	Description
no	La connexion maître se ferme immédiatement lorsque le terminal est fermé.
yes	La connexion maître persiste indéfiniment (jusqu'à ce qu'elle soit fermée manuellement ou que le système redémarre).
Valeurs de temps	Spécifie la durée (par exemple, 5m pour 5 minutes, 1h pour 1 heure). La connexion se ferme après cette période d'inactivité.

Définir ControlPersist 10m ou 15m est un point de départ raisonnable pour des sessions de travail typiques. Utilisez une valeur plus courte sur les postes de travail partagés ou les hôtes de saut sensibles.

Implémentation pratique dans ~/.ssh/config

Vous trouverez ci-dessous des exemples montrant comment configurer le multiplexage dans votre fichier de configuration client SSH.

Exemple 1 : Configuration globale

Cette configuration applique le multiplexage de connexion à tous les hôtes distants auxquels vous vous connectez, en supposant qu'ils fonctionnent sur le port standard 22.

# Configuration pour TOUS les hôtes (*)
Host *
    # Activer la réutilisation ou l'initiation de connexion
    ControlMaster auto

    # Maintenir la connexion active pendant 15 minutes après la fermeture de la dernière session
    ControlPersist 15m

    # Définir le chemin du socket, garantissant l'unicité basée sur l'utilisateur, l'hôte et le port
    ControlPath ~/.ssh/sockets/%r@%h:%p

    # Optionnel : utile sur certaines liaisons à faible bande passante, mais pas toujours plus rapide
    Compression yes

Exemple 2 : Configuration spécifique à un hôte

Il est souvent préférable de limiter le multiplexage aux hôtes ou groupes fréquemment consultés.

# Configuration spécifique aux hôtes correspondant à 'prod-*'
Host prod-*
    HostName %h.example.com
    ControlMaster auto
    ControlPersist 5m
    ControlPath ~/.ssh/sockets/%r@%h:%p

# Configuration spécifique à l'hôte de saut (qui peut nécessiter une persistance plus longue)
Host jumpbox
    ControlMaster auto
    ControlPersist 1h
    ControlPath ~/.ssh/sockets/%r@%h:%p

Utilisation, vérification et gestion

1. Vérification de l'amélioration de la vitesse

Vous pouvez facilement vérifier les gains de performances à l'aide de la commande time.

Première connexion :

$ time ssh myhost exit

real    0m1.234s
user    0m0.045s
sys     0m0.015s

Connexion suivante pendant que le maître est actif :

$ time ssh myhost exit

real    0m0.045s
user    0m0.005s
sys     0m0.003s

2. Vérification de l'état de la connexion maître

Une fois une connexion maître établie, le fichier socket existe dans votre ControlPath spécifié. Vous pouvez vérifier l'état de la connexion à l'aide du drapeau -O (option de contrôle).

# Vérifier si la connexion à myhost est active
ssh -O check myhost

En cas de succès, la sortie confirmera que la connexion socket est ouverte.

3. Terminaison de la connexion maître

Si vous devez fermer immédiatement la connexion maître persistante (par exemple parce que les informations d'authentification ont changé ou que vous devez tester une nouvelle configuration), utilisez l'option de contrôle exit :

# Termine la connexion maître à myhost
ssh -O exit myhost

Cette commande demande au processus maître de s'arrêter gracieusement. Les sessions suivantes seront alors obligées de créer une nouvelle connexion maître.

Une configuration par défaut plus sûre

Sur les clients OpenSSH plus récents, %C est souvent un meilleur jeton ControlPath que la combinaison manuelle de %r, %h et %p. Il se développe en un hachage des détails de connexion, ce qui évite les longs chemins de socket Unix et les caractères gênants dans les noms d'hôte.

Host *
    ControlMaster auto
    ControlPersist 10m
    ControlPath ~/.ssh/sockets/%C

La longueur du chemin du socket est importante car les sockets de domaine Unix ont des limites spécifiques à la plateforme. Un chemin long comme ~/.ssh/sockets/utilisateur-très-long@nom-d-hôte-très-long.example.internal:2222 peut échouer sur certains systèmes. Si vous voyez des erreurs concernant un chemin de contrôle trop long, passez à %C.

Assurez-vous également que le répertoire des sockets existe avant de vous fier à cette configuration :

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

Quand éviter le multiplexage

N'activez pas le multiplexage aveuglément pour chaque situation. Quelques cas méritent une attention particulière :

• Modification des autorisations du compte : Si l'appartenance à un groupe, les commandes forcées ou la politique du compte côté serveur changent pendant une session, une connexion réutilisée peut ne pas refléter le nouvel état jusqu'à ce que le maître se ferme.
• Dépannage du bastion et de l'hôte de saut : Lors du test des échecs de connexion, désactivez le multiplexage afin de savoir que chaque commande crée un nouveau chemin.
• Hôtes hautement sensibles : Une connexion maître persistante maintient un canal authentifié disponible à partir de votre compte local jusqu'à l'expiration de ControlPersist. C'est généralement acceptable sur un poste de travail personnel avec les bonnes permissions, mais cela peut ne pas convenir à toutes les politiques de sécurité.

Pour une seule commande, désactivez la réutilisation comme ceci :

ssh -o ControlMaster=no -o ControlPath=none user@host

Multiplexage avec les outils d'automatisation

Ansible, rsync, Git over SSH et les scripts de déploiement peuvent tous bénéficier du multiplexage car ils ouvrent souvent de nombreuses sessions courtes. Pour Ansible en particulier, les arguments SSH se trouvent généralement dans ansible.cfg :

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=10m -o ControlPath=~/.ssh/sockets/%C

Si votre automatisation s'exécute depuis CI, pensez au cycle de vie de l'exécuteur. Un travail CI de courte durée peut ne pas bénéficier beaucoup car l'espace de travail disparaît après le travail. Un hôte de déploiement de longue durée peut bénéficier beaucoup, mais il nécessite également un nettoyage et des permissions prévisibles. Ne placez pas les sockets de contrôle dans un répertoire partagé accessible en écriture par tous comme /tmp à moins de comprendre pleinement les implications de sécurité et d'utiliser un sous-répertoire privé.

Pour rsync, le multiplexage aide surtout lorsque votre flux de travail exécute plusieurs commandes rsync ou ssh distinctes contre le même hôte :

rsync -az ./release/ app@web01:/opt/app/releases/current/
ssh app@web01 'systemctl --user restart app'
ssh app@web01 'systemctl --user status app --no-pager'

La première commande ouvre le maître. Les deux suivantes peuvent le réutiliser si l'hôte, l'utilisateur, le port et les options SSH effectives correspondent.

Débogage des problèmes de socket obsolètes

Parfois, un fichier socket reste après la mort de la connexion maître. Lorsque cela se produit, une commande SSH ultérieure peut afficher une erreur concernant la connexion au socket de contrôle, puis revenir à une connexion normale, ou elle peut échouer selon les options utilisées.

Vérifiez d'abord le maître :

ssh -O check web01

S'il échoue et que vous voyez un ancien socket sous ~/.ssh/sockets, supprimez ce fichier obsolète. Si cela se produit souvent, vérifiez si la mise en veille de votre poste de travail, la déconnexion VPN ou les changements de réseau tuent la connexion maître. Un ControlPersist plus court peut être meilleur qu'un maître de longue durée sur des réseaux instables.

Vous pouvez également demander à SSH d'être plus explicite lors du débogage :

ssh -vvv web01 exit

Recherchez les lignes mentionnant ControlPath, mux_client ou un maître existant. Une fois que vous savez que le multiplexage est impliqué, fermez le maître et retestez avant de blâmer le DNS, les clés ou le démon SSH distant.

Hôtes de saut et correspondance d'options

Le multiplexage est lié à la destination SSH effective et aux options. Si vous vous connectez au même serveur une fois directement et une fois via un hôte de saut, ce ne sont pas nécessairement la même connexion de contrôle. Il en va de même lorsqu'une commande utilise un alias d'hôte et qu'une autre utilise le nom d'hôte brut avec des paramètres User, Port, ProxyJump ou de fichier d'identité différents.

Pour une réutilisation prévisible, placez les détails de connexion réels dans ~/.ssh/config et utilisez l'alias partout :

Host app-prod-1
    HostName 10.20.30.41
    User deploy
    ProxyJump bastion-prod
    IdentityFile ~/.ssh/prod_deploy
    ControlMaster auto
    ControlPersist 10m
    ControlPath ~/.ssh/sockets/%C

Exécutez ensuite ssh app-prod-1, scp file app-prod-1:/tmp/ et l'automatisation contre app-prod-1. Mélanger les alias, les adresses IP et les drapeaux -J ponctuels rend plus difficile la compréhension de savoir si une commande doit réutiliser le maître existant.

C'est aussi pourquoi les équipes devraient documenter les alias d'hôte préférés dans les runbooks. Une convention partagée évite des connexions à moitié réutilisées déroutantes lors des déploiements.

Dépannage et bonnes pratiques

Répertoire et permissions

La sécurité est primordiale. Le fichier socket créé par SSH contient des métadonnées sur votre connexion, y compris des commandes de contrôle potentielles. Assurez-vous que le répertoire des sockets a des permissions restreintes.

# Créer le répertoire s'il n'existe pas
mkdir -p ~/.ssh/sockets

# Définir des permissions strictes (accessible uniquement par le propriétaire)
chmod 700 ~/.ssh/sockets

Contrôle de plusieurs utilisateurs

Si vous utilisez différents noms d'utilisateur pour vous connecter au même hôte, le multiplexage gérera cela automatiquement car la variable %r (utilisateur distant) dans le ControlPath garantit que des sockets séparés sont créés pour user1@host et user2@host.

Conflits avec d'autres clients

Si vous exécutez des scripts ou des outils automatisés qui reposent sur SSH, assurez-vous qu'ils sont configurés pour utiliser les mêmes paramètres de multiplexage ou pour le désactiver explicitement si nécessaire. Si un script a besoin de garantir une nouvelle connexion, vous pouvez forcer un comportement non multiplexé sur la ligne de commande :

ssh -o ControlMaster=no user@host

Le multiplexage de connexion SSH est l'une des améliorations les plus simples de la qualité de vie pour une utilisation fréquente de SSH. Configurez ControlMaster auto, utilisez un ControlPath unique et court, définissez un ControlPersist raisonnable et vérifiez avec ssh -O check host. Si une connexion se comporte étrangement lors du dépannage, fermez le maître avec ssh -O exit host et testez à nouveau avec une nouvelle session.