Guide d’accès à distance

Connectez-vous à un Mac dans le cloud et validez son fonctionnement

SSH gère la ligne de commande, l’automatisation et les builds ; VNC sert aux opérations graphiques. Vérifiez d’abord les informations du nœud et son empreinte, puis ouvrez la session, contrôlez la chaîne d’outils et consignez les résultats.

Louer un Mac cloud Voir le centre d’aide

Ligne de commande: SSH et authentification par clé
Bureau graphique: VNC et presse-papiers contrôlé
Objectifs de validation: Connexion, outils, tâche, déconnexion

Avant la connexion READY / VERIFY

Informations du nœud Nom d’hôte, port, utilisateur Obtenu

Éléments d’identité Clé privée ou identifiants temporaires Conservés localement

Vérification de confiance Vérifier l’empreinte de l’hôte Obligatoire

Première validation Terminal, bureau, tâche de build Résultats consignés

Ne copiez pas l’empreinte de l’hôte depuis une conversation ou une source inconnue. Fiez-vous aux informations renvoyées par la commande actuelle dans la console.

Choisir le mode de connexion

Choisissez SSH ou VNC selon la tâche

Les deux modes se connectent au même Mac physique dédié, mais répondent à des besoins différents. Privilégiez SSH pour l’automatisation ; utilisez VNC pour vérifier l’interface graphique, la résolution ou les applications de bureau.

Ligne de commande et automatisation

SSH : le choix privilégié pour les builds, scripts et runners

Idéal pour Git, les outils en ligne de commande Xcode, Fastlane, l’installation de dépendances, la collecte de journaux et les tâches de runner self-hosted. Préparez un client SSH local, une clé privée protégée, le nom d’hôte, le port, l’utilisateur et l’empreinte fiable du nœud.

Le fichier de clé privée est lisible uniquement par l’utilisateur actuel
Le réseau local autorise l’accès au port renvoyé par la commande
Vérifier l’empreinte via un canal indépendant avant la première connexion
Utiliser une clé dédiée pour l’automatisation et en limiter l’usage

Opérations sur le bureau graphique

VNC : vérifier les applications et l’environnement d’affichage

Idéal pour utiliser l’interface graphique macOS, vérifier la disposition du clavier, confirmer la résolution et valider les tâches nécessitant une session de bureau. Préparez un client VNC fiable, l’adresse du nœud, les identifiants temporaires et une politique claire pour le presse-papiers.

Un appareil partagé ne doit pas enregistrer le mot de passe de connexion
Définir une résolution adaptée à la charge de travail
Désactiver la synchronisation inutile des fichiers et du presse-papiers
Vérifier le verrouillage en veille et le comportement après reconnexion

Procédure de première connexion

Du nœud au relevé de validation, en quatre étapes

Ne sautez pas la vérification de l’empreinte de l’hôte. Une connexion réussie prouve seulement que le chemin est accessible ; vérifiez séparément les outils, les droits sur les répertoires et la procédure de déconnexion.

01 Récupérer les informations du nœud

Ouvrez la commande actuelle dans la console et notez le nom d’hôte, le port, l’utilisateur, les identifiants temporaires ou les indications de clé, ainsi que l’empreinte renvoyée par le système.
Validation : les champs proviennent de la même commande et le nœud correspond à la durée de location
02 Vérifier l’empreinte indépendamment

Lors de la première connexion SSH, comparez chaque segment de l’empreinte avec les informations de la console. En cas de divergence, arrêtez la connexion ; ne contournez pas l’alerte et n’effacez pas l’historique.
Validation : l’algorithme et le texte de l’empreinte correspondent exactement
03 Ouvrir la session et mettre à jour les identifiants

Après la première connexion, modifiez les identifiants temporaires selon les instructions de livraison, enregistrez votre clé publique et supprimez les éléments d’accès temporaires devenus inutiles.
Validation : la nouvelle session fonctionne et les anciens éléments temporaires ne sont plus utilisés
04 Consigner les résultats de validation

Vérifiez la version du système, la version de Xcode, l’espace disque et l’écriture dans le répertoire de travail, puis exécutez une petite tâche de build reproductible et terminez-la normalement.
Validation : la connexion, les outils, l’écriture, la tâche et la sortie produisent tous un résultat

Exemple de validation dans le terminal

Vérifier SSH, Xcode et Fastlane avec une session reproductible

Le nom d’hôte, l’utilisateur et le nom de la tâche ci-dessous sont des exemples. Lisez toujours les paramètres réels dans la console ; n’inscrivez pas de données d’accès de production dans un script, un journal de build ou un ticket.

armcli-session — verification

$ ssh -p 22022 developer@host.example
The authenticity of host cannot be established.
ED25519 key fingerprint is SHA256:<compare-with-console>
Are you sure you want to continue connecting (yes/no)? yes
Last login: current session

developer@cloud-mac % xcodebuild -version
Xcode 16.x
Build version 16X000

developer@cloud-mac % fastlane test
[✓] Préparation de l’environnement de build
[✓] Résolution des dépendances du projet
[✓] Tâche de test terminée

developer@cloud-mac % exit
Connection to host.example closed.

Point de contrôle : empreinte vérifiée Xcode est accessible Tâche terminée correctement Session fermée

Vérification de la connexion au bureau

VNC est disponible, mais cela ne garantit pas un bureau prêt à travailler

Après l’accès initial au bureau graphique, vérifiez dans cet ordre l’affichage, la saisie, les échanges de données et la reprise de session. Chaque point doit rester reproductible après déconnexion et reconnexion.

Résolution et mise à l’échelle

Choisissez une résolution qui affiche entièrement les barres d’outils et les boîtes de dialogue. Ne vérifiez pas seulement la netteté du bureau : ouvrez aussi les outils de développement réels pour vous assurer que le texte, les volets et les fenêtres ne sont pas tronqués.

Disposition du clavier

Dans une zone de texte ordinaire, testez les lettres, chiffres, symboles et raccourcis courants. Si les dispositions locale et distante diffèrent, uniformisez-les avant de modifier du code ou de saisir des commandes.

Politique du presse-papiers

Activez la synchronisation du presse-papiers uniquement si la tâche l’exige. Ne copiez ni clé privée, ni jeton, ni variables d’environnement complètes ; sur un appareil partagé, désactivez la synchronisation bidirectionnelle et effacez l’historique.

Verrouillage en veille

Vérifiez que le bureau se verrouille lorsque vous quittez l’appareil. Sur un terminal partagé, verrouillez-le activement après usage ; ne comptez pas sur la coupure réseau pour protéger la session.

Reconnexion après coupure

Déconnectez-vous volontairement puis reconnectez-vous pour vérifier que l’état de la session est conforme. Pour les builds longs, utilisez un gestionnaire de tâches capable de séparer la tâche de la connexion interactive.

Nettoyage d’un appareil partagé

Après la déconnexion, supprimez les hôtes enregistrés, les identifiants mis en cache et les téléchargements temporaires. Vérifiez séparément le navigateur, le client VNC et le gestionnaire de mots de passe.

Pratique des tunnels SSH

Ne transférez que le port local nécessaire à la tâche

La redirection de port locale permet aux outils locaux d’accéder à un service distant via SSH, sans exposer son adresse d’écoute à un réseau plus vaste. Le port, la cible et la durée doivent être clairement délimités.

Ouverture minimale :Le service distant doit de préférence écouter sur l’adresse de bouclage ; ne transférez que le port utilisé par la tâche actuelle.
Maintien explicite :Pour les tâches longues, configurez un intervalle de maintien raisonnable et un nombre maximal d’échecs afin d’éviter qu’une session interrompue reste bloquée indéfiniment.
Clé distincte :Utilisez une clé dédiée pour les tunnels automatisés ; ses droits et son usage doivent pouvoir être révoqués séparément, sans la mélanger aux clés d’interaction courantes.
Révoquer après la tâche :À la fin de la redirection, arrêtez le processus, révoquez la clé publique inutilisée et vérifiez que le port local n’est plus en écoute.

Exemple de redirection de port local LOCAL ONLY

ssh \
  -L 127.0.0.1:9000:127.0.0.1:9000 \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -p 22022 \
  developer@host.example

Écoute locale: 127.0.0.1:9000
Cible distante: 127.0.0.1:9000
Procédure de sortie: Terminez normalement la session SSH et confirmez la fermeture du port

Intégration CI/CD

Commencez par faire exécuter au runner un pipeline de test minimal

Lors de l’intégration à GitLab CI ou à un autre système, ne migrez pas directement le flux de production complet. Enregistrez d’abord le runner, définissez ses tags, vérifiez les droits des répertoires, puis lancez une petite tâche de test sans données sensibles.

Enregistrer le runner

Utilisez une identité de service dédiée, puis notez le nom du runner, l’exécuteur, le répertoire de travail et le projet associé. N’utilisez le jeton d’enregistrement que lors des étapes nécessaires et ne l’écrivez pas dans le dépôt.

Résultat : runner en ligne

Ajouter des tags explicites

Les tags doivent décrire les capacités réelles, comme macOS, arm64 et l’usage du projet. Évitez les tags par défaut trop génériques afin que les tâches sans rapport ne soient pas planifiées sur ce nœud.

Résultat : tâche associée avec précision

Vérifier le répertoire de travail

Contrôlez les droits de lecture et d’écriture des clones, caches, artefacts de build et répertoires temporaires. L’identité de la tâche ne doit pas obtenir de privilèges système dépassant ceux nécessaires au répertoire de travail.

Résultat : lecture et écriture du répertoire contrôlées

Exécuter la première tâche

Pour le premier passage, limitez-vous à l’affichage de l’environnement, à la résolution des dépendances et à un petit test. Vérifiez le code de sortie, l’intégrité des journaux, le chemin du cache et le nettoyage en cas d’échec.

Résultat : tâche reproductible

Relevé de validation initiale du runner
Point de contrôle	Méthode d’exécution	Condition de réussite	Vérifier d’abord en cas d’échec
Architecture et système	uname -m	La sortie correspond au tag de la tâche	Tags du runner et nœud d’exécution
Chaîne d’outils Xcode	xcodebuild -version	Version lisible, code de sortie 0	Chemin de la commande et environnement de la tâche
Répertoire de travail	Créer, lire puis supprimer un fichier de test	Seul le répertoire cible est accessible en lecture-écriture selon le besoin	Propriétaire et droits du répertoire
Comportement du cache	Exécuter deux fois le même test	Les accès au cache sont explicables et ne mélangent pas les projets	Clé du cache et stratégie de nettoyage

Dépannage des problèmes de connexion

Du DNS au réseau local, réduisez progressivement le périmètre

Ne vérifiez qu’une variable à la fois. Ne changez pas simultanément le nom d’hôte, le port, la clé et le réseau ; sinon, même après rétablissement, la cause racine restera incertaine.

DNS et nom d’hôte

Vérifiez que vous utilisez le nom d’hôte actuellement renvoyé par la console et que la résolution reste stable. Ne copiez pas l’adresse depuis un ancien ticket ou un script historique.

Résolution

Port de connexion

Vérifiez le numéro du port et le protocole, puis testez l’accessibilité du port cible depuis le réseau local. Si le réseau de l’entreprise impose des restrictions, effectuez un contre-test sur un autre réseau de confiance.

Accessibilité du port

Clé et droits du fichier

Vérifiez le fichier de clé réellement chargé par le client, ses droits et la clé publique correspondante. Si vous activez les journaux détaillés, masquez d’abord les données sensibles, puis examinez l’ordre d’authentification.

Phase d’authentification

Empreinte de l’hôte

Si l’empreinte change, arrêtez la connexion et revérifiez les informations du nœud. Ne supprimez pas simplement l’historique des hôtes connus pour poursuivre la connexion.

Vérification de confiance

Sessions et ressources occupées

Vérifiez la présence d’une session de bureau non fermée, d’une tâche longue ou d’une redirection de port locale. Contrôlez d’abord l’état de la tâche avant de décider d’arrêter un processus.

État de la session

Réseau local

Enfin, vérifiez le proxy, le pare-feu, le VPN, la qualité du Wi-Fi et la politique de sortie. Recommencez avec un réseau de remplacement fiable pour distinguer un problème local d’un problème du nœud.

Périmètre réseau

Préparez ces informations avant d’ouvrir un ticket

Identifiant du nœud, heure du problème, mode de connexion, structure complète de la commande, résumé de l’erreur, étapes déjà tentées et journaux dépersonnalisés. Supprimez la clé privée, les jetons, les mots de passe, l’empreinte complète et les données métier avant l’envoi.

Ouvrir la console pour envoyer un ticket Contacter l’équipe de service

Checklist de fin

Avant de terminer, clôturez l’accès, les données et la durée de location

Fermer la fenêtre distante ne suffit pas. Quittez les sessions, révoquez les éléments d’accès, supprimez les fichiers sensibles, vérifiez les sauvegardes et contrôlez la durée de la commande.

01 Fermer toutes les sessions
Terminez les sessions SSH, VNC, de redirection de port locale et d’interaction avec le runner ; vérifiez qu’aucun processus de test ni port en écoute ne subsiste.
02 Révoquer les clés inutilisées
Supprimez les clés publiques temporaires, les identifiants de test du runner et les éléments d’accès ponctuels ; chaque élément conservé doit avoir un responsable et un usage ultérieur clairement définis.
03 Nettoyer le cache et les fichiers sensibles
Vérifiez l’historique du shell, les répertoires temporaires, les journaux de build, les téléchargements, l’historique du presse-papiers et les fichiers de configuration de l’espace de travail ; supprimez ce qui ne doit pas être conservé.
04 Vérifier que la sauvegarde est lisible
Confirmez que le code et les artefacts nécessaires ont été exportés, puis effectuez une vérification de lecture dans un emplacement indépendant. Ne considérez pas l’unique copie présente sur le nœud comme une sauvegarde.
05 Vérifier la durée et l’état de la commande
Confirmez dans la console la date d’expiration, le renouvellement et l’historique du service. Si vous devez poursuivre, vérifiez d’abord la durée avant de planifier les prochains builds.

Prêt à commencer

Louez un Mac physique dédié, puis suivez ce guide pour le connecter

Trois configurations disponibles couvrent les builds en ligne de commande, le bureau graphique, les runners CI/CD et les tâches parallèles. L’état réellement disponible est celui renvoyé en temps réel par la console.

SSH et VNC Nœud physique dédié Fonctionnement continu 365 jours par an

Louer un Mac cloud Voir les offres de location