Vous louez une machine physique dédiée, pas une machine virtuelle. L’hôte, le port et les identifiants de connexion sont visibles uniquement dans la console : utilisez SSH pour exécuter des tâches, le partage d’écran pour l’interface graphique et le transfert de fichiers pour récupérer vos livrables.
Avant la première connexion, vérifiez que l’instance a bien été attribuée. N’envoyez jamais votre mot de passe, votre clé privée ni vos identifiants complets par e-mail.
Commencez ici pour compiler, exécuter des scripts ou vérifier le système. Utilisez le port indiqué dans la console : ne présumez pas qu’il s’agit du port par défaut.
Ouvrez l’instance concernée dans la console et vérifiez l’adresse de l’hôte, le port SSH et le nom d’utilisateur. Respectez les majuscules, minuscules et caractères spéciaux du mot de passe. Les variables ci-dessous sont des exemples : remplacez-les par vos propres paramètres dans le terminal. Le mot de passe vous sera demandé de manière interactive.
Lors de la première connexion, SSH affiche une empreinte de clé d’hôte. Vérifiez-la à partir des informations confirmées dans la console ou d’un ticket avant de l’accepter. Si la clé change, vérifiez d’abord si la machine a été réinstallée ou remplacée. N’ignorez pas l’avertissement et ne désactivez pas globalement la vérification de l’identité de l’hôte.
Générez une clé dédiée protégée par une phrase secrète sur votre ordinateur, puis ajoutez la clé publique au fichier d’autorisation de l’utilisateur distant. Gardez la clé privée sur votre ordinateur. Chaque membre de l’équipe doit utiliser sa propre clé : vous pourrez ainsi révoquer un accès individuellement, sans partager de clé privée.
Gardez la session actuelle ouverte et testez la connexion par clé dans un autre terminal. Après avoir confirmé qu’elle fonctionne et vérifié que vous pouvez rétablir l’accès depuis la console, modifiez le paramètre d’authentification par mot de passe du service SSH. Vérifiez la syntaxe de la configuration, puis appliquez-la selon le mode de fonctionnement du système. Désactiver l’authentification par mot de passe ne désactive pas toutes les méthodes interactives.
À exécuter dans votre terminal ; remplacez d’abord les trois paramètres de connexion
HOST='adresse-hote-de-la-console'
SSH_PORT='port-SSH-de-la-console'
REMOTE_USER='utilisateur-de-la-console'
ssh -p "$SSH_PORT" "$REMOTE_USER@$HOST"
ssh-keygen -t ed25519 -f "$HOME/.ssh/xcodenet_ed25519"
cat "$HOME/.ssh/xcodenet_ed25519.pub" | ssh -p "$SSH_PORT" "$REMOTE_USER@$HOST" 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'
ssh -i "$HOME/.ssh/xcodenet_ed25519" -p "$SSH_PORT" "$REMOTE_USER@$HOST"La commande d’ajout de la clé publique ne s’exécute qu’une fois. Si une clé existe déjà, ne l’écrasez pas : choisissez un autre nom de fichier. Avant de modifier l’authentification, le port ou le pare-feu, vérifiez comment rétablir l’accès pour éviter de vous bloquer hors de la machine.
Voici un exemple de séquence, pas la sortie en temps réel de votre instance. Pour compiler avec Xcode, il vous faut le projet et le bon chemin vers les outils. Une distribution avec Fastlane nécessite également votre propre configuration de signature et les autorisations de publication.
$ ssh -p "$SSH_PORT" "$REMOTE_USER@$HOST"
Welcome to macOS
$ uname -m
arm64
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ cd ~/workspace/App
$ xcodebuild -scheme App archive
BUILD SUCCEEDED
$ fastlane beta
Successfully uploaded to TestFlightuname -m Cette commande indique l’architecture en cours d’utilisation. Les outils natifs doivent être compatibles avec arm64. En cas d’erreur de dépendance, vérifiez d’abord l’architecture du binaire : une connexion réussie ne signifie pas que l’environnement est prêt.
xcode-select -p Affiche le répertoire des outils de développement actifs. Après avoir changé de version de Xcode, vérifiez à nouveau ce chemin, puis contrôlez le SDK, le scheme et les exigences de signature du projet.
Pour distribuer avec Fastlane, vous devez disposer d’un certificat, d’un profil de provisioning et des autorisations de publication valides. Stockez les fichiers sensibles dans un répertoire à accès restreint ; ne les ajoutez pas au dépôt de code et ne les affichez pas dans des journaux de build publics.
Vérifier la publicationOuvrez le bureau uniquement si vous devez utiliser Xcode, le simulateur ou les réglages système. L’expérience graphique dépend davantage de la latence aller-retour et de la stabilité du réseau. Commencez par assurer une connexion fiable, puis augmentez progressivement la qualité d’image.
Dans le Finder de votre Mac, choisissez Aller > Se connecter au serveur et saisissez l’adresse indiquée dans la console. Utilisez les identifiants de connexion graphique de l’instance, et non ceux de votre compte de console.
Si vous vous connectez via le tunnel SSH ci-dessous, utilisez l’adresse vnc://127.0.0.1:5901Laissez le terminal du tunnel ouvert : sa fermeture interrompt le transfert. N’exposez pas en parallèle le service de bureau sur Internet pour contourner le tunnel.
Saisissez l’hôte, le port et les identifiants de l’instance dans le client. Privilégiez un client prenant en charge les tunnels SSH ou une connexion explicitement chiffrée. Le protocole VNC ne garantit pas à lui seul le chiffrement des données dans toutes ses implémentations ; une connexion établie ne suffit pas à prouver qu’elle est sécurisée.
Commencez avec un seul écran et une résolution modeste, et désactivez les animations superflues. Pour travailler sur du texte, privilégiez la lisibilité. Pour prévisualiser des vidéos, utilisez des fichiers proxy et téléchargez le rendu final pour le vérifier localement.
Privilégiez la fluidité, puis augmentez la qualitéExemple de tunnel chiffré : le service de bureau distant doit être activé ; vérifiez le port d’écoute dans les paramètres de l’instance
VNC_PORT='5900'
ssh -N -L "127.0.0.1:5901:127.0.0.1:$VNC_PORT" \
-i "$HOME/.ssh/xcodenet_ed25519" \
-p "$SSH_PORT" "$REMOTE_USER@$HOST"Cet exemple lie le port local à l’adresse de bouclage uniquement, sans l’exposer au réseau local. Si le port 5901 est déjà utilisé, choisissez un autre port local disponible et modifiez aussi l’adresse dans le client. En cas d’écran noir, vérifiez la session utilisateur distante et le service de bureau au lieu de réinstaller le client à répétition.
Le transfert de fichiers réutilise l’hôte, le port et la clé SSH. Commencez par tester le chemin et les droits avec un petit fichier, puis envoyez le projet complet. Remplacez les répertoires des commandes par vos propres chemins.
Idéal pour les archives compressées, les journaux de build et les archives finalisées.scp utilise une majuscule pour le port : -P, contrairement à ssh qui utilise une minuscule : -p . Le répertoire de destination distant doit être créé à l’avance et autoriser l’écriture.
Idéal pour synchroniser progressivement du code et des ressources. La barre oblique à la fin du répertoire source indique que son contenu sera synchronisé. Lors du premier essai, vous pouvez ajouter --dry-run pour vérifier les changements prévus. N’ajoutez pas l’option de suppression sans précaution : vous risqueriez d’effacer des fichiers présents uniquement sur la machine distante.
Vérifiez d’abord le répertoire distant ; les exemples ci-dessous ne suppriment aucun fichier
scp -P "$SSH_PORT" -i "$HOME/.ssh/xcodenet_ed25519" \
./App.zip "$REMOTE_USER@$HOST:~/uploads/"
scp -P "$SSH_PORT" -i "$HOME/.ssh/xcodenet_ed25519" \
"$REMOTE_USER@$HOST:~/exports/App.zip" ./downloads/
rsync -av --dry-run \
-e "ssh -p $SSH_PORT -i $HOME/.ssh/xcodenet_ed25519" \
./project/ "$REMOTE_USER@$HOST:~/workspace/project/"
rsync -av \
-e "ssh -p $SSH_PORT -i $HOME/.ssh/xcodenet_ed25519" \
./project/ "$REMOTE_USER@$HOST:~/workspace/project/"Pour les grands projets, les modèles ou les fichiers multimédias qui nécessitent plus d’espace, ajoutez un SSD externe de +1 To pour $2.2/jour ou de +2 To pour $4.4/jour. Ces disques supplémentaires ne changent pas la capacité du disque principal des modèles proposés. Après connexion, utilisez df -h pour vérifier le point de montage et l’espace disponible, puis définissez vos répertoires de téléchargement, de cache et d’export.
Les vidéos, fichiers audio et archives déjà compressés se prêtent généralement mal à une nouvelle compression avant transfert. Après avoir transféré des fichiers importants, vérifiez leur taille ou leur somme de contrôle et gardez-en une copie locale. Une synchronisation réussie ne remplace pas une sauvegarde.
Deux configurations sont proposées à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul), à Hong Kong, dans l’est des États-Unis et dans l’ouest des États-Unis. Ces zones sont des suggestions de sélection, pas des garanties de latence. Consultez la disponibilité actuelle dans la console.
À comparer en priorité pour l’Asie du Sud-Est. Pour le partage d’écran, surveillez la latence aller-retour entre votre réseau et le site. Pour les builds automatisés en équipe, vérifiez également les routes vers le dépôt de code et le stockage des livrables.
Deux configurations disponiblesUne option à considérer pour l’Asie de l’Est. Pour le débogage graphique, testez le défilement du texte et le déplacement des fenêtres. Si vous utilisez surtout SSH, comparez aussi la vitesse de téléchargement des dépendances et de récupération des livrables.
Deux configurations disponiblesÀ comparer pour l’Asie du Nord-Est. L’utilisation d’un simulateur à distance est sensible aux variations du réseau. Gardez la même résolution et la même qualité d’image lors des tests afin de ne pas confondre les réglages du client avec les différences entre emplacements.
Deux configurations disponiblesÀ comparer pour le sud de la Chine et l’Asie du Sud-Est. Commencez par une connexion filaire ou locale stable pour écarter les interférences Wi-Fi, puis évaluez le partage d’écran et la stabilité des transferts prolongés.
Deux configurations disponiblesÀ considérer pour l’est de l’Amérique du Nord et l’Europe de l’Ouest. Pour les tâches CI, comparez les routes vers le dépôt de code de l’équipe, les services de dépendances et le stockage des livrables, pas seulement la distance entre l’utilisateur et le site.
Deux configurations disponiblesÀ comparer pour la côte ouest de l’Amérique du Nord. Pour le développement interactif, privilégiez la latence aller-retour. Pour les builds par lots, évaluez plutôt la durée totale d’exécution et de livraison des livrables : le meilleur emplacement peut différer selon l’usage.
Deux configurations disponiblesSur une machine déjà attribuée, commencez par exécuter ping -c 10 "$HOST"pour observer le temps aller-retour et la perte de paquets. Certains réseaux ne répondent pas à ICMP ; cela ne signifie pas que SSH est inaccessible. Testez ensuite le bureau avec les mêmes réglages client et transférez le même fichier de test. Notez l’heure, le réseau utilisé, la résolution et le résultat pour faciliter la reproduction du problème dans un ticket.
Cette page ne présente pas les zones géographiques comme des mesures de latence. Votre opérateur, le routage entre régions, le réseau sans fil et la qualité d’image du client influent tous sur l’expérience. Testez votre flux de travail pendant une journée avant de prolonger la location : la distance sur une carte ne suffit pas à choisir.
Une machine dédiée ne dispense pas de définir des limites d’accès. Renforcez les autorisations dans cet ordre : clés, sources, services, nettoyage. Gardez toujours une méthode de récupération déjà testée.
Modifier le port d’écoute SSH peut réduire le bruit des scans courants, mais ne remplace pas l’authentification par clé. Vérifiez d’abord que la redirection de port et les règles réseau autorisent ce changement, mettez à jour la configuration du client et la documentation de l’équipe, puis testez la connexion depuis une nouvelle session.
Dans les règles d’accès prises en charge par l’instance, n’autorisez que les sources nécessaires. L’adresse IP publique de votre entreprise ou de votre domicile peut changer, tout comme la sortie d’un réseau mobile. Avant d’appliquer une règle, vérifiez votre adresse de sortie et la procédure de récupération en cas de changement.
Le pare-feu des applications macOS et les règles de filtrage par port et par source ont des fonctions différentes : vérifiez-les séparément. Autorisez les services nécessaires et désactivez ceux que vous n’utilisez pas. Après chaque changement, testez SSH et le bureau depuis un deuxième terminal au lieu d’appliquer plusieurs modifications à la fois.
Synchronisez d’abord vos projets, livrables de build et notes d’expérimentation. Révoquez ensuite les autorisations de publication temporaires, supprimez les clés publiques de l’équipe et nettoyez les fichiers sensibles dans les certificats et les caches. Vérifiez que vos sauvegardes sont lisibles avant de terminer : ne comptez pas sur la conservation des données après la location pour remplacer une sauvegarde.
Pour un ticket, indiquez uniquement l’identifiant de l’instance, le problème rencontré et les vérifications effectuées. N’envoyez ni clé privée, ni mot de passe, ni mot de passe de certificat de signature, ni numéro de carte bancaire. Masquez aussi les identifiants dans les captures d’écran. Si vous souhaitez qu’un membre de l’assistance intervienne sur l’instance, précisez clairement l’étendue de l’autorisation dans le ticket.
Commencez par distinguer un délai d’attente dépassé, un refus de connexion et un échec d’authentification : c’est plus efficace que de réessayer sans cesse. Suivez les étapes dans l’ordre, conservez le message d’erreur original, puis ouvrez un ticket depuis la page d’aide ou la console.
Vérifiez l’état du paiement et de l’attribution, puis ouvrez la bonne fiche d’instance. Si les identifiants de connexion ne s’affichent pas, vérifiez d’abord l’état de la commande. Ne devinez pas l’adresse et ne reprenez pas dans d’anciennes notes les informations d’une autre instance.
Comparez l’hôte, le port et le nom d’utilisateur avec les informations de la console. En cas de délai d’attente dépassé, vérifiez d’abord le réseau et les règles d’accès. Un refus de connexion signale généralement qu’il faut vérifier le service à l’écoute, le port et les paramètres de redirection.
En cas d’échec d’authentification, vérifiez que vous avez sélectionné la bonne clé privée et le bon utilisateur distant, et que le fichier des clés publiques autorisées est correct. Utilisez ssh -v pour examiner le processus d’authentification. Avant de partager les journaux, supprimez les informations sensibles comme l’hôte, le nom d’utilisateur et les chemins locaux.
Vérifiez le proxy, les règles réseau de votre entreprise et les règles de pare-feu récemment modifiées. Pour un bureau connecté par tunnel, vérifiez que SSH est toujours actif et que le port local n’est pas déjà utilisé. Si SSH fonctionne mais que le bureau reste noir, examinez la session graphique et le service de bureau.
Indiquez l’identifiant de l’instance, l’emplacement, le modèle, l’heure et le fuseau horaire, le mode de connexion, le message d’erreur complet et les étapes déjà tentées. Précisez si vous venez de réinstaller le système ou de modifier les paramètres de sécurité pour aider l’assistance à relier le problème aux changements effectués.
Mac cloud à partir de $21.4/jour. Choisissez un modèle, un emplacement et une durée de location. Après confirmation du paiement et attribution de la machine, consultez vos identifiants dans la console. Pour commencer, vérifiez SSH, puis préparez le bureau et l’environnement de développement.