VNC et SSH : connecter un Mac dans le cloud

Avant de commencer

Vérifiez d’abord six conditions de connexion

Ne commencez pas par réessayer sans cesse le mot de passe. Vérifiez d’abord le nœud, la région, les identifiants et votre réseau local afin de distinguer rapidement un problème de livraison, d’authentification ou de liaison réseau.

État du nœud

Connectez-vous à la console pour confirmer que l’instance est disponible et notez son ID. Tant que le nœud s’initialise, n’enregistrez pas une empreinte hôte qui n’a pas encore été vérifiée.

Se connecter lorsque l’état est normal

Région du nœud

Vérifiez que la région de la commande et celle de l’instance correspondent. Le catalogue actuel couvre Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong, l’est des États-Unis et l’ouest des États-Unis.

Région / ID du nœud

Nom d’utilisateur et identifiants temporaires

Copiez intégralement le nom d’utilisateur fourni dans la console en respectant la casse. Après la première connexion, modifiez immédiatement le mot de passe temporaire et configurez en priorité l’authentification SSH par clé.

Ne transférez pas les identifiants par e-mail classique

Réseau local

Effectuez d’abord le test sur une connexion filaire stable ou un Wi-Fi fiable. Les proxys d’entreprise, réseaux invités et hotspots publics peuvent limiter les ports nécessaires à SSH ou VNC.

Écartez d’abord l’influence du VPN et des règles de proxy

Pare-feu du système

Vérifiez que le pare-feu local autorise les connexions sortantes du client utilisé. Depuis un réseau professionnel, demandez à l’administrateur réseau de contrôler les règles appliquées à l’adresse et au port de destination.

SSH 22 / VNC 5900

Cohérence des informations de connexion

Comparez l’adresse hôte, le port, le nom d’utilisateur et la région. Ne réutilisez pas directement la configuration client d’un ancien nœud pour un nouveau nœud physique attribué.

Créez une nouvelle configuration de connexion pour le nouveau nœud

Limites de sécurité

Lisez les paramètres de connexion uniquement dans la console. Ne transmettez pas de clé privée, de mot de passe complet, de jeton d’accès ni de journal de build non anonymisé dans des documents généraux ou des dépôts de code.

Interface graphique

Établissez votre première connexion graphique avec VNC

VNC convient à l’interface graphique Xcode, à la vérification des archives signées et aux tâches nécessitant une interaction avec le bureau. Lors de la première connexion, configurez successivement l’adresse, l’authentification, la qualité d’affichage et la fermeture de session.

01

Saisissez l’adresse et le port fournis par la console

Créez une nouvelle connexion dans le client VNC et copiez l’adresse hôte caractère par caractère. Si la console fournit un port personnalisé, utilisez-le sans le deviner ni reprendre les paramètres d’une ancienne instance.

Point de contrôle :L’étiquette de région de la configuration client doit correspondre à la région de la commande.
02

Authentifiez-vous avec le nom d’utilisateur du nœud

Saisissez le nom d’utilisateur du nœud et les identifiants temporaires fournis par la console. Après plusieurs échecs, arrêtez les tentatives, recopiez le nom d’utilisateur et vérifiez la disposition du clavier afin d’éviter une restriction de sécurité due aux erreurs répétées.

Point de contrôle :Vérifiez qu’aucun espace ni saut de ligne n’a été copié avant ou après les identifiants.
03

Ajustez la qualité d’affichage selon la liaison

Commencez par une résolution adaptative et une qualité de couleur moyenne pour établir une base stable. Sur une liaison intercontinentale, réduisez la résolution, la profondeur des couleurs et la fréquence de rafraîchissement, puis augmentez progressivement la qualité.

Point de départ conseillé :1920 × 1080, zoom à 100 %, qualité dynamique activée.
04

Testez d’abord le presse-papiers avec du contenu non sensible

Copiez un texte ordinaire et vérifiez que le presse-papiers bidirectionnel local et distant fonctionne comme prévu. N’utilisez pas de mot de passe, de clé privée ni de jeton d’accès pour tester cette fonction.

Limite :Dans un environnement partagé en équipe, désactivez la synchronisation du presse-papiers si nécessaire.
05

Fermez la session sans interrompre directement les tâches

Avant de fermer la fenêtre, vérifiez si le build s’exécute au premier plan. Confiez les tâches persistantes à un CI runner, à launchd ou à un gestionnaire de sessions terminal afin qu’une déconnexion VNC n’arrête pas le processus au premier plan.

Point de contrôle :Après la fermeture, vérifiez dans la console que le nœud fonctionne toujours normalement.

Accès en ligne de commande

Utilisez SSH pour créer un point d’accès de développement auditable

SSH convient à la synchronisation des dépôts, à l’installation des dépendances, aux builds automatisés et à la collecte des journaux. Lors de la première connexion, ne cherchez pas seulement à ignorer l’avertissement : vérifiez l’empreinte hôte et limitez les privilèges à long terme.

Arrêtez-vous immédiatement si l’empreinte ne correspond pas

Ne supprimez pas directement l’enregistrement local pour poursuivre la connexion. Vérifiez d’abord si le nœud a été réinstallé, réattribué ou si son adresse a changé, puis faites confirmer la situation via un ticket dans la console.

01

Vérifiez l’empreinte hôte

Lors de la première connexion, comparez segment par segment l’empreinte affichée dans le terminal avec celle fournie par la console. Si l’adresse du nœud est identique mais que l’empreinte a changé, traitez cela comme un incident de sécurité au lieu d’ignorer l’avertissement.

02

Privilégiez la connexion par clé

Utilisez une clé publique distincte pour chaque membre et chaque tâche automatisée. Conservez les clés privées sur des appareils contrôlés ou dans un système de gestion des clés, et ne les téléversez pas dans un répertoire partagé du nœud.

03

Limitez les droits sur les fichiers et les commandes

Configurez les permissions de la clé privée pour que seul l’utilisateur courant puisse la lire. Accordez aux tâches CI uniquement les droits nécessaires aux répertoires et commandes de build ; n’utilisez pas les privilèges d’administration par défaut.

04

Modifiez le mot de passe temporaire

Après la première connexion, définissez immédiatement un mot de passe unique et robuste. Vérifiez que la connexion par clé fonctionne, puis limitez l’authentification par mot de passe selon la politique de l’équipe, sans désactiver d’abord l’unique accès disponible.

Générez une clé SSH dédiée

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/hexvm_node
chmod 600 ~/.ssh/hexvm_node
ssh-add ~/.ssh/hexvm_node

Générez des clés distinctes pour les membres, le CI runner et les opérations temporaires afin de pouvoir les révoquer séparément.

Établissez la première connexion

ssh-keyscan -p "$NODE_PORT" "$NODE_HOST"
ssh -i ~/.ssh/hexvm_node \
  -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"

Vérifiez d’abord l’empreinte affichée, puis acceptez l’enregistrement de l’hôte. Copiez les valeurs des variables depuis la console et ne transmettez pas d’identifiants réels dans le script.

Validation de la chaîne d’outils de développement

De la connexion SSH à la réussite de l’archivage

Une fois la connexion établie, vérifiez l’environnement à l’aide des commandes de version, d’un build de test et d’une commande d’archivage. Commencez par des contrôles ciblés avant d’intégrer le pipeline complet.

hexvm-node — zsh — 120 × 34 SSH

$ssh -i ~/.ssh/hexvm_node "$NODE_USER@$NODE_HOST"

Authenticated with public key.

Last login: current session from approved network

$sw_vers && xcodebuild -version

ProductName: macOS

Xcode 16.x

$xcodebuild test -scheme MobileApp -destination 'platform=macOS'

** TEST SUCCEEDED **

$bundle exec fastlane archive

Resolving signing settings...

Exporting archive artifact...

Archive completed successfully

Vérifiez d’abord les versions

Notez les versions de macOS, Xcode et des outils en ligne de commande afin que le terminal interactif et le CI runner utilisent la même sélection de chaîne d’outils.

Exécutez ensuite le test minimal

Lancez d’abord un seul scheme ou une seule cible de test pour isoler les problèmes de dépendances, de signature et de variables d’environnement, puis élargissez au workspace complet.

Intégrez enfin l’archivage

Après la réussite de l’archivage, vérifiez le chemin de l’artefact, les permissions des fichiers et les règles d’anonymisation des journaux avant de migrer la commande vers le pipeline automatisé.

Référence de latence réseau

Latence aller-retour médiane des six régions de nœuds

Ces données servent à présélectionner une région et ne représentent pas un résultat fixe pour chaque réseau. Avant de choisir, répétez les tests depuis votre réseau professionnel réel et la sortie CI.

Période de test Jours ouvrés, heure locale 14:00–16:00

Référence réseau Connexion fixe locale, VPN et proxy désactivés

Méthode statistique Médiane de 20 allers-retours ICMP par chemin

Unité ms

Latence réseau médiane entre les principaux points de test client et les six régions de nœuds HexVM
Point de test client	Singapour	Japon (Tokyo)	Corée du Sud (Séoul)	Hong Kong	Est des États-Unis	Ouest des États-Unis
Connexion fixe à Pékin	78 ms	54 ms	47 ms	42 ms	198 ms	146 ms
Connexion fixe à Shanghai	69 ms	41 ms	49 ms	35 ms	190 ms	132 ms
Connexion fixe à Taipei	48 ms	32 ms	43 ms	24 ms	181 ms	112 ms
Connexion fixe à Manille	39 ms	71 ms	76 ms	36 ms	214 ms	139 ms
Connexion fixe à Los Angeles	177 ms	104 ms	119 ms	151 ms	68 ms	21 ms
Connexion fixe à New York	231 ms	168 ms	181 ms	205 ms	19 ms	73 ms

< 60 ms

Adapté aux opérations graphiques continues

La saisie au clavier, le changement de fenêtre et les opérations Xcode courantes sont généralement fluides ; surveillez néanmoins les pertes de paquets et la gigue.

60–140 ms

Adapté aux builds et aux interactions légères

Après réduction de la qualité d’affichage, les opérations graphiques restent possibles ; les builds en ligne de commande, la consultation des journaux et les tâches CI sont généralement peu affectés.

> 140 ms

Privilégiez la ligne de commande et l’automatisation

Sur une liaison intercontinentale, confiez le travail continu à SSH, au CI runner et aux tâches en arrière-plan ; utilisez VNC uniquement pour les vérifications nécessaires.

La latence réelle dépend de l’opérateur local, de la sortie internationale, des changements de routage, du proxy professionnel, de la qualité du Wi-Fi et du trafic au même moment. Les combinaisons courantes du catalogue régional sont disponibles à la commande ; la disponibilité effective est indiquée en temps réel dans la console.

Optimisation de l’expérience

Stabilisez la session à distance au lieu de rechercher la qualité d’image maximale

Séparez les tâches interactives, les tâches continues et les transferts volumineux afin de limiter l’impact de la gigue réseau sur les builds.

01

Commencez par une résolution sur un seul écran

Commencez avec un seul écran 1920 × 1080 pour établir une base stable. Sur une liaison à forte latence, n’activez pas directement le double écran, un zoom élevé ni des ajustements dynamiques fréquents.

Si le texte est trop petit, ajustez d’abord le zoom du système sans augmenter inutilement la résolution.
Sur réseau mobile, privilégiez une taille de fenêtre fixe afin de limiter les redessinages répétitifs.

02

Choisissez la qualité des couleurs selon la liaison

L’édition de code, les journaux de build et la configuration ne nécessitent pas la précision maximale des couleurs. Lorsque la liaison fluctue, réduisez d’abord la profondeur des couleurs et la qualité d’image, puis observez le délai de saisie.

Vous pouvez augmenter temporairement la qualité pour les contrôles de design et les tâches vidéo.
Pour le développement courant, privilégiez la compression adaptative et un arrière-plan statique.

03

Désactivez les transmissions audio et vidéo inutiles

Le développement à distance repose principalement sur le code, le terminal et l’état des builds. Désactivez l’audio, la redirection de caméra et les animations inutilisés pour réduire la consommation de bande passante.

Évitez de lire des médias à haut débit dans une session VNC.
Désactivez les effets dynamiques du bureau et les fenêtres de supervision qui se rafraîchissent en continu.

04

Sortez les tâches continues de la session interactive

Les builds, tests et téléchargements de dépendances longs doivent s’exécuter dans une session terminal indépendante, un CI runner ou une tâche système. Une déconnexion VNC ou SSH ne doit pas arrêter directement la tâche.

Écrivez les journaux dans un fichier dédié et consignez le code de sortie.
Après reconnexion, vérifiez d’abord l’état du processus et ne relancez pas le même build.

05

Utilisez un transfert reprenable pour les fichiers volumineux

Utilisez pour les dépôts, caches et artefacts de build un mode de transfert prenant en charge l’incrémentiel et la vérification. Ne transférez pas de gros fichiers via le presse-papiers graphique et ne placez pas d’artefacts sensibles dans un emplacement public.

Compressez les nombreux petits fichiers avant le transfert afin de réduire les allers-retours.
Après le transfert, vérifiez la taille, le condensat et les permissions d’accès des fichiers.

06

Placez les caches au bon endroit

Isolez les caches de dépendances et DerivedData par projet, branche ou version de la chaîne d’outils. Si le taux de réussite baisse, analysez d’abord les clés de cache au lieu d’augmenter indéfiniment l’espace disque utilisé.

Supprimez régulièrement les caches invalides et les anciennes archives.
En cas de manque d’espace disque, localisez d’abord les répertoires volumineux avant toute suppression.

Diagnostic des problèmes

Réduisez le périmètre du problème de connexion à partir des symptômes

Ne modifiez qu’une variable à la fois et consignez l’ID du nœud, la région, l’heure de l’incident et le texte complet de l’erreur. Vous pourrez ainsi déterminer si le problème vient du poste local, du réseau, de l’authentification ou du nœud.

Délai d’attente : le client ne répond pas pendant une longue période

Dans la console, vérifiez que l’état du nœud et l’adresse de connexion n’ont pas changé.
Vérifiez le port, puis testez à nouveau après avoir temporairement désactivé le VPN ou le proxy local.
Testez séparément depuis le réseau domestique et un hotspot mobile afin de déterminer si le réseau professionnel limite les connexions sortantes.
Notez l’heure du délai d’attente, la région, le réseau client et le port cible, puis envoyez un ticket depuis la console.

Échec de l’authentification : nom d’utilisateur, mot de passe ou clé refusé

Recopiez le nom d’utilisateur fourni par la console et vérifiez la casse ainsi que les espaces en début et en fin.
Vérifiez que vous utilisez les identifiants du nœud actuel, et non le mot de passe ou la clé enregistrés pour une ancienne instance.
En cas d’échec de la clé SSH, vérifiez le chemin de la clé privée, ses permissions et la configuration de la clé publique correspondante.
Après plusieurs échecs, arrêtez les tentatives et demandez une vérification via un ticket dans la console ; n’envoyez pas d’identifiants complets par e-mail.

Affichage saccadé : connexion établie mais saisie très lente

Passez à un seul écran 1920 × 1080, puis désactivez la qualité de couleur élevée et les transmissions audio et vidéo.
Vérifiez le signal Wi-Fi local, les pertes de paquets et les téléchargements en arrière-plan ; privilégiez une connexion filaire.
Comparez la réactivité de VNC et de SSH ; si SSH fonctionne normalement, ajustez en priorité l’encodage graphique et les paramètres d’affichage.
Sur une liaison intercontinentale, exécutez les builds longs en arrière-plan et utilisez VNC uniquement pour vérifier les écrans essentiels.

Changement d’empreinte hôte : SSH affiche un avertissement d’identité

Arrêtez immédiatement la connexion et n’utilisez pas directement une commande qui ignore la vérification.
Vérifiez si le nœud a été réattribué ou réinstallé, ou si l’adresse de connexion provient d’une ancienne configuration.
Récupérez à nouveau l’empreinte actuelle dans la console et comparez-la segment par segment.
Si vous ne pouvez pas confirmer la cause, envoyez un ticket dans la console avec l’ID du nœud, la région et le texte d’avertissement anonymisé.

Port inaccessible : le test réseau renvoie immédiatement un refus

Vérifiez que le protocole et le port correspondent ; ne saisissez pas le port SSH dans le client VNC.
Contrôlez le pare-feu local, les règles de sortie de l’entreprise et celles des logiciels de sécurité.
Testez la même adresse et le même port depuis un autre réseau indépendant afin de déterminer s’il s’agit d’un problème de routage lié à un opérateur.
Si plusieurs réseaux restent inaccessibles, envoyez un ticket dans la console en précisant les résultats des tests et l’étendue de l’impact.

Informations à préparer avant d’envoyer un ticket

ID du nœud Région du nœud Heure du problème Type de réseau local Client et version Étapes complètes de reproduction Journaux d’erreur anonymisés Étendue de l’impact

Ne transmettez pas de clé privée, de mot de passe complet, de jeton d’accès ni de journal contenant des éléments sensibles de signature. Pour obtenir de l’aide, connectez-vous à la console pour envoyer un ticket ou écrivez à support@hexvm.com.

Envoyer un ticket depuis la console Consulter le centre d’aide

Nœuds Apple Silicon dédiés

Choisissez votre Mac dédié et commencez à vous connecter en environ 4 minutes

Chaque commande correspond à un nœud physique Mac mini dédié, et non à une machine virtuelle. Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong, l’est des États-Unis et l’ouest des États-Unis fonctionnent normalement 365 jours par an.

Tous les frais sont facturés en dollars américains (USD). La disponibilité effective du nœud et de la région est indiquée en temps réel dans la console.

Louer un Mac dédié maintenant Voir les offres de location