Von den Zugangsdaten zum Arbeitsplatz

Drei Wege zu Ihrem M4

Für die Kommandozeile nutzen Sie SSH, für interaktive Aufgaben den grafischen Desktop und für automatisierte Builds einen CI-Runner. Alle drei Zugänge führen zum selben exklusiven physischen Knoten – nicht zu drei verschiedenen Umgebungen.

Cloud-Mac mieten Im Portal anmelden

Sie haben bereits gemietet? Öffnen Sie im Portal die Details zur Instanz Ihrer Bestellung. Dort finden Sie Hostadresse, SSH-Port, Benutzernamen und Hinweise zur Bereitstellung. Ersetzen Sie in dieser Anleitung alle Host-Platzhalter durch die tatsächlichen Werte Ihrer Instanz.

SSHHost prüfen, Dateien übertragen und Builds starten

DesktopXcode, Simulatoren und macOS bedienen

CI-RunnerProjektaufgaben auf Ihrem physischen Knoten ausführen

Zuerst eine überprüfbare Verbindung herstellen

SSH: Schlüssel erstellen und Host-Alias einrichten

Stellen Sie zuerst die Verbindung zur Kommandozeile her, bevor Sie Desktop und Pipeline einrichten. SSH ist auch der schnellste Weg, die Erreichbarkeit des Knotens und mögliche Authentifizierungsprobleme zu prüfen.

01
Schlüssel lokal erstellen
Führen Sie die Befehle auf Ihrem eigenen Computer aus, nicht auf dem Cloud-Knoten. Schützen Sie den Schlüssel mit einer Passphrase. Einen bereits vorhandenen, dedizierten Schlüssel können Sie weiterverwenden; überschreiben Sie keine Datei, die noch verwendet wird. Der private Schlüssel bleibt immer lokal. An den Knoten übertragen Sie nur den öffentlichen Schlüssel mit der Endung .pub.
```
ssh-keygen -t ed25519 -f ~/.ssh/xcnode_ed25519 -C "xcnode-workstation"
ssh-add ~/.ssh/xcnode_ed25519
```
Wenn ssh-add meldet, dass kein Authentifizierungsagent verbunden ist, prüfen Sie zuerst, ob der SSH-Agent auf Ihrem Computer läuft. Die Passphrase des Schlüssels ist nicht dasselbe wie das Passwort des Remote-Benutzers.
02
Öffentlichen Schlüssel installieren und Host prüfen
Legen Sie die drei Variablen gemäß den Angaben zu Ihrer Instanz fest. Verwenden Sie ssh-copy-id nur, wenn die Bereitstellung eine erstmalige Anmeldung per Passwort erlaubt. Ist der öffentliche Schlüssel bereits hinterlegt, testen Sie direkt die Anmeldung. Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerprint. Bestätigen Sie einen unbekannten Host nicht allein deshalb, weil eine Abfrage erscheint.
```
read -r -p "Host: " NODE_HOST
read -r -p "SSH port: " NODE_PORT
read -r -p "User: " NODE_USER
ssh-copy-id -i ~/.ssh/xcnode_ed25519.pub -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"
ssh -i ~/.ssh/xcnode_ed25519 -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"
```
Die Eingabe der Variablen funktioniert in Bash. Unter macOS können Sie in zsh zuerst bash ausführen. Falls die erstmalige Installation des öffentlichen Schlüssels nicht klappt, nutzen Sie den im Portal angegebenen Weg zur Verwaltung der Zugangsdaten oder erstellen Sie ein Support-Ticket. Versuchen Sie nicht wiederholt, sich mit einem Passwort anzumelden.
03
Alias speichern und Umgebung prüfen
Fügen Sie den Alias in die lokale Datei ~/.ssh/config ein. Ersetzen Sie die Felder in spitzen Klammern durch die Werte Ihrer Instanz und entfernen Sie dabei die Klammern. Windows OpenSSH liest die Datei ebenfalls aus dem Verzeichnis .ssh/config Ihres Benutzerkontos.
```
Host xcnode-work
  HostName <INSTANCE_HOST>
  Port <SSH_PORT>
  User <INSTANCE_USER>
  IdentityFile ~/.ssh/xcnode_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3
```
```
ssh xcnode-work
uname -m
sysctl -n machdep.cpu.brand_string
xcode-select -p
xcodebuild -version
```
uname -m sollte arm64 ausgeben. Der Chipname sollte dem gebuchten Modell entsprechen; maßgeblich ist die tatsächlich auf dem Knoten installierte Xcode-Version. Eine stabile Verbindung sorgt nicht dafür, dass ein unterbrochener Auftrag automatisch weiterläuft. Für lange Builds empfiehlt sich ein Runner oder ein Tool zur Verwaltung persistenter Sitzungen.

Drei Betriebssysteme, unterschiedliche Details

Prüfen Sie zuerst, ob sich ssh -V lokal ausführen lässt. Fehlt ein Hilfsprogramm, bedeutet das nicht, dass der Knoten SSH nicht unterstützt.

Lokalen Client vorbereiten und öffentlichen Schlüssel installieren
Lokales System	SSH-Client	Öffentlichen Schlüssel installieren	Hinweise
macOS	OpenSSH ist im Terminal enthalten	`ssh-copy-id` muss in der Regel separat installiert werden. Alternativ können Sie den öffentlichen Schlüssel gemäß den Bereitstellungshinweisen hinterlegen.	Die Standardshell ist häufig zsh. Übernehmen Sie Bash-spezifische Eingabesyntax nicht unverändert.
Windows	OpenSSH Client in PowerShell verwenden	Verwenden Sie `ssh-copy-id` in WSL oder hinterlegen Sie den öffentlichen Schlüssel im Portal.	PowerShell und WSL haben jeweils ein eigenes Benutzerverzeichnis und eigene Schlüsseldateien.
Linux	OpenSSH-Clientpaket der Distribution	`ssh-copy-id` ist normalerweise enthalten. Falls nicht, installieren Sie zuerst die Clientwerkzeuge.	Setzen Sie die Berechtigungen des privaten Schlüssels auf `600` und die des Verzeichnisses `~/.ssh` auf `700`.

Wenn Sie eine grafische Oberfläche benötigen

Desktop: Am besten über einen SSH-Tunnel

Sobald SSH funktioniert, prüfen Sie den Bildschirmfreigabedienst und die grafische Sitzung. Ein erreichbarer Port bedeutet nicht automatisch, dass der Desktop einsatzbereit ist.

macOS-Bildschirmfreigabe

Auf einem lokalen Mac können Sie den integrierten Client „Bildschirmfreigabe“ verwenden. Der übliche TCP-Port des VNC-Servers ist 5900. Maßgeblich sind jedoch die Angaben zur Instanz – dazu gehören der tatsächliche Port, die Authentifizierung und die Frage, ob der Dienst aktiviert ist.

Wenn der entfernte Host Port 5900 verwendet, richten Sie im lokalen Terminal einen Tunnel ein und lassen Sie das Terminal geöffnet. Hier verwenden wir lokal Port 15900, damit es nicht zu Konflikten mit lokalen Diensten kommt.

ssh -N -L 127.0.0.1:15900:127.0.0.1:5900 \
  -o ExitOnForwardFailure=yes xcnode-work

Öffnen Sie den Client anschließend in einem zweiten Terminal:

open "vnc://127.0.0.1:15900"

Tunnel nur an Loopback gebunden

VNC-Clients für Windows und Linux

Wählen Sie einen VNC-Client, der die Authentifizierung Ihrer Instanz unterstützt, zum Beispiel TigerVNC. Richten Sie zuerst denselben SSH-Tunnel ein. Als Ziel geben Sie im Client 127.0.0.1 und als Port 15900 an.

Je nach Client wird der Port unterschiedlich eingegeben: Manche bieten ein eigenes Portfeld, andere verwenden einen doppelten Doppelpunkt für die vollständige Portnummer. Folgen Sie der Dokumentation Ihres Clients und verwechseln Sie den Port nicht mit der Displaynummer.

Die Authentifizierung der macOS-Bildschirmfreigabe ist nicht immer mit allgemeinen VNC-Clients kompatibel. Prüfen Sie bei fehlgeschlagener Authentifizierung zuerst die Funktionen des Clients und die Bereitstellungshinweise. Schwächen Sie den Zugriffsschutz des Knotens nicht ab, nur um einen Client kompatibel zu machen.

Desktop-Zugangsdaten getrennt von SSH-Schlüsseln verwalten

Erst flüssige Bedienung, dann bessere Bildqualität

Wählen Sie bei der ersten Verbindung automatisch oder eine niedrigere Bildqualität und verwenden Sie nur einen Bildschirm. Vermeiden Sie es, gleichzeitig große Dateien zu übertragen und bewegte Inhalte im Vollbild anzuzeigen. Sobald Text gut lesbar ist und Eingaben zuverlässig ankommen, können Sie Auflösung und Farbqualität schrittweise erhöhen. Schnelle SSH-Dateiübertragungen bedeuten nicht automatisch eine niedrige Latenz am Desktop.

Bei einem schwarzen Bildschirm prüfen Sie der Reihe nach: Läuft der Tunnel noch? Stimmt der Zielport? Ist die Bildschirmfreigabe aktiviert? Gibt es auf dem entfernten Host eine verfügbare grafische Sitzung? Klären Sie bei Sitzungskonflikten die Nutzungszeiten im Team, statt einen Benutzer während eines Builds zwangsweise abzumelden.

Aufgaben automatisch an den Knoten senden

CI einrichten: einmal registrieren, Autostart prüfen

Der Runner führt Aufgaben auf dem Cloud-Mac aus, nicht auf Ihrem lokalen Computer. Testen Sie zuerst die Toolchain mit einem interaktiven Auftrag und richten Sie den Runner anschließend als Dienst ein.

GitHub Actions: Self-hosted Runner

Öffnen Sie die Runner-Einstellungen Ihres Projekts oder Ihrer Organisation und wählen Sie macOS ARM64. Bereiten Sie die Software mit den dort aktuell angegebenen Download- und Prüfbefehlen vor. Die Registrierungs-URL und das kurzlebige Token erhalten Sie auf derselben Einstellungsseite.

cd ~/actions-runner
read -r -p "Registration URL: " RUNNER_URL
read -r -s -p "Registration token: " RUNNER_TOKEN
printf '\n'
./config.sh --url "$RUNNER_URL" --token "$RUNNER_TOKEN" \
  --name xcnode-work --labels xcnode,arm64
unset RUNNER_TOKEN
./run.sh

Führen Sie die Eingabebefehle in Bash aus. Starten Sie einen Testauftrag und prüfen Sie, ob der Runner online ist und den Build abschließt. Beenden Sie anschließend den Vordergrundprozess und installieren Sie den Dienst:

./svc.sh install
./svc.sh start
./svc.sh status

Verwenden Sie in Workflows eindeutige Labels, damit Aufträge nicht auf einem Rechner mit anderer Architektur landen:

runs-on: [self-hosted, macOS, ARM64, xcnode]
steps:
  - run: xcodebuild -version

Das Registrierungstoken ist kein dauerhaftes Projekttoken. Speichern Sie es weder im Repository noch in Build-Ausgaben oder Ticketanhängen.

GitLab Runner

Erstellen Sie einen Runner in Ihrem Projekt oder Ihrer Gruppe und rufen Sie das aktuelle Authentifizierungstoken gemäß den Plattformhinweisen ab. Installieren Sie die Version für macOS ARM64 und registrieren Sie den Runner in einem Terminal der grafischen Sitzung des vorgesehenen Benutzers. Führen Sie Builds nicht als root aus.

gitlab-runner register

Geben Sie interaktiv die Instanz-URL und das Authentifizierungstoken ein und wählen Sie den Executor shell. Versehen Sie den Runner mit den Labels xcnode und arm64 und beschränken Sie ihn auf vertrauenswürdige Projekte.

gitlab-runner install
gitlab-runner start
gitlab-runner status

Prüfen Sie die Umgebung zuerst mit einem einfachen Testauftrag. Signierung und Archivierung können Sie anschließend ergänzen:

build-check:
  tags: [xcnode, arm64]
  script:
    - uname -m
    - xcode-select -p
    - xcodebuild -version

Der Shell-Executor kann auf die Dateien des ausführenden Benutzers zugreifen. Eine exklusiv genutzte Maschine isoliert nicht automatisch nicht vertrauenswürdige Aufgaben unter demselben Konto.

Autostart und interaktive Funktionen getrennt prüfen

Benutzerdienste unter macOS werden normalerweise von launchd verwaltet und können von einer Benutzersitzung abhängen. Prüfen Sie nach der Installation des Dienstes Prozesse, Logs und Warteschlangenstatus. Testen Sie die Wiederherstellung nach einem Neustart zu einem im Team abgestimmten Zeitpunkt. Benötigen Aufgaben einen Simulator oder eine grafische Oberfläche, muss auch die angemeldete Sitzung den Anforderungen entsprechen. Der Online-Status des Runners allein reicht nicht aus.

Beginnen Sie mit einem einzelnen Auftrag und erfassen Sie den tatsächlichen Spitzenwert des Speicherverbrauchs Ihres Projekts, bevor Sie die Parallelität erhöhen. Verwalten Sie Caches getrennt nach Projekt und Xcode-Version und archivieren Sie Build-Artefakte separat. Wenn Signaturmaterial aus dem System-Schlüsselbund verwendet wird, prüfen Sie zusätzlich die Zugriffsrechte des Dienstbenutzers. Ein erfolgreicher Build im Terminal garantiert nicht, dass der Build im Hintergrund funktioniert.

Den Standort anhand Ihres Netzwerks wählen

Vier Standorte: zuerst das Arbeitsnetz testen

In Singapur, Tokio, Seoul und Hongkong stehen jeweils zwei Modellstufen zur Verfügung. Die Verfügbarkeit sehen Sie aktuell im Portal. Die geografische Entfernung ist nur ein erster Anhaltspunkt – auch das Routing des Internetanbieters und die Arbeitszeiten Ihres Teams spielen eine Rolle.

Singapur

Ein guter Ausgangspunkt für Teams in Südostasien. Testen Sie die Desktop-Bedienung über Ihr tatsächliches Büronetzwerk und prüfen Sie anschließend, wie zuverlässig sich Repositories abrufen und Artefakte hochladen lassen.

sg · UTC+8

Tokio

Ein guter Ausgangspunkt für Teams in Japan und Ostasien. Eine ähnliche Zeitzone garantiert keine schnellere Verbindung. Vergleichen Sie die Leistung zu Stoßzeiten und außerhalb der Hauptzeiten.

jp · UTC+9

Seoul

Ein guter Ausgangspunkt für Teams in Südkorea und Nordostasien. Bei einem dauerhaft laufenden Runner ist besonders wichtig, dass der Zugriff auf Code-Repositories und Paketquellen zuverlässig funktioniert.

kr · UTC+9

Hongkong

Ein guter Ausgangspunkt für Teams in Südchina und Südostasien. Stimmen Sie bei gemeinsam genutzten Desktops über Zeitzonen hinweg die Nutzungs- und Abmeldezeiten für grafische Sitzungen vorab ab.

hk · UTC+8

Drei Messwerte: Latenz, Schwankungen und echte Aufgaben

Prüfen Sie die tatsächliche Hostadresse Ihrer zugewiesenen Instanz. Ein Geschwindigkeitstest für die Website ersetzt keinen Test des Knotens. Führen Sie die folgenden Befehle in einer lokalen Bash-Sitzung aus, in der die Knotenvariablen bereits gesetzt sind.

ping -c 20 "$NODE_HOST"
ssh -p "$NODE_PORT" "$NODE_USER@$NODE_HOST" 'uptime'

Unter Windows PowerShell verwenden Sie ping -n 20 <INSTANCE_HOST>. Notieren Sie Paketverlust und Schwankungsbreite der Laufzeiten. Testen Sie anschließend einen echten Git-Abruf oder die Übertragung eines Build-Artefakts. ICMP kann durch Netzwerkrichtlinien gefiltert werden. Antwortet ping nicht, testen Sie den tatsächlichen SSH-Port trotzdem separat.

Wiederholen Sie die Tests im üblichen Teamnetzwerk und während der typischen Arbeitszeiten. Diese Anleitung gibt keine allgemeine Latenzgarantie; die Ergebnisse gelten nur für den jeweiligen Netzwerkpfad zum Testzeitpunkt. Wenn Sie noch nicht gemietet haben, fragen Sie über die Support-E-Mail nach einer geeigneten Testmethode. Verwenden Sie keine vermuteten Hostadressen.

Die Begriffe im Überblick

Acht Begriffe rund um Verbindungen erklärt

Wenn Sie Ressourcen, Verbindungsprotokolle und Aufgabenplanung auseinanderhalten, lassen sich Probleme gezielter eingrenzen.

Physischer Knoten: Ein Apple-Silicon-Rechner, auf dem macOS läuft. Mit Ihrer Bestellung wird Ihnen das ganze Gerät zugewiesen, keine virtuelle Maschine auf einem gemeinsam genutzten Host.
Exklusive Nutzung: Während der Mietdauer ist der physische Rechner einem einzelnen Kunden zugewiesen. CPU, GPU und Unified Memory werden nicht mit anderen Kunden geteilt.
VNC: Ein Protokoll zur Übertragung des Bildschirms sowie von Tastatur- und Mauseingaben. Dienststatus, Port und Authentifizierung müssen separat geprüft werden.
Screen Sharing: Die Bildschirmfreigabe-Funktion von macOS und der zugehörige Client für den Zugriff auf eine entfernte grafische Sitzung. Sie ersetzt keine SSH-Verbindung zur Kommandozeile.
SSH-Schlüssel: Ein Zugangsnachweis aus öffentlichem und privatem Schlüssel. Der öffentliche Schlüssel kann auf dem Knoten hinterlegt werden; der private bleibt auf einem geschützten Client.
Self-hosted Runner: Ein Agent, der CI-Aufgaben auf Ihrem eigenen Knoten ausführt und dessen Toolchain, Berechtigungen und Cache verwendet.
Thunderbolt 5-Verbund: Eine optionale Verbindung zwischen separat ausgewählten Knoten. Sie macht aus mehreren Geräten kein gemeinsames Speichersystem; Software muss weiterhin für verteilte Aufgaben ausgelegt sein.
Unified Memory: Bei Apple Silicon nutzen CPU und GPU denselben Speicherpool. Planen Sie den Speicherbedarf für Builds, Simulatoren und Modellaufgaben daher gemeinsam.

Sicher verbinden und Zugriffe begrenzen

Schlüssel testen und Zugriffe absichern

Ändern Sie die Authentifizierung nicht, solange die einzige Verbindung noch nicht geprüft ist. Lassen Sie die aktuelle Sitzung offen und bestätigen Sie die Anmeldung mit dem neuen Schlüssel in einem zweiten Terminal, bevor Sie die Knoteneinstellungen ändern.

Passwortanmeldung deaktivieren

Prüfen Sie die sshd-Konfiguration und eingebundene Dateien für die installierte macOS-Version. Aktivieren Sie die Anmeldung per öffentlichem Schlüssel und deaktivieren Sie Passwort- sowie interaktive Tastatur-Authentifizierung. Ändern Sie nicht nur einen einzelnen Eintrag, der von einer anderen Datei überschrieben werden könnte.

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Prüfen Sie vor dem Anwenden der Konfiguration die Syntax mit sudo /usr/sbin/sshd -t und übernehmen Sie die Änderungen gemäß den Angaben zu Ihrer Instanz.

Nur erforderliche Ports öffnen

Stellen Sie die SSH-Verbindung über den bei der Bereitstellung angegebenen Port her. Greifen Sie auf den grafischen Desktop möglichst über einen lokalen Tunnel zu und legen Sie Port 5900 nicht im öffentlichen Netzwerk offen. Schließen Sie temporäre Testdienste nach der Verwendung und prüfen Sie sowohl die Bindeadresse als auch die Firewall-Regeln.

lsof -nP -iTCP -sTCP:LISTEN

Runner verbinden sich in der Regel selbst mit dem CI-Dienst. Öffnen Sie deshalb keine zusätzlichen eingehenden Verwaltungsports.

Zugangsdaten pro Person und Aufgabe verwalten

Jedes Teammitglied sollte einen eigenen öffentlichen Schlüssel verwenden. Entfernen Sie die entsprechende Berechtigung, wenn jemand das Team verlässt. Lassen Sie Runner nur vertrauenswürdige Repository-Aufgaben ausführen und speichern Sie Projektschlüssel als geschützte Variablen auf der CI-Plattform, nicht in Skripten oder Projektdateien.

Wenn sich der Host-Fingerprint ändert, prüfen Sie zuerst, ob die Instanz neu installiert wurde. Löschen Sie nicht einfach den lokalen Eintrag und verbinden Sie sich erneut.

Hängen Sie an Tickets nur bereinigte Logs, die Bestellnummer und die fehlgeschlagenen Schritte an. Senden Sie keine privaten Schlüssel, Passwörter oder Registrierungstoken.

Isolation und Datenverarbeitung Checkliste zur Fehlerbehebung

Lokale Schritte in einen reproduzierbaren Remote-Arbeitsplatz verwandeln

Wählen Sie zuerst Modell und Mietdauer und rufen Sie dann die Zugangsdaten Ihrer Instanz ab. Beginnen Sie mit der SSH-Prüfung und verbinden Sie anschließend Desktop und Build-Warteschlange Schritt für Schritt. Wenn es bei einer bestehenden Instanz hakt, reichen Sie im Portal einen bereinigten Fehlerbericht ein.

Cloud-Mac mieten Im Portal anmelden und Ticket erstellen