Des identifiants à votre environnement de travail

Trois façons de vous connecter à votre M4

SSH pour la ligne de commande, un bureau graphique pour les opérations interactives et un runner CI pour les builds automatisés. Ces trois accès mènent au même nœud physique dédié, pas à trois environnements distincts.

Louer un Mac dans le cloud Voir mes identifiants dans le portail

Déjà client ? Ouvrez dans le portail les détails de l’instance associée à votre commande pour consulter l’adresse de l’hôte, le port SSH, le nom d’utilisateur et les instructions de mise à disposition. Remplacez chaque variable d’hôte de ce guide par la valeur réelle de votre instance.

SSHVérifier l’hôte, synchroniser des fichiers et lancer des builds

Bureau graphiqueUtiliser Xcode, le simulateur et macOS

Runner CIExécuter les tâches du projet sur votre nœud physique

Commencez par une connexion vérifiable

SSH : créez une clé et configurez un alias de nœud

Commencez par établir la connexion en ligne de commande, puis configurez le bureau et le pipeline. SSH est aussi le moyen le plus rapide de vérifier que le nœud est accessible et de diagnostiquer un problème d’authentification.

01
Générez une clé en local
Exécutez ces commandes sur votre ordinateur, pas sur le nœud distant. Définissez une phrase secrète pour la clé. Si vous disposez déjà d’une clé dédiée, vous pouvez la réutiliser ; ne remplacez pas un fichier encore utilisé. La clé privée reste toujours en local. Seule la clé publique, dont le nom se termine par .pub, est transmise au nœud.
```
ssh-keygen -t ed25519 -f ~/.ssh/xcnode_ed25519 -C "xcnode-workstation"
ssh-add ~/.ssh/xcnode_ed25519
```
Si ssh-add indique qu’aucun agent d’authentification n’est connecté, vérifiez que l’agent SSH de votre ordinateur est démarré. La phrase secrète de la clé et le mot de passe de l’utilisateur distant sont deux choses différentes.
02
Installez la clé publique et vérifiez l’hôte
Définissez les trois variables selon les instructions de votre instance. Utilisez ssh-copy-id uniquement si les instructions autorisent l’authentification par mot de passe lors de la première connexion. Si votre clé publique est déjà enregistrée, testez directement la connexion. Lors de la première connexion, vérifiez l’empreinte de l’hôte ; n’acceptez pas un hôte inconnu simplement parce qu’une invite de confirmation s’affiche.
```
read -r -p "Host: " NODE_HOST
read -r -p "SSH port: " NODE_PORT
read -r -p "User: " NODE_USER
ssh-copy-id -i ~/.ssh/xcnode_ed25519.pub -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"
ssh -i ~/.ssh/xcnode_ed25519 -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"
```
La saisie des variables ci-dessus fonctionne avec Bash. Sous zsh sur macOS, lancez d’abord bash. Si l’installation initiale de la clé publique échoue, utilisez la procédure de gestion des identifiants indiquée dans le portail ou ouvrez un ticket ; ne multipliez pas les essais de mot de passe.
03
Enregistrez un alias et vérifiez l’environnement
Ajoutez un alias dans votre fichier local ~/.ssh/config. Remplacez les champs entre chevrons ci-dessous par les valeurs de votre instance, sans conserver les chevrons. OpenSSH sous Windows lit également le fichier .ssh/config du répertoire utilisateur.
```
Host xcnode-work
  HostName <INSTANCE_HOST>
  Port <SSH_PORT>
  User <INSTANCE_USER>
  IdentityFile ~/.ssh/xcnode_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3
```
```
ssh xcnode-work
uname -m
sysctl -n machdep.cpu.brand_string
xcode-select -p
xcodebuild -version
```
uname -m doit renvoyer arm64. Vérifiez que le nom de la puce correspond au modèle commandé. La version de Xcode dépend de celle installée sur le nœud. Garder une connexion active ne relance pas automatiquement les tâches ; pour les builds longs, utilisez un runner ou un outil de gestion de sessions persistantes.

Trois systèmes, des points à vérifier différents

Vérifiez d’abord que ssh -V fonctionne en local. L’absence d’une commande auxiliaire ne signifie pas que le nœud ne prend pas SSH en charge.

Préparation du client local et installation de la clé publique
Système local	Client SSH	Installation de la clé publique	À noter
macOS	OpenSSH est inclus dans le Terminal	`ssh-copy-id` doit généralement être installé séparément. Vous pouvez aussi enregistrer la clé publique selon les instructions de mise à disposition.	Le shell par défaut est souvent zsh ; n’utilisez pas directement la syntaxe de saisie propre à Bash.
Windows	Utilisez OpenSSH Client dans PowerShell	Utilisez `ssh-copy-id` dans WSL ou enregistrez la clé publique dans le portail.	PowerShell et WSL ont chacun leur propre répertoire utilisateur et leurs propres fichiers de clés.
Linux	Le paquet client OpenSSH de votre distribution	`ssh-copy-id` est généralement fourni ; sinon, installez d’abord les outils client.	Définissez les permissions de la clé privée sur `600` et celles du répertoire `~/.ssh` sur `700`.

Pour utiliser une interface graphique

Bureau graphique : privilégiez un tunnel SSH

Une fois SSH opérationnel, vérifiez le service de partage d’écran et la session graphique. Un port accessible ne signifie pas que le bureau est prêt.

Partage d’écran macOS

Sur un Mac local, vous pouvez utiliser l’application « Partage d’écran » intégrée à macOS. Le port de service VNC habituel est le TCP 5900. Le port réel, le mode d’authentification et l’activation du service dépendent des instructions de mise à disposition de votre instance.

Après avoir confirmé que le port distant est bien 5900, créez un tunnel depuis le Terminal local et laissez cette fenêtre ouverte. L’exemple utilise le port local 15900 pour éviter tout conflit avec un service de votre ordinateur.

ssh -N -L 127.0.0.1:15900:127.0.0.1:5900 \
  -o ExitOnForwardFailure=yes xcnode-work

Ouvrez ensuite le client dans un autre Terminal :

open "vnc://127.0.0.1:15900"

Tunnel limité à l’interface locale

Clients VNC sous Windows et Linux

Choisissez un client VNC compatible avec le mode d’authentification de votre instance, par exemple TigerVNC. Créez d’abord le même tunnel SSH, puis indiquez 127.0.0.1 comme hôte et 15900 comme port.

La saisie du port varie selon les clients : certains proposent un champ dédié, d’autres utilisent un double deux-points pour indiquer le port complet. Suivez la documentation du client et ne confondez pas le port avec le numéro d’affichage.

L’authentification du partage d’écran macOS n’est pas toujours compatible avec les clients VNC génériques. En cas d’échec, vérifiez d’abord les fonctionnalités du client et les instructions de mise à disposition. Ne réduisez pas les protections d’accès du nœud pour contourner une incompatibilité.

Identifiants du bureau séparés des clés SSH

Commencez avec une qualité d’image réduite

Lors de la première connexion, choisissez le mode automatique ou une qualité d’image faible et utilisez un seul écran. Évitez de transférer de gros fichiers tout en affichant des contenus animés en plein écran. Quand le texte est lisible et les clics réactifs, augmentez progressivement la résolution et la qualité des couleurs. Un transfert de fichiers rapide en SSH ne garantit pas une faible latence pour le bureau graphique.

En cas d’écran noir, vérifiez dans l’ordre que le tunnel fonctionne toujours, que le port cible est correct, que le partage d’écran est activé et qu’une session graphique est disponible à distance. En cas de conflit de session, convenez d’un créneau d’utilisation avec l’équipe ; ne forcez pas la déconnexion d’un utilisateur dont le build est en cours.

Acheminez automatiquement les tâches vers le nœud

CI : inscrivez le runner, puis vérifiez son démarrage automatique

Le runner s’exécute sur le Mac dans le cloud, pas sur votre ordinateur. Validez d’abord la chaîne d’outils avec une tâche interactive, puis configurez le runner comme service.

Runner self-hosted GitHub Actions

Dans les paramètres des runners du projet ou de l’organisation, choisissez macOS ARM64. Suivez les commandes de téléchargement et de vérification affichées sur la page. Récupérez l’URL d’inscription et le jeton à durée limitée depuis ces paramètres.

cd ~/actions-runner
read -r -p "Registration URL: " RUNNER_URL
read -r -s -p "Registration token: " RUNNER_TOKEN
printf '\n'
./config.sh --url "$RUNNER_URL" --token "$RUNNER_TOKEN" \
  --name xcnode-work --labels xcnode,arm64
unset RUNNER_TOKEN
./run.sh

Exécutez les commandes de saisie ci-dessus dans Bash. Soumettez une tâche de test et vérifiez que le runner est en ligne et que le build aboutit. Arrêtez ensuite le processus au premier plan et installez le service :

./svc.sh install
./svc.sh start
./svc.sh status

Utilisez des labels explicites dans le workflow pour éviter d’envoyer une tâche vers une machine d’une autre architecture :

runs-on: [self-hosted, macOS, ARM64, xcnode]
steps:
  - run: xcodebuild -version

Le jeton d’inscription n’est pas une clé de projet permanente. Ne l’ajoutez ni au dépôt, ni aux logs de build, ni aux pièces jointes d’un ticket.

GitLab Runner

Créez un runner dans le projet ou le groupe, puis récupérez le jeton d’authentification en suivant les instructions de la plateforme. Après avoir installé la version macOS ARM64, enregistrez-le depuis le Terminal de la session graphique de l’utilisateur qui exécutera les tâches. Ne lancez pas les builds du projet en tant que root.

gitlab-runner register

Saisissez l’URL de l’instance et le jeton d’authentification, puis choisissez l’exécuteur shell. Attribuez les labels xcnode et arm64 au runner et limitez son utilisation aux projets de confiance.

gitlab-runner install
gitlab-runner start
gitlab-runner status

Commencez par vérifier l’environnement avec une tâche minimale, puis ajoutez la signature et l’archivage :

build-check:
  tags: [xcnode, arm64]
  script:
    - uname -m
    - xcode-select -p
    - xcodebuild -version

L’exécuteur Shell peut accéder aux fichiers de l’utilisateur qui l’exécute. Une machine dédiée n’isole pas les tâches non fiables lancées sous le même compte.

Vérifiez séparément le démarrage automatique et les tâches interactives

Sous macOS, les services au niveau utilisateur sont généralement gérés par launchd et peuvent dépendre de la session utilisateur. Après l’installation du service, vérifiez les processus, les logs et l’état de la file d’attente. Testez la reprise après redémarrage à un moment convenu avec l’équipe. Pour les tâches nécessitant un simulateur ou une interface graphique, vérifiez aussi que la session ouverte répond aux exigences ; le statut « en ligne » du runner ne suffit pas.

Commencez par une seule tâche et notez la consommation mémoire maximale réelle du projet avant d’augmenter le parallélisme. Séparez les caches par projet et par version de Xcode, et archivez les artefacts de build à part. Si vous utilisez des certificats de signature du trousseau système, vérifiez séparément les droits d’accès du compte de service : un build réussi dans le Terminal ne garantit pas la réussite d’un build en arrière-plan.

Choisissez un emplacement selon votre réseau

Quatre nœuds : testez d’abord votre réseau de travail

Singapour, Tokyo, Séoul et Hong Kong proposent chacun deux configurations. La disponibilité affichée en temps réel dans le portail fait foi. La distance géographique n’est qu’un premier repère : le routage de l’opérateur et les horaires de travail de l’équipe comptent aussi.

Singapour

À privilégier pour une première évaluation par les équipes d’Asie du Sud-Est. Testez le bureau avec le réseau réellement utilisé au travail, puis vérifiez les accès au dépôt et le transfert des artefacts.

sg · UTC+8

Tokyo

À envisager pour les équipes du Japon et d’Asie de l’Est. Un fuseau horaire proche ne garantit pas un réseau plus rapide : comparez les performances aux heures de pointe et en dehors.

jp · UTC+9

Séoul

À envisager pour les équipes de Corée et d’Asie du Nord-Est. Pour un runner permanent, surveillez surtout la stabilité des accès au dépôt et aux sources de dépendances.

kr · UTC+9

Hong Kong

À envisager pour les équipes du sud de la Chine et d’Asie du Sud-Est. Si vous partagez un bureau entre plusieurs fuseaux horaires, convenez à l’avance des horaires d’utilisation et de fermeture de la session graphique.

hk · UTC+8

Notez trois indicateurs : latence, stabilité et tâches réelles

Testez l’adresse réelle de l’hôte de votre instance attribuée ; mesurer le domaine du site ne remplace pas un test du nœud. Exécutez les commandes suivantes dans un Terminal Bash local où les variables du nœud sont définies.

ping -c 20 "$NODE_HOST"
ssh -p "$NODE_PORT" "$NODE_USER@$NODE_HOST" 'uptime'

Dans Windows PowerShell, utilisez ping -n 20 <INSTANCE_HOST>. Notez les pertes de paquets et la plage des temps aller-retour, puis effectuez un vrai pull Git ou un transfert d’artefact de build. ICMP peut être filtré par les règles réseau ; si ping ne reçoit aucune réponse, testez tout de même le port SSH séparément.

Répétez les tests sur le réseau et aux horaires habituels de l’équipe. Ce guide ne garantit aucun délai uniforme : les résultats reflètent uniquement le comportement de ce chemin réseau à l’instant du test. Si vous n’avez pas encore loué d’instance, contactez l’assistance par e-mail pour connaître la procédure de test ; n’essayez pas une adresse de nœud supposée.

Rassemblez les notions dans un même tableau

Huit notions de connexion, expliquées simplement

Distinguez les ressources, les protocoles de connexion et l’orchestration des tâches pour diagnostiquer les problèmes sans confondre les différents niveaux.

Nœud physique: Machine Apple Silicon qui exécute macOS. La commande attribue un appareil complet, pas une machine virtuelle sur un hôte partagé.
Dédié: Pendant la durée de location, la machine physique est attribuée à un seul locataire ; le CPU, le GPU et la mémoire unifiée ne sont pas partagés avec d’autres locataires.
VNC: Protocole de transmission de l’écran distant et des entrées clavier-souris. L’état du service, le port et l’authentification doivent être vérifiés séparément.
Screen Sharing: Fonctionnalité et client de partage d’écran de macOS, utilisés pour accéder à une session graphique distante. Ils ne remplacent pas la connexion en ligne de commande par SSH.
Clé SSH: Identifiants constitués d’une clé publique et d’une clé privée. La clé publique peut être enregistrée sur le nœud ; la clé privée reste sur un client protégé.
Runner self-hosted: Agent qui exécute les tâches CI sur votre nœud et utilise les outils, les permissions et les caches de celui-ci.
Connexion Thunderbolt 5: Option à sélectionner pour chaque machine. Elle ne transforme pas plusieurs appareils en un système à mémoire partagée unique ; les logiciels doivent toujours prendre en charge les tâches distribuées.
Mémoire unifiée: Sur Apple Silicon, le CPU et le GPU utilisent le même pool mémoire. Prévoyez donc ensemble la mémoire nécessaire aux builds, aux simulateurs et aux tâches de traitement de modèles.

Sécurisez aussi la connexion

Vérifiez la clé, puis renforcez les accès

Ne modifiez pas l’authentification avant d’avoir vérifié votre unique moyen de connexion. Gardez la session actuelle ouverte et testez la connexion avec la nouvelle clé dans un second Terminal avant d’ajuster les règles du nœud.

Désactivez l’authentification par mot de passe

Vérifiez la configuration de sshd et les fichiers inclus selon la version de macOS. Activez l’authentification par clé publique et désactivez l’authentification par mot de passe et par clavier interactif. Ne modifiez pas un seul paramètre qui pourrait être remplacé par un autre fichier.

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Avant d’appliquer la configuration, vérifiez sa syntaxe avec sudo /usr/sbin/sshd -t, puis procédez comme indiqué pour votre instance.

N’ouvrez que les ports nécessaires

Connectez-vous à SSH sur le port fourni. Pour le bureau graphique, privilégiez un tunnel local et n’exposez pas directement le port 5900 sur Internet. Fermez tout service de test temporaire après usage et vérifiez à la fois son adresse d’écoute et les règles du pare-feu.

lsof -nP -iTCP -sTCP:LISTEN

Un runner se connecte généralement de lui-même au service CI ; n’ouvrez pas pour autant de port d’administration entrant supplémentaire.

Gérez les identifiants par personne et par tâche

Chaque membre doit utiliser sa propre clé publique. Révoquez les accès correspondants lorsqu’une personne quitte l’équipe. Limitez le runner aux tâches de dépôts de confiance et stockez les secrets de projet dans les variables protégées de la plateforme CI, jamais dans un script ou les fichiers du projet.

Si l’empreinte de l’hôte change, vérifiez d’abord si l’instance a été réinstallée. Ne supprimez pas simplement l’ancienne entrée locale pour vous reconnecter.

Dans un ticket, joignez uniquement des logs expurgés, le numéro de commande et les étapes ayant échoué. N’envoyez ni clé privée, ni mot de passe, ni jeton d’inscription.

Isolation et traitement des données Dépanner une connexion

Transformez vos étapes locales en poste de travail distant reproductible

Choisissez un modèle et une durée de location, puis récupérez les identifiants de l’instance. Commencez par vérifier SSH, puis configurez le bureau graphique et la file de builds. Si votre instance rencontre un problème, transmettez un compte rendu expurgé depuis le portail.

Louer un Mac dans le cloud Ouvrir un ticket dans le portail