Guide de connexion à distance

Connectez-vous en toute sécurité à un Mac dans le cloud

Déterminez d’abord si votre tâche nécessite la ligne de commande, un bureau graphique ou une exécution sans intervention, puis vérifiez les identifiants, les outils et les autorisations. VMRunner fournit des nœuds Apple Silicon physiques dédiés, et non des machines virtuelles ; utilisez les informations de connexion de la commande livrée dans le portail.

Louer un Mac dans le cloud Voir le dépannage
Voies de connexion
3 types
Type de livraison
Nœud physique dédié
Disponibilité
365 jours par an
CONNECTION RUN SHEET

Tableau de connexion

À exécuter après livraison du nœud
01
Administration SSH Dépôts, builds, journaux
Recommandé
02
Bureau graphique Xcode, ressources, débogage interactif
À la demande
03
Runner CI Tests, signature, retour des artefacts
Continu
Isolation des identifiants Validé
Empreinte de l’hôte À vérifier localement
Premier build Commencer par une petite tâche

Ne transmettez pas les mêmes identifiants à une session personnelle et à une tâche automatisée. Créez d’abord un compte dédié révocable, puis connectez le Runner.

Choisir le mode de connexion

Répartissez les tâches selon leur nature, sans ouvrir le bureau graphique par défaut

La ligne de commande convient aux opérations fréquentes et scriptables ; réservez la session graphique aux outils interactifs ; confiez les tâches continues à un Runner dédié. Cette séparation clarifie les autorisations et facilite le diagnostic des problèmes de connexion.

Administration en ligne de commande

Convient aux opérations Git, à l’installation de dépendances, à l’analyse des journaux, à l’exécution de scripts et aux builds. La consommation de bande passante est faible et la reprise après interruption est plus simple.

  • Point d’entrée typique : SSH
  • Tâches adaptées : builds et exploitation
  • Autorisations recommandées : authentification par clé

Utilisation du bureau graphique

Convient au débogage dans l’interface Xcode, à l’inspection du simulateur, aux projets audio-vidéo et aux tâches nécessitant de surveiller une fenêtre. Plus la résolution est élevée, plus le réseau local doit être performant.

  • Point d’entrée typique : bureau à distance
  • Tâches adaptées : outils interactifs
  • Autorisations recommandées : compte de session dédié

Exécution CI automatisée

Convient aux tests, à l’archivage, à la signature et au retour des artefacts. Le Runner utilise un compte dédié ; les variables d’environnement sont injectées par tâche et les identifiants ne sont pas partagés avec la session de bureau personnelle.

  • Point d’entrée typique : Runner auto-hébergé
  • Tâches adaptées : pipeline continu
  • Autorisations recommandées : moindre privilège
Vérifications avant connexion

Consignez précisément les informations de livraison et votre référence locale

Lors du diagnostic d’une connexion distante, le temps est le plus souvent perdu non pas à cause d’une panne complexe, mais parce que l’adresse du nœud, l’usage du compte ou la référence réseau locale ne sont pas clairs. Effectuez les relevés suivants avant la première connexion afin d’identifier la couche concernée par tout changement.

Informations de livraison à conserver

Identifiant de commande, ville du nœud, adresse du nœud, usage du compte, résultat de la vérification de l’empreinte de l’hôte et heure de la première connexion réussie. Conservez la clé privée uniquement sur un appareil contrôlé ; ne l’inscrivez ni dans un ticket, ni dans une conversation, ni dans un dépôt de code.

  1. 01

    Confirmer la livraison de la commande

    Vérifiez l’état de la commande et les informations de connexion dans le portail. Avant la livraison, n’essayez pas de vous connecter avec une ancienne adresse ou les informations d’une autre personne.

  2. 02

    Enregistrer l’adresse du nœud et des identifiants distincts

    Utilisez des comptes ou des clés révocables distincts pour les opérations personnelles, les tâches automatisées et la collaboration temporaire ; ne partagez pas un jeu d’identifiants permanent.

  3. 03

    Mesurer la référence réseau locale

    Relevez la latence, les pertes de paquets et la stabilité sur réseau filaire et sans fil. En cas de saccades dans la session graphique, comparez d’abord avec cette référence.

  4. 04

    Planifier les autorisations des comptes

    Le compte de développement reçoit uniquement les droits nécessaires au répertoire de travail ; le compte Runner accède seulement au répertoire de build, au cache et aux ressources de signature nécessaires.

Voie SSH

Vérifiez d’abord l’identité de l’hôte, puis utilisez une clé pour les connexions quotidiennes

Lors de la première connexion, l’objectif n’est pas d’ignorer rapidement l’avertissement, mais de confirmer que l’adresse correspond bien au nœud livré. Après vérification de l’empreinte, configurez un alias, une stratégie de maintien de connexion et un compte aux privilèges minimaux.

ÉTAPE 01

Vérifier l’empreinte de l’hôte

ssh-keyscan -t ed25519 NODE_ADDRESS
ssh USER@NODE_ADDRESS

Comparez l’empreinte relevée pour la première fois avec les informations de livraison du portail. Si l’empreinte change après une modification d’adresse ou une réinstallation du système, vérifiez d’abord la cause ; ne supprimez pas directement l’historique local pour poursuivre la connexion.

ÉTAPE 02

Générer et déployer une clé dédiée

ssh-keygen -t ed25519 -a 64
ssh-copy-id USER@NODE_ADDRESS

Générez une clé distincte pour le nœud VMRunner. Protégez la clé privée par une phrase secrète locale, ne la validez pas dans le dépôt et ne la mélangez pas à la clé de déploiement du Runner.

ÉTAPE 03

Configurer un alias et le maintien de connexion

Host vmrunner-build
  HostName NODE_ADDRESS
  User ACCOUNT_NAME
  IdentityFile ~/.ssh/vmrunner_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

L’alias réduit les erreurs de transcription d’adresse. Les paramètres de maintien détectent uniquement la perte de connexion ; ils ne relancent pas automatiquement un processus interrompu. Confiez les tâches longues à un gestionnaire de tâches ou à un Runner CI.

Limites du moindre privilège

Ne faites pas des privilèges administrateur votre réglage quotidien par défaut. Séparez l’installation des dépendances, la configuration système et l’exécution des pipelines ; après une élévation temporaire, revenez immédiatement aux privilèges ordinaires et consignez les modifications.

Session graphique

Réglez la qualité d’image au strict nécessaire

Le bureau à distance convient aux opérations nécessitant d’afficher Xcode, le simulateur ou une timeline ; il ne doit pas remplacer toutes les tâches en arrière-plan. Commencez par une résolution faible pour établir une session stable, puis augmentez progressivement la qualité.

  • Vérifiez que le service graphique distant est activé sur le nœud livré et limitez les comptes autorisés à se connecter.
  • Testez d’abord avec un seul écran et une résolution faible ; augmentez la configuration après avoir confirmé la stabilité de l’entrée et de l’affichage.
  • Vérifiez la correspondance entre Command, Option, Control et la disposition de votre clavier local afin d’éviter les raccourcis accidentels.
  • Ne transférez via le presse-papiers que le texte nécessaire ; ne copiez ni clé privée, ni jeton complet, ni mot de passe de certificat.
  • Verrouillez la session en partant ; déconnectez-vous activement à la fin de la tâche et ne laissez pas un bureau inutilisé ouvert durablement.

Ordre de réglage de la session graphique

Commencer par la stabilité
01 Résolution

Choisissez d’abord la résolution minimale permettant d’afficher entièrement les fenêtres des outils, puis observez la latence d’entrée et le rafraîchissement.

02 Couleurs et animations

En cas de fluctuation du réseau, réduisez les effets visuels et réservez la bande passante au retour des actions et à la synchronisation des fichiers.

03 Mappage du clavier

Testez les raccourcis courants dans une fenêtre de texte sans risque avant les opérations de signature, de suppression ou de publication.

04 Verrouillage de session

Après une interruption, vérifiez d’abord l’état de l’ancienne session afin d’éviter de relancer des outils ou d’utiliser deux fois le même répertoire de travail.

Parcours de migration

Du Mac local au Mac dans le cloud : trois validations

Ne transférez pas tout le code, les certificats, les caches et les pipelines en une seule fois. Conservez un résultat vérifiable à chaque étape et ne passez à la suivante qu’après validation.

01 · DATA

Synchronisation des données

Synchronisez d’abord le dépôt, les fichiers de verrouillage, les ressources nécessaires et les scripts de build. Les gros caches et dépendances retéléchargeables ne font pas partie de la première migration.

  • Vérifier la branche par défaut et le hash du commit
  • Consigner la version des fichiers de verrouillage des dépendances
  • Comparer les sommes de contrôle des ressources importantes
Résultat : référence de code reproductible dans le cloud
02 · TOOLCHAIN

Installation de la chaîne d’outils

Vérifiez Xcode, les outils en ligne de commande, le gestionnaire de paquets, les certificats et les profils de provisionnement. Exécutez d’abord une petite cible de test, sans lancer directement le pipeline complet de publication.

  • Figer les versions de Xcode et du SDK
  • Confirmer le chemin sélectionné pour les outils en ligne de commande
  • Séparer le cache des dépendances et le répertoire de build
Résultat : inventaire d’environnement validé par un build de test
03 · RUNNER

Connexion CI

Créez un compte Runner dédié, limitez l’accès aux variables d’environnement, exécutez une tâche de test réversible et renvoyez les artefacts.

  • Créer un répertoire de travail distinct pour le Runner
  • Injecter uniquement les variables requises par la tâche en cours
  • Vérifier les journaux, le code de sortie et le hash des artefacts
Résultat : premier pipeline cloud auditable
Vérification de l’environnement

Décrivez l’environnement de développement dans un inventaire, plutôt que de le reconstituer de mémoire

Un même code peut se comporter différemment sur deux Mac, généralement à cause des versions d’outils, des chemins, du cache ou des autorisations. Consignez les éléments suivants avant le premier build officiel.

Élément à vérifier Méthode de vérification Critère de validation
Xcode et SDK xcodebuild -version Versions conformes à la référence du projet
Outils en ligne de commande xcode-select -p Le chemin pointe vers le Xcode cible
Certificats et profils de provisionnement Effectuer un contrôle de signature après masquage des données sensibles Nom de cible et périmètre valide correspondants
Gestionnaire de paquets Consigner la version et l’état du fichier de verrouillage Dépendances installables de façon reproductible
Répertoire de cache Vérifier propriétaire, capacité et règles de nettoyage Tâches personnelles et CI isolées
Répertoire de build Effectuer un build de test après nettoyage Chemin et autorisations des artefacts définis
Connexion CI

Donnez aux tâches automatisées leur propre identité et leur propre répertoire de travail

Le Runner ne doit pas réutiliser le compte de bureau du développeur. Une identité distincte facilite la révocation des droits, le nettoyage du cache et l’identification des problèmes de propriétaire des fichiers, tout en réduisant les interférences de la session personnelle avec le pipeline.

Voir le dépannage CI
  1. 01

    Créer un compte dédié

    Le compte accède uniquement à l’espace de travail du dépôt, au cache des dépendances, au répertoire de build et aux ressources de signature nécessaires ; il ne reçoit pas de privilèges administrateur permanents.

  2. 02

    Enregistrer le Runner

    Utilisez la procédure d’enregistrement fournie par la plateforme de pipeline pour associer le nœud actuel, puis attribuez au Runner des étiquettes identifiant la puce, le système et le type de tâche.

  3. 03

    Injecter des variables contrôlées

    Configurez les variables selon le dépôt, l’environnement et la portée de la tâche. Masquez les valeurs sensibles dans les journaux et n’affichez pas le fichier de configuration complet dans les rapports de build.

  4. 04

    Exécuter un build de test

    Commencez par une cible rapide et peu dépendante, puis vérifiez le code de sortie, les résultats des tests, les succès du cache et le nettoyage du répertoire de travail.

  5. 05

    Renvoyer et vérifier les artefacts

    Consignez le nom de l’artefact, le commit générateur, la somme de contrôle et l’emplacement de conservation. Après confirmation du retour, étendez l’exécution au pipeline complet.

Finalisation sécurisée

Une connexion réussie ne signifie pas que la migration est terminée

Avant la mise en production, vérifiez encore les identifiants, le périmètre de partage, les sauvegardes et les informations de restauration. L’objectif est que chaque compte, session ou tâche automatisée puisse être révoqué séparément.

A

Faire tourner les identifiants initiaux

Après la première vérification, remplacez le mot de passe ou la clé initiaux, supprimez les autorisations temporaires inutiles et consignez l’usage des identifiants ainsi que leur responsable.

B

Limiter les comptes partagés

Chaque utilisateur et chaque Runner utilisent une identité distincte. En cas de changement d’autorisation, révoquez uniquement le compte concerné sans affecter les autres charges de travail.

C

Sauvegarder les données importantes

Le dépôt distant reste la source principale du code. Sauvegardez les éléments de signature, les ressources du projet et les artefacts essentiels selon la stratégie de l’équipe, puis testez régulièrement la restauration.

D

Déconnecter les sessions inactives

Verrouillez et fermez les sessions graphiques inutilisées, arrêtez les services temporaires et vérifiez que les tâches en arrière-plan ont toujours un responsable clairement défini.

E

Conserver les informations de restauration

Consignez l’identifiant de commande, la ville du nœud, l’usage du compte, les versions des outils et le dernier build fonctionnel afin de permettre un diagnostic rapide par le support.

Préparez des informations reproductibles avant de demander de l’aide

Transmettez l’identifiant de commande, la ville du nœud, l’heure de l’incident, les étapes de reproduction, les journaux masqués et le résultat attendu. N’envoyez ni clé privée, ni jeton d’accès complet, ni mot de passe de certificat, ni fichier de configuration non masqué.

Voir les voies de contact
Prêt à commencer

Après avoir choisi un nœud, validez toute la chaîne de connexion avec un petit build

Vérifiez d’abord les identifiants, consignez les versions des outils et renvoyez les artefacts de test, puis migrez le projet officiel vers un nœud Apple Silicon physique dédié.

Louer un Mac dans le cloud Voir les trois formules