SSH ControlMaster sur Mac distant : configurer les sessions multiples en 2026

Un transfert SCP et plusieurs commandes SSH ouvrent chacun leur propre connexion, alors que le Mac distant est déjà accessible.

Le choix adapté est SSH ControlMaster avec ControlPersist, si le chemin ControlPath distingue correctement les connexions et si son répertoire n’est accessible qu’au compte local concerné. Ce partage réutilise la connexion SSH ; il ne garantit pas qu’un build continue après une coupure.

Ce guide s’adresse aux ingénieurs qui exécutent régulièrement des commandes, transferts et builds sur un Mac distant.
Les responsables DevOps d’un nœud partagé y trouveront aussi les contrôles de permissions, d’isolation et de fermeture.

Avant de partager une connexion : vérifier les accès et les limites

ControlMaster agit côté client OpenSSH. Le Mac distant doit être joignable par SSH et autoriser le compte utilisé. Sur macOS, Remote Login permet l’accès distant par SSH et SFTP ; son activation et la liste des utilisateurs autorisés se gèrent dans les réglages de partage. Consultez la documentation Apple sur Remote Login avant de diagnostiquer un échec comme un problème de multiplexage.

Trois limites sont à clarifier avant de modifier le fichier de configuration.

• Les connexions ne partagent pas automatiquement leur identité. Un alias qui pointe vers le bon hôte avec un autre compte, un autre port ou une autre règle d’accès peut ouvrir une connexion séparée, ou échouer.
• Le client et le serveur n’ont pas le même rôle. Les options ControlMaster, ControlPath et ControlPersist se configurent côté client. Les règles du serveur restent soumises à la configuration SSH de macOS et aux permissions de Remote Login.
• La connexion partagée n’est pas un gestionnaire de tâches. Si le réseau tombe, les canaux de la connexion peuvent être interrompus. Il ne faut pas déduire de la présence d’un socket que la commande distante a survécu ou qu’elle peut reprendre sans contrôle.

Le protocole SSH prévoit plusieurs canaux logiques au sein d’une connexion de transport. C’est le principe qui permet de partager cette connexion, sans pour autant transformer les commandes en un seul processus persistant. Voir la description des canaux dans RFC 4254.

Avant la configuration, le client peut afficher les options effectives d’un alias :

ssh -V
ssh -G mac-build | grep -E '^(hostname|user|port|controlmaster|controlpath|controlpersist) '

ssh -V indique la version du client ; ssh -G expose la configuration calculée. Les résultats varient selon le client et les fichiers de configuration chargés. Le manuel OpenSSH de ssh_config détaille les options et les jetons disponibles.

Choisir les options : un rôle distinct pour chaque directive

Un alias dédié évite d’activer le partage sans discernement pour toutes les destinations. Les noms d’hôte, de compte et de clé ci-dessous sont des valeurs de remplacement.

Host mac-build
    HostName <adresse-du-mac>
    User <compte-distant>
    Port <port-ssh>
    IdentityFile ~/.ssh/<cle-pour-ce-mac>

    ControlMaster auto
    ControlPath ~/.ssh/cm/%C
    ControlPersist 5m

La durée inscrite dans l’exemple est un choix de configuration, pas une garantie universelle. Ajustez-la au rythme des commandes, puis vérifiez le comportement avec la version du client installée.

Pour définir ControlPath, %C fournit un identifiant compact calculé à partir de paramètres de connexion décrits dans le manuel OpenSSH. Il convient à une séparation par destination, compte et port. Si des alias doivent aussi isoler des configurations distinctes, ajoutez un jeton approprié et inspectez le chemin obtenu avec ssh -G. Évitez de supposer que deux profils utilisant le même compte distant mais des clés différentes seront séparés par le seul nom de la clé.

Le socket est un point d’accès local à la connexion maître. Créez son répertoire sous le compte qui lancera les commandes :

install -d -m 700 ~/.ssh/cm

Vérifiez son propriétaire et ses permissions. Sur une machine partagée, un autre compte local ne doit pas pouvoir écrire dans ce répertoire ni remplacer ses sockets. Le manuel OpenSSH de ssh_config décrit les contraintes de ControlPath et les précautions liées au socket.

À retenir : les permissions affichées dans les réglages de Remote Login concernent l’accès au Mac distant. Elles ne remplacent pas les permissions locales du répertoire qui contient ControlPath.

Premier accès : établir puis contrôler la connexion maître

Avec ControlMaster auto, une connexion ordinaire peut créer le maître si aucun socket correspondant n’existe. Pour rendre l’essai explicite, ouvrez une session sans commande distante :

ssh -MNf mac-build

Cette invocation demande au client de créer une connexion maître, de ne pas lancer de commande distante et de se placer en arrière-plan. Si l’authentification ou l’accès réseau échoue, réglez ce problème avant d’évaluer la réutilisation. Une connexion maîtresse n’accorde pas davantage de droits que le compte SSH déjà autorisé.

Contrôlez ensuite l’état du maître :

ssh -O check mac-build

Un client peut produire une réponse du type Master running. Le texte exact dépend de la version ; c’est le statut de la commande et la présence d’un maître actif pour l’alias qui comptent. Si la commande indique qu’aucun maître n’est actif, vérifiez le chemin calculé et la correspondance des options plutôt que de créer des sockets au hasard.

La configuration doit être chargée de façon identique par les commandes de test. Pour les scripts, passez l’alias mac-build plutôt que de répéter une adresse IP avec des options en ligne de commande : une variation du compte ou du port peut empêcher la réutilisation.

Commandes et transferts parallèles : réutiliser sans confondre les tâches

Depuis un autre terminal, lancez plusieurs opérations avec le même alias :

ssh mac-build 'hostname'
ssh mac-build 'cd <repertoire-du-projet> && <commande-de-verification>'
scp <fichier-local> mac-build:<chemin-distant>
ssh -O check mac-build

La deuxième commande SSH et le transfert SCP peuvent emprunter le maître si leurs options effectives correspondent. Le transfert copie un fichier ; il ne prouve pas qu’un build distant sera récupérable après une perte de réseau. Pour les particularités de la commande de transfert, consultez le manuel OpenSSH de scp.

Ces vérifications établissent l’existence et l’usage de la connexion partagée ; elles ne constituent pas une preuve de durée de vie du processus distant. Pour distinguer les deux, observez séparément le code de sortie, le fichier ou l’artefact attendu, et l’état réel du build. Les commandes exécutées à travers le même maître restent des opérations distinctes.

Pour un usage automatisé, consignez le résultat de chaque étape dans les journaux du script : résolution de l’alias, état de la connexion, code de retour du transfert, puis résultat du build. En cas d’échec, cette séparation aide à savoir si la cause se situe dans l’authentification, le réseau, le transfert ou la commande distante. N’interprétez pas une vérification positive du maître comme un succès du pipeline.

Plusieurs terminaux et utilisateurs : isoler les sockets

Des terminaux ou scripts qui partagent volontairement le même alias et le même compte peuvent utiliser un maître commun. La situation change si plusieurs comptes locaux, clés, environnements d’intégration continue ou destinations entrent en jeu. Le contrôle doit porter sur les options effectives, pas seulement sur le nom visible de l’alias.

Le contrôle côté serveur est distinct. Les options de sshd_config gouvernent le service SSH, et non le chemin du socket créé par le client. La référence OpenSSH de sshd_config aide à vérifier les règles serveur pertinentes. Pour un nœud partagé, l’acceptation doit inclure un compte adapté, des permissions locales minimales et une configuration consultable par l’équipe d’exploitation.

Rappel de sécurité : ne rendez pas le répertoire ControlPath accessible en écriture à un groupe simplement pour faciliter le partage entre utilisateurs. Organisez plutôt l’accès par comptes et configurations distincts, puis validez explicitement le comportement attendu.

Coupure, fermeture ou Mac indisponible : choisir le bon retour

Une connexion SSH qui disparaît ne signifie pas toujours la même chose. La réponse dépend de l’endroit où l’interruption a eu lieu et de l’état de la commande distante.

Quand il faut fermer le maître, la commande de contrôle est :

ssh -O exit mac-build

Elle peut mettre fin à la connexion commune. Avant de l’utiliser, vérifiez qu’aucun transfert ou commande ne dépend encore de ce maître. Ne supprimez pas un socket actif pour « réparer » une connexion : confirmez d’abord l’état avec ssh -O check, puis suivez les procédures de l’équipe si le résultat reste ambigu.

Si un build doit continuer après la fermeture du terminal ou la perte du réseau, il faut une stratégie distincte de maintien et de reprise de tâche, ainsi qu’une vérification de son résultat. ControlPersist maintient la connexion maître selon sa configuration ; il ne garantit ni la survie d’un processus distant ni la reprise automatique d’un build.

Validation de bout en bout : retenir la bonne branche

La dernière vérification doit reproduire le travail réel, pas seulement afficher un nom d’hôte. Exécutez une commande SSH de contrôle, transférez un fichier avec SCP, puis lancez un build dont le résultat peut être vérifié à distance. Contrôlez l’état du maître entre les opérations et comparez les résultats avec les journaux de l’automatisation. Un échec doit avoir une voie de récupération définie : nouvelle connexion, diagnostic du transfert ou relance contrôlée du build.

Les sources publiques confirment les mécanismes SSH et Remote Login, mais elles ne valident pas la configuration propre à chaque installation. Le client OpenSSH réellement utilisé, les règles du serveur, la méthode d’accès au Mac et le script de build déterminent le résultat. Pour une procédure d’exploitation, gardez ces éléments dans le compte rendu de test plutôt que de conclure à partir d’une seule commande réussie.

• Si plusieurs clients doivent seulement éviter de recréer une connexion, que le compte et la destination sont identiques et que le socket reste privé, activez ControlMaster avec un ControlPath vérifié.
• Si des identités, comptes ou environnements doivent rester séparés, employez des alias et chemins distincts ; désactivez le partage pour les cas où l’isolation n’est pas démontrée.
• Si une tâche doit survivre à une coupure, ne choisissez pas ControlPersist comme mécanisme de reprise. Déployez et testez séparément une méthode de gestion de tâche.
• Si le Mac n’est pas joignable ou si Remote Login refuse l’accès, corrigez d’abord l’accès distant ; le multiplexage ne résout pas un problème d’authentification ou de disponibilité.

Questions fréquentes

ControlMaster peut-il partager la connexion entre SSH et SCP ?

Oui, à condition que les deux commandes chargent une configuration compatible et visent le même hôte, le même port et le même compte. Utiliser le même alias est souvent le moyen le plus simple d’éviter une divergence involontaire. Un test SCP réussi confirme le transfert, mais ne renseigne pas sur la continuité d’une autre commande si la connexion est interrompue.

Pourquoi une commande ouvre-t-elle une nouvelle connexion malgré ControlMaster ?

Le client peut calculer des options différentes pour cette commande : alias différent, utilisateur, port, proxy ou chemin ControlPath distinct. Comparez les sorties de ssh -G pour les deux invocations. Vérifiez aussi que le maître est toujours actif. Une différence de configuration ou un maître fermé explique généralement l’absence de réutilisation ; elle ne signifie pas nécessairement que l’option est ignorée.

ControlPersist maintient-il un build après une coupure réseau ?

Non, ce réglage concerne la connexion maître, pas la gestion du processus lancé sur le Mac. Une interruption peut fermer le canal utilisé par le client et laisser le résultat du build incertain. Il faut contrôler les journaux, l’artefact et le code de retour, puis décider si une relance est sûre. Les tâches critiques demandent un mécanisme de maintien distinct.

Le socket ControlPath peut-il être partagé entre plusieurs comptes locaux ?

Un socket placé dans un répertoire privé ne constitue pas un mécanisme de partage entre comptes. Élargir les permissions peut créer une frontière d’accès indésirable. Pour un Mac ou un poste partagé, gardez des répertoires et configurations séparés, limitez les droits, et vérifiez qui peut accéder au compte distant. N’autorisez un partage commun qu’après validation explicite de l’isolation et de l’audit.

Pour une équipe dont les commandes actuelles partent d’un poste Linux ou Windows, les limites sont concrètes : l’environnement local ne fournit pas à lui seul les outils macOS, les scripts et les secrets doivent être adaptés au nœud distant, et les coupures rendent les builds longs plus délicats à contrôler. Un Mac local évite une partie de la dépendance réseau, mais immobilise un budget matériel et demande sa propre maintenance. Pour des builds et validations macOS ponctuels ou évolutifs, la location d’un Mac réel via SFTPMAC peut éviter l’achat immédiat, tout en nécessitant de tester le réseau et l’accès SSH dans les conditions de travail. Les tarifs de location et les options de Mac distant permettent d’évaluer cette voie ; pour une charge permanente avec exigences matérielles fixes, l’achat d’un Mac peut rester plus approprié.