Parcours de connexion sécurisé

Vérifiez d’abord votre identité, puis connectez-vous à votre Mac dans le cloud

Le bureau distant sert à utiliser Xcode, déboguer graphiquement et manipuler macOS ; SSH sert aux scripts, aux fichiers, à l’automatisation et à la gestion CI/CD. Les deux canaux utilisent les mêmes informations de nœud dans le tableau de bord, mais leurs vérifications diffèrent.

  • Pour le bureau distant, vérifiez d’abord le nœud, le nom du compte et l’identité de la session
  • Lors de la première connexion SSH, comparez impérativement l’empreinte de l’hôte
  • Après validation d’une clé dédiée, désactivez les identifiants temporaires
Louer un Mac dans le cloud Voir les étapes d’activation
2
Modes de connexion principaux
6
Points à vérifier lors de la première connexion
1
Jeu d’informations d’accès dans le tableau de bord
CONNECTION PASS

Checklist de première connexion

À vérifier
Session graphique Xcode, débogage, utilisation du bureau
Bureau distant
Canal de commandes Scripts, fichiers, gestion du runner
SSH
Adresse du nœud
À relever dans la commande
Port
À renseigner selon le protocole
Empreinte de l’hôte
À comparer lors de la première connexion
Authentification durable
Clé SSH dédiée
Ordre de vérification Adresse → port → identité → empreinte → session
Vue d’ensemble des connexions

Le bureau pour le graphique, SSH pour l’automatisation

Les deux modes de connexion peuvent être utilisés simultanément. La session de bureau sert aux opérations visuelles, tandis que SSH assure des tâches de commande stables et traçables ; ne faites pas reposer tout votre travail sur une seule session.

Workflow graphique

Bureau distant

Idéal pour ouvrir Xcode, exécuter le simulateur, contrôler l’interface graphique, gérer les éléments de signature et observer les opérations de débogage nécessitant un retour visuel. Vérifiez d’abord l’adresse du nœud, le compte de session et l’identité du bureau.

  • Édition et compilation interactives dans Xcode
  • Vérification des journaux graphiques et des panneaux de performances
  • Sessions macOS nécessitant une observation continue
Workflow de commandes

SSH

Idéal pour exécuter des scripts, synchroniser des fichiers, vérifier l’espace disque, gérer les processus de compilation et administrer un self-hosted runner. Pour une utilisation durable, employez une clé dédiée et limitez son emplacement de stockage et son périmètre d’utilisation.

  • Scripts de compilation et de déploiement reproductibles
  • Transfert de fichiers, extraction des journaux et nettoyage du cache
  • Enregistrement et administration du runner CI/CD
Combinaison recommandée

Validez avec le bureau, exécutez avec SSH

Lors de la livraison initiale, vérifiez la session et l’état du système via le bureau distant, puis validez la clé avec SSH. Au quotidien, placez les tâches longues dans un workflow de commandes récupérable et réservez le bureau aux opérations visuelles.

  • Réduire l’impact d’une déconnexion du bureau sur les tâches longues
  • Faciliter l’enregistrement des commandes et des résultats
  • Séparer les opérations interactives des autorisations d’automatisation
Identifier les informations d’accès

Chaque champ a un rôle précis : ne les mélangez pas

Les informations d’accès se trouvent dans la commande ou les détails de l’instance du tableau de bord. Lors de la copie, conservez la casse et le port d’origine ; ne retranscrivez pas une longue empreinte depuis une capture d’écran.

Champs d’accès au Mac dans le cloud et leur utilisation
Champ Utilisation Vérification initiale Limite de sécurité
Adresse du nœud Hôte cible du client de bureau distant et des commandes SSH Identique au nœud sélectionné dans la commande actuelle N’utilisez pas l’adresse d’une autre commande comme adresse de secours
Port Distingue les points d’entrée du bureau distant et du service SSH Renseignez-les séparément selon le tableau de bord, sans deviner N’exposez pas sur Internet un port d’écoute ajouté vous-même
Nom du compte Identifie la session utilisateur macOS ouverte Vérifiez l’orthographe, la casse et l’appartenance à la session Les membres de l’équipe ne doivent pas partager des comptes impossibles à tracer
Identifiants temporaires Utilisés uniquement pour la première validation du bureau distant ou de SSH Après la première connexion, mettez immédiatement en place une authentification durable Après validation d’une clé dédiée, désactivez les identifiants temporaires
Empreinte de l’hôte Confirme que SSH se connecte au nœud physique attendu Lors de la première connexion, comparez chaque caractère avec l’enregistrement du tableau de bord Si l’empreinte change, interrompez la connexion et ouvrez un ticket pour vérification
Première connexion au bureau distant

Divisez la première connexion en quatre vérifications distinctes

Le nom et la version du client compatible dépendent de votre système d’exploitation. Après le téléchargement, installez une version prise en charge, puis saisissez les informations fournies par le tableau de bord.

  1. 01

    Préparer le client

    Installez un client de bureau distant compatible et vérifiez que votre système autorise l’accès réseau et l’affichage. Désactivez les anciennes configurations susceptibles de modifier l’adresse cible.

  2. 02

    Saisir les informations du nœud

    Copiez dans le tableau de bord l’adresse du nœud, le port du bureau distant et le nom du compte. Enregistrez-les dans une configuration dédiée à cette commande, sans partager d’alias avec d’autres nœuds.

  3. 03

    Vérifier l’identité de la session

    Après la connexion, vérifiez les informations de l’hôte, le nom du compte, le nœud sélectionné et l’enregistrement de la commande. Si un élément ne correspond pas, quittez la session et recommencez la vérification.

  4. 04

    Finaliser la première connexion

    Remplacez les identifiants temporaires, vérifiez la disposition du clavier, la résolution et le verrouillage automatique, puis reconnectez-vous pour confirmer que les nouvelles informations fonctionnent.

Connexion SSH sécurisée

La connexion n’est terminée qu’après validation de la clé, de l’empreinte et des autorisations

Chaque opérateur et chaque environnement automatisé doivent générer leurs propres clés. Ne copiez pas la clé privée d’une autre personne et ne diffusez pas la même clé durable sur des appareils impossibles à tracer.

Ordre de connexion SSH Générer localement → envoyer la clé publique → comparer l’empreinte → tester la connexion

1. Générer une clé dédiée

ssh-keygen -t ed25519 -f ~/.ssh/ovps_remote

Conservez la clé privée sur un appareil contrôlé et transmettez la clé publique via le tableau de bord. Donnez à la clé un nom d’usage identifiable pour faciliter son remplacement et sa révocation.

2. Vérifier les autorisations de la clé privée locale

chmod 600 ~/.ssh/ovps_remote

Avec des autorisations trop larges, SSH refuse d’utiliser la clé privée. Sur un poste partagé, vérifiez également les autorisations du répertoire et l’accès des logiciels de sauvegarde.

3. Tester la connexion avec les champs du tableau de bord

ssh -i ~/.ssh/ovps_remote -p "$SSH_PORT" "$SSH_USER@$NODE_ADDRESS"

Lors de la première demande d’empreinte de l’hôte, comparez-la d’abord avec l’enregistrement du tableau de bord. Ne confirmez qu’en cas de correspondance parfaite ; ne l’ignorez pas et ne l’acceptez pas aveuglément.

Critères de réussite

Un test doit produire quatre conclusions

  • L’adresse cible correspond au nœud de la commande
  • L’empreinte de l’hôte correspond caractère par caractère
  • La clé privée dédiée permet l’authentification
  • Le compte n’accède qu’au répertoire de travail prévu
Après la validation

Désactiver les identifiants temporaires

Après confirmation de la connexion par clé, désactivez les identifiants temporaires utilisés lors de la livraison initiale. Notez le propriétaire, l’usage et le plan de remplacement de la clé, puis supprimez les copies temporaires devenues inutiles.

Voir l’assistance à la connexion
Scénarios de tunnel SSH

Ne transférez que les services nécessaires et liez-les à l’adresse de bouclage locale

Un tunnel convient pour consulter temporairement un service de développement interne, un rapport de compilation ou un port de débogage local. Il ne remplace pas une publication permanente d’un service sur Internet.

Transfert de port local

Créer un canal contrôlé

La commande suivante mappe sur l’ordinateur de l’opérateur un service de développement du Mac dans le cloud qui écoute uniquement sur l’adresse de bouclage. Le navigateur utilise l’adresse locale ; le service n’a pas besoin d’un nouveau port public.

ssh -N \
  -L 127.0.0.1:8080:127.0.0.1:8080 \
  -i ~/.ssh/ovps_remote \
  -p "$SSH_PORT" \
  "$SSH_USER@$NODE_ADDRESS"
Liaison locale
127.0.0.1:8080
Cible distante
127.0.0.1:8080
Méthode d’authentification
Clé SSH dédiée
Nettoyage après déconnexion

Quitter ne suffit pas à terminer le nettoyage

Après le débogage, vérifiez dans l’ordre le processus du tunnel, le port d’écoute, le service temporaire et l’absence d’accès superflu dans les journaux.

  1. Arrêter le processus du tunnel SSH Vérifiez que la session locale est terminée et qu’elle ne se reconnecte plus automatiquement.
  2. Vérifier le port d’écoute local Vérifiez que les ports temporaires, notamment 8080, sont libérés.
  3. Arrêter le service temporaire distant Lorsque le débogage est terminé, arrêtez les services temporaires et les proxys de test.
  4. Révoquer les autorisations temporaires Supprimez les clés publiques ou règles d’accès ajoutées uniquement pour ce diagnostic.
Connexion d’un runner CI

Commencez par une tâche de test minimale avant d’intégrer le pipeline de production

Un self-hosted runner doit utiliser un répertoire de travail dédié et un périmètre de projet minimal. N’autorisez pas par défaut l’accès à tous les dépôts de l’équipe, aux éléments de signature ou aux anciens artefacts de compilation.

Vérification de l’intégration 4 étapes
01

Enregistrer un runner dédié

Créez une identité de runner dédiée au projet cible et notez le nœud, l’usage et le responsable. Les identifiants d’enregistrement ne servent que lors de la configuration.

Identité claire
02

Limiter le périmètre du projet

Autorisez uniquement les dépôts et types de tâches prévus à utiliser ce runner. Configurez les labels selon le workflow et évitez les correspondances génériques trop larges.

Périmètre contrôlé
03

Configurer le répertoire de travail

Séparez le code source, le cache des dépendances, les artefacts de compilation et les fichiers temporaires. Vérifiez l’espace disque et les règles de nettoyage en fin de tâche.

Répertoires isolés
04

Exécuter une tâche de test minimale

Commencez par les informations d’environnement, la récupération du code et une petite compilation de test. Vérifiez les journaux, le code de sortie et le chemin des artefacts avant d’ajouter les tâches de production.

Prêt à intégrer
Consultation mobile

Le téléphone sert à consulter l’état, pas à stocker des identifiants complets

Un petit écran convient pour vérifier l’avancement de la livraison, les alertes de session, le numéro de commande et l’état du nœud. Pour copier des informations d’accès complètes, gérer des clés SSH ou effectuer une récupération, utilisez un appareil de bureau contrôlé.

État de la livraison Disponible
Alertes de session Disponible
Informations de commande Disponible
Clé privée complète Non affichée
Opérations adaptées au mobile

Vérification rapide

Vérifiez si la commande est livrée, si le nœud correspond et si une alerte de session nécessite une réponse, puis notez l’heure du problème.

Revenir au bureau

Opérations sécurisées

Pour envoyer une clé publique, remplacer des identifiants, copier une empreinte d’hôte, consulter les informations de connexion complètes ou exécuter des commandes, utilisez un appareil de bureau contrôlé.

Dépannage

Suivez l’ordre du parcours et ne modifiez pas plusieurs variables à la fois

Notez le résultat de chaque étape. Si vous changez simultanément le réseau, le port, la clé et le client, la disparition temporaire du problème ne permettra pas d’en identifier la cause réelle.

01

Vérifier le réseau local

Vérifiez que le réseau actuel accède normalement aux services externes, désactivez les proxys temporaires susceptibles de modifier le routage, puis refaites un test sur un réseau connu comme fonctionnel.

Réseau consigné
02

Vérifier l’adresse du nœud

Recopiez l’adresse du nœud depuis la commande actuelle. N’utilisez pas une ancienne commande, un favori obsolète du client ou une adresse issue d’un historique de conversation.

Adresse correspondante
03

Vérifier le port du protocole

Confirmez que le bureau distant et SSH utilisent chacun le port prévu, puis vérifiez si le réseau local limite les connexions sortantes vers ce port.

Port accessible
04

Vérifier les autorisations de la clé

Vérifiez le chemin de la clé privée, le resserrement suffisant des autorisations, l’envoi de la clé publique au nœud cible et l’utilisation effective de la clé attendue par le client.

Authentification réussie
05

Vérifier l’état de la session distante

Vérifiez la cohérence du nom du compte et de la session graphique. Si le bureau ne répond plus, recréez d’abord la session ; n’envoyez pas immédiatement de nombreuses demandes de connexion répétées.

Session opérationnelle
06

Vérifier les réglages de veille

Vérifiez que les règles de verrouillage et de veille pendant les tâches longues correspondent au workflow, et que le runner ou les scripts ne s’arrêtent pas lorsque la session graphique est interrompue.

Tâche en cours
Préparer la connexion

Choisissez votre nœud et votre configuration : la livraison prend environ 4 minutes

Trois configurations de machines physiques dédiées couvrent Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong, la côte Est des États-Unis et la côte Ouest des États-Unis. Après la livraison, vérifiez le bureau distant et SSH dans l’ordre indiqué sur cette page.

Paiement uniquement par USDT-TRC20 et Visa / Mastercard / Amex (via Stripe), avec règlement exclusivement en dollars américains (USD).

Louer un Mac dans le cloud Voir les trois configurations