Sie mieten einen exklusiven physischen Mac, keine virtuelle Maschine. Host, Port und Zugangsdaten stehen nur in der Konsole: Nutzen Sie SSH für Aufgaben, die Bildschirmfreigabe für die grafische Oberfläche und die Dateiübertragung für Ihre Ergebnisse.
Prüfen Sie vor der ersten Verbindung, ob Ihre Bestellung bereits zugewiesen wurde. Senden Sie Passwörter, private Schlüssel oder vollständige Zugangsdaten niemals per E-Mail.
Hier starten Sie mit Builds, Skripten und Systemprüfungen. Verwenden Sie den in der Konsole angezeigten Port, statt den Standardport anzunehmen.
Öffnen Sie die passende Instanz in der Konsole und prüfen Sie Hostadresse, SSH-Port und Benutzernamen. Groß- und Kleinschreibung sowie Sonderzeichen im Passwort müssen exakt stimmen. Ersetzen Sie die Beispielvariablen unten im lokalen Terminal durch Ihre Angaben. Das Passwort geben Sie bei der interaktiven Abfrage ein.
Beim ersten Verbindungsaufbau werden Sie nach dem Hostschlüssel gefragt. Prüfen Sie den Fingerabdruck anhand bestätigter Angaben aus der Konsole oder einem Support-Ticket, bevor Sie ihn akzeptieren. Ändert sich der Hostschlüssel, klären Sie zuerst, ob das System neu installiert oder die Maschine gewechselt wurde. Ignorieren Sie die Warnung nicht und deaktivieren Sie die Hostprüfung nicht global.
Erstellen Sie lokal einen geschützten Schlüssel mit Passphrase und fügen Sie den öffentlichen Schlüssel zur Autorisierungsdatei des Remote-Benutzers hinzu. Der private Schlüssel bleibt auf Ihrem Rechner. Verwenden Sie im Team jeweils eigene Schlüssel, damit Sie den Zugriff einzelner Personen gezielt entziehen können.
Lassen Sie die bestehende Verbindung geöffnet und testen Sie die Anmeldung per Schlüssel in einem zweiten Terminal. Ändern Sie die Passwortauthentifizierung in der SSH-Serverkonfiguration erst, wenn die Anmeldung funktioniert und ein Wiederherstellungsweg über die Konsole bereitsteht. Prüfen Sie die Konfigurationssyntax und wenden Sie die Änderung entsprechend dem Dienst Ihres Systems an. Das Deaktivieren der Passwortauthentifizierung schaltet nicht alle interaktiven Anmeldemethoden ab.
Im lokalen Terminal ausführen; zuerst die drei Verbindungsangaben ersetzen
HOST='Hostadresse-aus-der-Konsole'
SSH_PORT='SSH-Port-aus-der-Konsole'
REMOTE_USER='Benutzername-aus-der-Konsole'
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"Der Befehl zum Hinzufügen des öffentlichen Schlüssels muss nur einmal ausgeführt werden. Ist der Schlüssel bereits vorhanden, überschreiben Sie die Datei nicht, sondern wählen Sie einen anderen Dateinamen. Klären Sie vor Änderungen an Authentifizierung, Port oder Firewall, wie Sie den Zugriff wiederherstellen können, damit Sie sich nicht aussperren.
Die folgenden Abläufe sind Beispiele und keine Live-Ausgabe Ihrer Instanz. Für einen Xcode-Build benötigen Sie Ihr Projekt und den richtigen Toolpfad. Für die Verteilung mit Fastlane brauchen Sie außerdem Ihre eigene Signaturkonfiguration und Veröffentlichungsberechtigung.
$ 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 Prüft die aktuell verwendete Architektur. Native Tools müssen zur arm64-Umgebung passen. Prüfen Sie bei Abhängigkeitsfehlern zuerst die Architektur der Binärdateien. Eine erfolgreiche Verbindung bedeutet nicht, dass die Umgebung bereits vollständig eingerichtet ist.
xcode-select -p Zeigt das Verzeichnis der aktiven Entwicklertools. Prüfen Sie den Pfad nach einem Wechsel der Xcode-Version erneut und kontrollieren Sie dann SDK, Scheme und Signaturanforderungen Ihres Projekts.
Für die erfolgreiche Verteilung mit Fastlane benötigen Sie ein gültiges Zertifikat, ein Provisioning-Profil und die Veröffentlichungsberechtigung. Speichern Sie sensible Dateien in einem zugriffsbeschränkten Verzeichnis. Übertragen Sie sie weder ins Code-Repository noch in öffentlich einsehbare Build-Logs.
Zum Schluss die Veröffentlichung prüfenÖffnen Sie den Desktop nur, wenn Sie Xcode, den Simulator oder Systemeinstellungen bedienen müssen. Die grafische Interaktion hängt stärker von Latenz und Verbindungsstabilität ab. Sorgen Sie zuerst für eine stabile Verbindung und erhöhen Sie dann schrittweise die Bildqualität.
Öffnen Sie im lokalen Finder unter „Gehe zu“ die Option „Mit Server verbinden“ und geben Sie die Verbindungsadresse aus der Konsole ein. Verwenden Sie den grafischen Benutzernamen und das zugehörige Passwort der Instanz. Das Passwort für Ihr Konsolenkonto ist nicht das Passwort des Macs.
Wenn Sie die Verbindung über den SSH-Tunnel unten herstellen, lautet die Adresse vnc://127.0.0.1:5901. Lassen Sie das Terminal mit dem Tunnel geöffnet. Wird es geschlossen, endet die Weiterleitung. Öffnen Sie den Desktop-Dienst nicht zusätzlich für das öffentliche Internet, um den Tunnel zu umgehen.
Geben Sie im Client Host, Port und Zugangsdaten der Instanz ein. Verwenden Sie vorzugsweise einen Client, der SSH-Tunnel oder eine ausdrücklich verschlüsselte Verbindung unterstützt. Das VNC-Protokoll garantiert nicht bei jeder Implementierung eine verschlüsselte Übertragung. Eine erfolgreiche Verbindung allein bedeutet daher nicht, dass sie sicher ist.
Beginnen Sie mit einem einzelnen Bildschirm und einer niedrigeren Auflösung, und deaktivieren Sie unnötige Desktop-Animationen. Bei Textarbeiten sollte die Lesbarkeit Vorrang haben. Verwenden Sie für Videovorschauen Proxy-Dateien und laden Sie fertige Ausgabedateien zur Prüfung lokal herunter.
Erst flüssig arbeiten, dann Bildqualität erhöhenBeispiel für einen verschlüsselten Tunnel: Der Remote-Desktop-Dienst muss aktiviert sein; der Listening-Port richtet sich nach den Einstellungen der Instanz
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"Das Beispiel bindet den lokalen Port nur an die Loopback-Adresse und macht ihn nicht im lokalen Netzwerk erreichbar. Ist Port 5901 lokal belegt, wählen Sie einen freien Port und passen Sie die Clientadresse entsprechend an. Prüfen Sie bei einem schwarzen Bildschirm zuerst die Remote-Benutzersitzung und den Desktop-Dienst, statt den Client wiederholt neu zu installieren.
Für die Dateiübertragung gelten dieselben SSH-Angaben für Host, Port und Schlüssel. Testen Sie zuerst Pfad und Berechtigungen mit einer kleinen Datei und übertragen Sie dann das gesamte Projekt. Ersetzen Sie die Verzeichnisse im Befehl durch Ihre tatsächlichen Pfade.
Geeignet für Archive, Build-Logs und fertige Pakete.scp Den Port geben Sie mit einem großen -Pan, anders als bei ssh mit einem kleinen -p . Das Zielverzeichnis auf dem Remote-System muss vorher angelegt werden und beschreibbar sein.
Ideal für die inkrementelle Synchronisierung von Code und Assets. Ein abschließender Schrägstrich am Quellverzeichnis bedeutet, dass dessen Inhalt synchronisiert wird. Fügen Sie beim ersten Durchlauf --dry-run hinzu, um den Umfang zu prüfen. Verwenden Sie nicht unbedacht eine Löschoption, damit ausschließlich auf dem Remote-System vorhandene Dateien nicht verloren gehen.
Remote-Verzeichnis zuerst prüfen; die Beispiele löschen keine Dateien
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/"Wenn große Projekte, Modelldateien oder Medien mehr Platz benötigen, können Sie eine externe SSD mit +1 TB für $2.2/Tag oder +2 TB für $4.4/Tag dazubuchen. Das zusätzliche Laufwerk ändert nicht die Hauptspeicherkapazität der angebotenen Modelle. Prüfen Sie nach dem Verbinden mit df -h den tatsächlichen Einhängepunkt und den verfügbaren Speicher. Legen Sie anschließend Download-, Cache- und Exportverzeichnisse fest.
Bereits komprimierte Video-, Audio- und Archivdateien lassen sich meist nicht sinnvoll weiter komprimieren. Prüfen Sie nach der Übertragung wichtiger Dateien ihre Größe oder Prüfsumme und behalten Sie eine lokale Kopie. Eine erfolgreiche Synchronisierung ist noch kein Backup.
An allen sechs Standorten – Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, US-Ostküste und US-Westküste – sind beide Modellvarianten verfügbar. Die Regionen sind Empfehlungen zur Standortwahl, keine garantierten Latenzwerte. Die aktuelle Verfügbarkeit sehen Sie in der Konsole.
Ein Standort zum Vergleichen für Nutzer in Südostasien. Achten Sie bei der Bildschirmfreigabe auf die Latenz zwischen Ihrem Netzwerk und dem Standort. Bei automatisierten Team-Builds sollten Sie auch die Übertragungswege zum Code-Repository und zum Speicher für Build-Artefakte prüfen.
Zwei Modelle verfügbarEine Option für Nutzer in Ostasien. Testen Sie bei der grafischen Fehlersuche das Scrollen von Text und das Verschieben von Fenstern. Bei überwiegender SSH-Nutzung können Sie zusätzlich die Geschwindigkeit von Downloads für Abhängigkeiten und Rückübertragungen von Build-Artefakten vergleichen.
Zwei Modelle verfügbarEine Option zum Vergleichen für Nutzer in Nordostasien. Die Arbeit mit Remote-Simulatoren reagiert empfindlich auf Schwankungen der Verbindung. Testen Sie mit derselben Auflösung und Bildqualität, damit Unterschiede in den Client-Einstellungen nicht mit Standortunterschieden verwechselt werden.
Zwei Modelle verfügbarEine Option zum Vergleichen für Nutzer in Südchina und Südostasien. Testen Sie zunächst über eine Kabelverbindung oder ein stabiles lokales Netzwerk, um WLAN-Störungen auszuschließen. Achten Sie anschließend auf die Qualität der Bildschirmfreigabe und die Stabilität längerer Übertragungen.
Zwei Modelle verfügbarEine Option für Nutzer im Osten Nordamerikas und in Westeuropa. Vergleichen Sie bei CI-Aufgaben auch die Verbindungswege zu Team-Repositories, Diensten für Abhängigkeiten und Speicherorten für Build-Artefakte – nicht nur die Entfernung zwischen Ihnen und dem Standort.
Zwei Modelle verfügbarEine Option zum Vergleichen für Nutzer an der Westküste Nordamerikas. Bei interaktiver Entwicklung zählt vor allem die Latenz. Bei umfangreichen Builds ist die Gesamtdauer von Ausführung und Bereitstellung der Artefakte wichtiger. Die beste Standortwahl kann daher je nach Aufgabe unterschiedlich ausfallen.
Zwei Modelle verfügbarAuf einer bereits zugewiesenen Instanz können Sie zunächst ping -c 10 "$HOST"ausführen, um Round-Trip-Zeit und Paketverlust zu prüfen. Manche Netzwerke beantworten ICMP-Anfragen nicht; daraus folgt nicht, dass SSH nicht verfügbar ist. Bedienen Sie anschließend den Desktop mit denselben Client-Einstellungen und übertragen Sie dieselbe Testdatei. Notieren Sie Uhrzeit, lokales Netzwerk, Auflösung und Ergebnis, damit sich der Test in einem Support-Ticket nachvollziehen lässt.
Die regionalen Angaben auf dieser Seite sind keine Messwerte zur tatsächlichen Latenz. Ihr Internetanbieter, das Routing zwischen Regionen, WLAN-Bedingungen und die Bildqualität des Clients beeinflussen das Nutzungserlebnis. Testen Sie Ihren Arbeitsablauf zunächst für einen Tag, bevor Sie die Mietdauer verlängern. Das ist aussagekräftiger als die Entfernung auf der Karte.
Ein exklusiver physischer Rechner macht Zugriffsregeln nicht überflüssig. Schränken Sie Berechtigungen in dieser Reihenfolge ein: Schlüssel, Herkunft, Dienste, Bereinigung. Halten Sie stets einen geprüften Wiederherstellungsweg bereit.
Ein anderer SSH-Port kann die Zahl üblicher Scanversuche verringern, ersetzt aber keine Anmeldung per Schlüssel. Prüfen Sie zuerst, ob Portweiterleitung und Netzwerkregeln die Änderung zulassen. Aktualisieren Sie Clientkonfiguration und Teamdokumentation und testen Sie die Verbindung anschließend in einer neuen Sitzung.
Lassen Sie in den für die Instanz verfügbaren Zugriffsregeln nur erforderliche Quelladressen zu. Die öffentliche IP-Adresse eines Unternehmensanschlusses oder Heimnetzwerks kann sich ändern; auch Mobilfunknetze wechseln mitunter den Ausgangspunkt. Prüfen Sie vor dem Anwenden der Regeln die aktuelle IP-Adresse und klären Sie, wie Sie bei einer Änderung wieder Zugriff erhalten.
Die macOS-Anwendungsfirewall und Regeln zum Filtern nach Port oder Herkunft haben unterschiedliche Aufgaben und sollten getrennt geprüft werden. Erlauben Sie nur benötigte Verbindungsdienste und deaktivieren Sie ungenutzte. Testen Sie nach jeder Änderung SSH und Desktop über ein zweites Terminal, statt mehrere Änderungen auf einmal vorzunehmen.
Synchronisieren Sie zuerst Projekte, Build-Artefakte und Testprotokolle. Widerrufen Sie dann temporäre Veröffentlichungsberechtigungen, entfernen Sie die öffentlichen Schlüssel des Teams und löschen Sie sensible Dateien aus Zertifikaten und Caches. Prüfen Sie, ob Ihr Backup lesbar ist, bevor Sie die Arbeit beenden. Verlassen Sie sich nicht auf eine mögliche Datenspeicherung nach Ablauf der Mietdauer als Ersatz für ein Backup.
Für ein Support-Ticket genügen die Instanzkennung, eine Beschreibung des Problems und die bereits durchgeführten Prüfungen. Senden Sie weder private Schlüssel noch Anmeldepasswörter, Passwörter für Signaturzertifikate oder Zahlungskartennummern. Schwärzen Sie Zugangsdaten auch auf Screenshots. Wenn das Supportteam Änderungen an der Instanz vornehmen soll, legen Sie den Umfang der Berechtigung im Ticket ausdrücklich fest.
Unterscheiden Sie zwischen Zeitüberschreitung, abgelehnter Verbindung und fehlgeschlagener Authentifizierung. Das ist meist schneller, als wiederholt auf „Verbinden“ zu klicken. Prüfen Sie die Punkte der Reihe nach, notieren Sie die genaue Fehlermeldung und reichen Sie anschließend über die Hilfeseite oder Konsole ein Ticket ein.
Prüfen Sie Zahlungs- und Zuweisungsstatus und öffnen Sie die Details der richtigen Instanz. Werden keine Verbindungsdaten angezeigt, prüfen Sie zuerst den Bestellstatus. Raten Sie nicht bei der Adresse und übernehmen Sie keine Angaben einer anderen Instanz aus alten Notizen.
Vergleichen Sie Host, Port und Benutzernamen mit den Angaben in der Konsole. Prüfen Sie bei einer Zeitüberschreitung zuerst Netzwerk und Zugriffsregeln. Bei „Verbindung abgelehnt“ sind meist der lauschende Dienst, Port und Weiterleitungseinstellungen zu prüfen.
Prüfen Sie bei fehlgeschlagener Authentifizierung, ob privater Schlüssel, Remote-Benutzer und Datei mit autorisierten öffentlichen Schlüsseln übereinstimmen. Mit ssh -v sehen Sie den Ablauf der Authentifizierung. Entfernen Sie vor dem Teilen des Logs sensible Angaben wie Host, Benutzernamen und lokale Pfade.
Prüfen Sie Proxy, Unternehmensnetzwerkregeln und kürzlich geänderte Firewallregeln. Wenn der Desktop über einen Tunnel verbunden ist, stellen Sie sicher, dass SSH noch läuft und der lokale Port nicht belegt ist. Funktioniert SSH, bleibt der Desktop aber schwarz, prüfen Sie die grafische Sitzung und den Desktop-Dienst.
Geben Sie Instanzkennung, Standort, Modell, Zeitpunkt und Zeitzone, Verbindungsmethode, vollständige Fehlermeldung und bereits getestete Schritte an. Erwähnen Sie, ob das System kürzlich neu installiert oder die Sicherheitseinstellungen geändert wurden. So kann das Supportteam Änderungen und Fehler besser einordnen.
Cloud-Mac ab $21.4/Tag. Wählen Sie Modell, Standort und Mietdauer. Nach bestätigter Zahlung und Zuweisung finden Sie die Zugangsdaten in der Konsole. Testen Sie beim ersten Start zunächst SSH und richten Sie anschließend Desktop und Entwicklungsumgebung ein.