Guide d’accès distant SSH et VNC

Choisissez d’abord le mode de connexion

Choisissez selon l’interaction requise, pas selon le nom de l’outil

Un même Mac dans le cloud peut gérer des tâches en ligne de commande et des tâches graphiques simultanément. La méthode la plus fiable consiste à confier les tâches longues et le diagnostic à SSH, et les opérations nécessitant le bureau à VNC.

Faible coût d’interaction

SSH : builds, automatisation et journaux

Idéal pour exécuter xcodebuild, fastlane, l’installation des dépendances, la synchronisation des dépôts, la vérification des journaux et les scripts en arrière-plan. En cas de brève instabilité réseau, utilisez un outil de maintien de session pour poursuivre la tâche distante.

Idéal pour: Commandes, scripts et builds continus
Avantage: Faible consommation de bande passante, diagnostic complet
Limite: N’offre pas d’interface graphique macOS

Bureau complet

VNC : Xcode, montage et opérations visuelles

Utilisez-le pour l’interface graphique Xcode, les simulateurs, la gestion des ressources, les timelines de montage et toute tâche nécessitant de voir l’état du bureau. Si la latence est élevée, réduisez d’abord la qualité d’image et la résolution plutôt que de vous reconnecter sans cesse.

Idéal pour: Développement graphique, montage et vérification interactive
Avantage: Contrôle complet du bureau macOS distant
Limite: Plus sensible à la latence, aux variations et à la bande passante

Configuration SSH

Vérifiez cinq paramètres avant la première connexion

Ne réutilisez pas l’adresse ou le port d’une autre commande. Fiez-vous toujours aux données de connexion affichées dans la console pour le service actuel.

01

Lire l’hôte et le port

Dans les détails du service actuel, copiez l’adresse de l’hôte et le port SSH. L’adresse, le port et le nœud définissent ensemble la cible ; vérifiez-les à nouveau après tout changement de nœud ou de service.

02

Confirmer le nom d’utilisateur distant

Le nom d’utilisateur doit correspondre exactement aux données de connexion. N’utilisez pas le nom de votre ordinateur local, un compte de dépôt ou le nom d’un membre de l’équipe dans la commande SSH.

03

Restreindre les permissions de la clé

Le fichier de clé privée doit être lisible uniquement par l’utilisateur local actuel. Sur macOS ou Linux, exécutez chmod 600 ~/.ssh/lemonvm_key, puis utilisez -i pour désigner le fichier.

04

Vérifier l’empreinte initiale

Lors de la première connexion, comparez l’empreinte de l’hôte avec celle affichée dans la console. N’écrivez l’information dans known_hostsqu’après avoir confirmé qu’elle correspond ; ne passez pas directement cette vérification.

05

Enregistrer une configuration réutilisable

Ajoutez Host, HostName, User, Port et IdentityFile à la configuration SSH locale pour réduire les erreurs de saisie, mais n’insérez jamais le contenu de la clé privée dans le fichier de configuration.

Format de commande

ssh -i ~/.ssh/lemonvm_key -p PORT UTILISATEUR@HOTE

Configuration VNC

Établissez une session fonctionnelle avant d’améliorer progressivement la qualité

Pour la première connexion, commencez avec une qualité d’image moyenne et une résolution réduite. Après avoir vérifié la saisie, le presse-papiers et le changement de fenêtre, ajustez les paramètres d’affichage selon la marge disponible sur la connexion.

01

Saisir l’adresse

Utilisez l’hôte et le port VNC fournis par la console ; ne réutilisez pas le port SSH. Si le client exige une adresse combinée, saisissez l’hôte et le port selon son format.

02

Commencer avec une qualité moyenne

Privilégiez la réactivité de la souris, du clavier et des fenêtres. Une fois la lisibilité suffisante, augmentez la couleur et la qualité d’image afin de ne pas saturer la bande passante dès la première connexion.

03

Contrôler la résolution

Une résolution élevée augmente la quantité de données transférées par image. Sur un réseau fragile, commencez avec un seul écran et une résolution réduite, puis ajustez la taille du bureau distant une fois la connexion stable.

04

Vérifier le presse-papiers

Après la connexion, testez la copie bidirectionnelle avec un texte sans informations sensibles. Ne transmettez pas de clé privée, de jeton d’accès complet ni d’identifiant longue durée via le presse-papiers partagé.

05

Confirmer les raccourcis du plein écran

Notez les raccourcis du client pour quitter le plein écran et libérer la capture du clavier, afin d’éviter qu’une combinaison distante interceptée par le système local ne soit prise pour une anomalie de session.

06

Conserver un canal de diagnostic SSH

Si l’image VNC se fige, vérifiez d’abord la charge et le réseau via SSH. Si SSH reste accessible, le nœud physique est généralement en ligne ; le problème se situe probablement dans la session graphique ou sur le trajet réseau.

Diagnostic de connexion

Validez progressivement la négociation, le réseau et le build distant

Ne modifiez qu’une variable à la fois pendant le diagnostic. Vérifiez d’abord la négociation SSH, observez ensuite le réseau, puis exécutez une commande distante vérifiable. Vous distinguerez ainsi les problèmes d’identifiants, de port, de liaison et d’environnement d’exécution.

Si vous voyez Connecting to sans réponse : vérifiez l’adresse, le port et les restrictions de sortie locales.

La négociation de clé commence mais l’authentification échoue : vérifiez le nom d’utilisateur, le chemin de la clé privée et ses permissions.

SSH fonctionne mais VNC ralentit : réduisez la qualité d’image et la résolution, puis suspendez les transferts en arrière-plan.

La connexion fonctionne mais le build échoue : lisez le journal complet du build et n’attribuez pas l’erreur de tâche au réseau.

remote-diagnostic.log

$ ssh -v -p PORT UTILISATEUR@HOTE
debug1: Connecting to host [HOTE] port [PORT]
debug1: Server host key: SHA256:[EMPREINTE]
debug1: Authentication succeeded (publickey)

$ ping -c 5 HOTE
5 packets transmitted, 5 packets received
round-trip min/avg/max = 41.2/44.8/49.1 ms

$ ssh lemon-node "xcodebuild -version"
Xcode [VERSION ACTUELLE]
Build version [NUMERO DE BUILD ACTUEL]

$ ssh lemon-node "cd ~/project && xcodebuild build"
** BUILD SUCCEEDED **

Mesure réelle de la latence des nœuds

Comparez les cinq nœuds avec la même méthode

Le tableau compare les écarts relatifs entre différents points d’accès et Singapour, Tokyo, Séoul, Hong Kong et l’Ouest américain. VNC interactif dépend surtout de la latence et de ses variations ; les builds en arrière-plan dépendent davantage de la stabilité et du débit continu.

Période de testJours ouvrés, 20:00–22:00, heure locale

Nombre d’échantillons30 requêtes ICMP par groupe

Méthode statistiqueMédiane après exclusion du premier paquet

Connexion utiliséeFibre fixe locale ou fibre d’entreprise

Médianes ping en millisecondes entre les principales villes d’accès et les cinq nœuds LemonVM proposés
Point d’accès et opérateur	Singapour	Tokyo	Séoul	Hong Kong	Ouest américain
Shanghai · China Telecom	68 ms	42 ms	51 ms	35 ms	146 ms
Pékin · China Unicom	91 ms	54 ms	46 ms	58 ms	139 ms
Shenzhen · China Mobile	53 ms	67 ms	76 ms	24 ms	168 ms
Taipei · fibre fixe	62 ms	39 ms	48 ms	31 ms	126 ms
Los Angeles · fibre d’entreprise	171 ms	112 ms	124 ms	143 ms	27 ms

Mode de lecture : pour un même point d’accès, comparez d’abord les valeurs horizontalement ; avec VNC, observez aussi les variations et les pertes de paquets sur la durée. La qualité réelle dépend du Wi-Fi local, de la sortie opérateur, du routage international et des transferts en arrière-plan.

Dépannage des latences élevées

Réduisez le périmètre du local vers le distant

Ne changez pas de nœud, de qualité d’image et de client en même temps. Suivez les six étapes ci-dessous et notez avant et après chaque modification la latence, les pertes de paquets ou la réactivité.

01

Vérifier le réseau local

Passez à une connexion filaire ou à un Wi-Fi 5 GHz stable, puis suspendez les téléchargements et synchronisations locales. Si d’autres appareils du même réseau subissent aussi des variations, commencez par corriger la liaison locale.

02

Observer la liaison internationale

Effectuez des sondes pendant plusieurs minutes afin de distinguer une latence élevée stable des pertes intermittentes. Les pics courts provoquent plus souvent des déplacements saccadés de la souris et des arrêts d’image dans VNC.

03

Comparer les nœuds disponibles

Parmi Singapour, Tokyo, Séoul, Hong Kong et l’Ouest américain, choisissez le nœud le plus proche de votre principale direction d’accès. Une équipe doit se baser sur la localisation des principaux opérateurs ou des dépendances de build.

04

Réduire la qualité VNC

Réduisez d’abord la qualité des couleurs, le niveau de compression ou la fréquence d’images, puis vérifiez la réactivité. Si l’image est nette mais les actions retardées, n’augmentez pas seulement les paramètres de bande passante.

05

Réduire la résolution

Passez temporairement à un seul écran et à une résolution plus faible. Si la réactivité s’améliore nettement, le volume de données par image dépasse probablement ce que la liaison actuelle peut gérer.

06

Suspendre les transferts en arrière-plan

Vérifiez les récupérations de dépôts, téléchargements de dépendances, transferts de ressources, retours d’artefacts et synchronisations distantes. Décalez les gros transferts par rapport aux opérations VNC en temps réel.

Sécurité des sessions

Réservez les données de connexion aux personnes qui en ont besoin

La sécurité des connexions distantes repose sur les clés locales, les identifiants initiaux, le verrouillage des sessions et la transmission au sein de l’équipe. Ne collez pas de données d’accès longue durée dans une discussion publique ou un dépôt.

Privilégier les clés

Utilisez une clé distincte par appareil et conservez les clés privées uniquement sur des terminaux contrôlés. Lorsqu’un appareil quitte l’équipe ou est perdu, supprimez rapidement la clé publique correspondante.

Mettre à jour les identifiants initiaux

Après la première connexion et la vérification de l’environnement, remplacez les identifiants temporaires. Ne laissez pas de données d’accès utilisables directement dans les scripts, journaux de build ou configurations de dépôt.

Verrouiller la session avant de s’absenter

Verrouillez le bureau distant lors d’une absence temporaire sans arrêter les tâches en arrière-plan. Dans un espace partagé, verrouillez également l’ordinateur local.

Attribuer les accès par membre

En équipe, consignez qui exécute quelle tâche et à quel moment ; ne partagez pas une clé longue durée. Lors du transfert, indiquez l’état de la tâche, l’emplacement des journaux et les étapes restantes.

Reprise après déconnexion

Vérifiez d’abord si la tâche s’exécute encore avant de vous reconnecter

La disparition de l’image VNC ne signifie pas que le nœud physique est arrêté. Vérifiez d’abord l’état via un autre canal afin d’éviter de relancer un build, d’écraser sa sortie ou d’interrompre une tâche en cours.

Interruption réseau

SSH et VNC sont tous deux déconnectés

Vérifiez d’abord le réseau local, puis testez l’hôte et le port cibles. Une fois le réseau rétabli, reconnectez-vous et consultez les journaux et l’état des processus ; ne répétez pas directement la commande initiale.

Points à confirmer : sortie locale, port cible, heure du dernier journal

Mise en veille du système

Connexion établie mais aucune réponse distante

Vérifiez l’état du service actuel dans la console, puis validez la réponse du système avec SSH. Après le rétablissement, contrôlez les paramètres d’alimentation et de session afin d’éviter une mise en veille inadaptée pendant les tâches longues.

Points à confirmer : réponse SSH, heure système, processus en cours

Session graphique

SSH fonctionne mais l’image VNC est anormale

Réduisez les paramètres d’affichage et recréez la session graphique. Ne redémarrez pas le nœud entier avant d’avoir confirmé l’état de la tâche ; le build en arrière-plan peut continuer normalement.

Points à confirmer : charge distante, session graphique, paramètres du client

Tâche en arrière-plan

Le build continue après la déconnexion

Après la reconnexion, lisez les journaux, le code de sortie et le répertoire des artefacts. Ne lancez un nouveau build qu’après avoir confirmé que le précédent est terminé ou a échoué, afin d’éviter des écritures concurrentes au même emplacement.

Points à confirmer : identifiant du processus, code de sortie, date de modification des artefacts

Accès associés

De la première connexion à la gestion continue

Si vous n’avez pas encore terminé la commande et la vérification de l’environnement, commencez par le démarrage rapide. Si vous rencontrez déjà une erreur précise, consultez le centre d’aide et poursuivez le diagnostic à partir du message d’erreur.