Fernzugriff · Erst verbinden, dann bauen

Mit Ihrem Cloud-Mac verbinden

Öffnen Sie die macOS-Oberfläche per VNC und führen Sie Skripte und CI über SSH aus. Sie verbinden sich mit einem dedizierten physischen Mac, nicht mit einer virtuellen Maschine. Nutzen Sie für Xcode-Debugging und automatisierte Builds jeweils den passenden Zugang.

Ist Ihr Mac bereits bereitgestellt? Halten Sie Host-Adresse, SSH-Port, Benutzernamen und Zugangsdaten bereit. Im Folgenden empfehlen wir, VNC durch einen SSH-Tunnel zu leiten.

Grafische Bedienung
VNC-Bildschirmfreigabe
Befehle ausführen
SSH / Runner
Grafische macOS-Arbeitsumgebung Ansicht nach der Verbindung
Xcode-Projekt Release-Build prüfen

Grafische Oberfläche und Kommandozeile auf demselben physischen Mac

BuildSettings.xcconfigRelease
CONFIGURATION = Release
SDKROOT = iphoneos
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym
ENABLE_TESTABILITY = NO
ArchivierenSignierenExportieren
Simulatorvorschau
Oberfläche prüfen Layout · Interaktion
VNC: Desktop anzeigen und bedienen SSH: Build-Befehle ausführen
Schematische Darstellung des Arbeitsbereichs, kein Live-Desktop und keine Leistungsangabe. Die tatsächliche Systemoberfläche und Tool-Version hängen von der Host-Konfiguration ab.
Den passenden Zugang wählen

Möchten Sie den Bildschirm sehen oder nur Befehle ausführen?

Wenn Sie Ihre Toolchain zum ersten Mal einrichten, können Sie die grafischen Einstellungen zunächst per Bildschirmfreigabe prüfen. Sobald die Pipeline zuverlässig läuft, übernimmt der Runner die Arbeit über die Kommandozeile. Beide Zugänge führen zum selben Mac – für grafische Aufgaben brauchen Sie keine separate Build-Umgebung.

Grafische Oberfläche

VNC-Bildschirmfreigabe

Ideal, um Xcode zu öffnen, den Simulator zu prüfen, Keychain-Einstellungen aufzurufen und Schritte mit Mausbedienung zu untersuchen. Sie sehen den Bildschirm des Remote-Macs; der Build läuft nicht lokal.

  • Verwenden Sie zunächst einen einzelnen Bildschirm mit moderater Auflösung. Prüfen Sie, ob Text, Maus und Tastatur funktionieren.
  • Verbinden Sie sich am besten über einen SSH-Tunnel, statt den VNC-Port direkt im Internet freizugeben.
  • Wenn Sie den Viewer schließen, wird der Mac nicht heruntergefahren. Längere Aufgaben sollten über CI oder eine wiederaufnehmbare Sitzung laufen.
Geeignet für: UI-Debugging, Ersteinrichtung, interaktive Fehlersuche
Kommandozeile

SSH und selbst gehosteter Runner

Ideal, um Abhängigkeiten zu installieren, xcodebuild auszuführen, Logs auszuwerten und einen CI-Runner zu registrieren. SSH überträgt kein Desktopbild. Für Skripte im Alltag muss VNC nicht gleichzeitig verbunden sein.

  • Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerprint, bevor Sie den Hostschlüssel akzeptieren.
  • Verwenden Sie für die interaktive Verwaltung vorzugsweise SSH-Schlüssel. Automatisierte Aufgaben sollten eigene, widerrufbare Zugangsdaten erhalten.
  • Lassen Sie dauerhafte Builds vom Runner-Dienst ausführen, statt ein Terminal auf dem Laptop geöffnet zu halten.
Geeignet für: automatisierte Builds, Abhängigkeitsverwaltung, Log-Analyse

Behandeln Sie VNC-Desktoppasswort, SSH-Anmeldepasswort und Passphrase des SSH-Schlüssels als drei verschiedene Zugangsdaten. Prüfen Sie bei Verbindungsproblemen zuerst, welche Zugangsdaten zum jeweiligen Protokoll gehören, bevor Sie Client-Einstellungen ändern.

macOS-Client

Verbindung über den Finder, Desktopsteuerung mit Bildschirmfreigabe

Richten Sie zuerst den SSH-Tunnel wie unten beschrieben ein und verbinden Sie sich anschließend mit der lokalen Weiterleitungsadresse. So läuft der VNC-Datenverkehr durch einen verschlüsselten Tunnel und der Remote-Desktop-Port muss nicht separat freigegeben werden.

  1. 01

    Hostdaten prüfen

    Melden Sie sich im Kundenportal an und öffnen Sie die Verbindungsdaten der entsprechenden Instanz. Notieren Sie Host-Adresse, SSH-Port und Benutzernamen; prüfen Sie die VNC-Zugangsdaten separat. Weichen Adresse oder Port vom Beispiel ab, verwenden Sie immer die tatsächlichen Instanzdaten.

  2. 02

    Tunnel geöffnet lassen

    Führen Sie den Weiterleitungsbefehl auf Ihrem lokalen Rechner aus. Bei Verwendung von -N ist es normal, dass nach erfolgreicher Verbindung keine interaktive Eingabeaufforderung erscheint. Lassen Sie das Terminal geöffnet. Bei einer Fehlermeldung beheben Sie zuerst den Fehler, statt die Desktopverbindung weiter auszuprobieren.

  3. 03

    VNC-Adresse eingeben

    Wählen Sie im Finder „Gehe zu → Mit Server verbinden“ oder drücken Sie ⌘ Kund geben Sie vnc://127.0.0.1:15900ein. macOS öffnet die App „Bildschirmfreigabe“. Geben Sie anschließend die VNC-Zugangsdaten des Remote-Macs ein.

  4. 04

    Erst testen, dann Bildqualität anpassen

    Prüfen Sie zunächst, ob Sie den Finder bedienen, Text eingeben und Xcode öffnen können. Wählen Sie den Steuerungsmodus statt des reinen Anzeigemodus. Passt das Bild nicht in das lokale Fenster, aktivieren Sie zuerst die Skalierung und passen die Bildqualität anschließend an Ihre Netzwerkverbindung an.

Die lokale Loopback-Adresse funktioniert nur auf dem Rechner, auf dem der Tunnel läuft. Wenn Sie den Viewer auf einem anderen Rechner öffnen, müssen Sie dort einen eigenen Tunnel einrichten. Die lokale Verbindung des ersten Rechners lässt sich nicht weiterverwenden.

Windows- / Linux-Client

Host und Port getrennt eingeben, mit konservativer Bildqualität starten

Verwenden Sie einen VNC-Viewer wie TigerVNC. Unter Windows können Sie den OpenSSH-Client, unter Linux das ssh-Terminalprogramm zum Einrichten des Tunnels nutzen. Verbinden Sie den Desktop-Viewer anschließend mit dem lokalen Weiterleitungsport.

Windows: Erst SSH starten, dann den Viewer öffnen

Führen Sie den Tunnelbefehl in PowerShell oder Windows Terminal aus. Wenn das System meldet, dass sshnicht gefunden wurde, prüfen Sie, ob der OpenSSH-Client in Windows installiert ist.

Geben Sie im Host-Feld des VNC-Viewers 127.0.0.1und im Port-Feld 15900ein. Manche Clients interpretieren die Zahl nach einem einzelnen Doppelpunkt als Display-Nummer. Gibt es nur ein Adressfeld, verwenden Sie das Format für einen expliziten Port, das der jeweilige Client vorsieht.

Tastaturbelegung: Prüfen Sie zuerst die Tasten Command und Option sowie häufig verwendete Kurzbefehle.

Linux: Tunnel und Bildanzeige getrennt prüfen

Lassen Sie den SSH-Tunnel in einem Terminal geöffnet und starten Sie anschließend den grafischen VNC-Viewer. Ist der Tunnel beendet, kann sich der Viewer nicht mit dem lokalen Port verbinden – das bedeutet nicht, dass das Remote-Desktop-Passwort falsch ist.

Installieren Sie den Client über den Paketmanager, wählen Sie eine Version, die das verwendete Authentifizierungsverfahren unterstützt. Bei der Meldung „Nicht unterstützter Sicherheitstyp“ prüfen Sie zuerst die Kompatibilität. Deaktivieren Sie nicht einfach die Authentifizierung und schwächen Sie nicht die Sicherheitseinstellungen des Servers ab.

Netzwerk prüfen: Stellen Sie sicher, dass der Client tatsächlich den lokalen Weiterleitungsport verwendet.
Dies sind empfohlene Ausgangswerte, keine Zusage für Bildqualität oder Bildrate. Die Bezeichnungen der Optionen unterscheiden sich je nach Viewer-Version.
Einstellung Empfehlung zum Start Wann anpassen?
Farbtiefe Automatisch wählen; bei eingeschränkter Verbindung 16 Bit testen Für Screenshots, Farbprüfung oder kleine Schrift auf volle Farbtiefe umstellen. Eine geringere Farbtiefe eignet sich nicht zur Farbkontrolle.
Kodierung und Komprimierung Automatische Kodierung beibehalten und adaptive Komprimierung verwenden Ruckelt das Verschieben von Fenstern deutlich, erhöhen Sie die Komprimierung moderat. Wird Text unscharf, reduzieren Sie die verlustbehaftete Komprimierung.
Desktopgröße Zunächst 1440 × 900 oder 1600 × 900 verwenden Erhöhen Sie die Auflösung erst, wenn die Bedienung stabil läuft. So vermeiden Sie, gleich zu Beginn große Mengen hochauflösender Bilddaten zu übertragen.
Kontinuierliche Aktualisierung Adaptive Aktualisierung verwenden und unnötige Daueraktualisierungen deaktivieren Erhöhen Sie die Aktualisierungsrate nur, wenn Sie dynamische Oberflächen untersuchen. Beim Bearbeiten von Code ist eine Bildwiederholrate wie bei Videos nicht erforderlich.
Zwischenablage Bei Bedarf aktivieren; bei sensiblen Vorgängen die Synchronisierung deaktivieren Prüfen Sie vor dem Kopieren von Zertifikatspasswörtern oder Zugangsdaten, in welche Richtung die lokale und die Remote-Zwischenablage synchronisiert werden.
Empfohlener Verbindungsweg

VNC durch einen SSH-Tunnel leiten

Die folgende Adresse dient nur als Dokumentationsbeispiel und kann nicht direkt verwendet werden. Ersetzen Sie 192.0.2.10 und macuser und den Port durch die tatsächlichen Verbindungsdaten aus dem Kundenportal. Im Beispiel lauscht der VNC-Dienst auf dem Remote-Host an Port 5900 .

Lokaler Viewer127.0.0.1:15900
Verschlüsselter SSH-TunnelHost-Adresse und SSH-Port
VNC-Dienst auf dem Remote-Host127.0.0.1:5900
Auf Ihrem lokalen Rechner ausführen
ssh -N -T -L 127.0.0.1:15900:127.0.0.1:5900 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -p 22 macuser@192.0.2.10

Was macht dieser Befehl?

-L bindet den Listener nur an die lokale Loopback-Adresse. Der erste Port ist der lokale Einstiegspunkt, der letzte Port gehört zum VNC-Dienst auf dem Remote-Host.-p gibt den SSH-Port an, nicht den VNC-Port.-N -T leitet nur Verbindungen weiter und öffnet kein interaktives Terminal auf dem Remote-Host.

Verbindung prüfen und beenden

Prüfen Sie beim ersten Verbindungsaufbau den SSH-Fingerprint. Sobald die Verbindung steht, verbinden Sie den Viewer mit dem lokalen Port. Drücken Sie Ctrl C um den Tunnel zu schließen. Ist der lokale Port bereits belegt, ersetzen Sie 15900 durch einen anderen freien Port und passen Sie die Viewer-Adresse entsprechend an.

Fehler schrittweise eingrenzen

Bei einer Zeitüberschreitung prüfen Sie Adresse, SSH-Port und Zugriffsbeschränkungen. Bei fehlgeschlagener Authentifizierung kontrollieren Sie Benutzernamen und Schlüssel. Wird die Weiterleitung zum Ziel abgelehnt, prüfen Sie den VNC-Dienst und den Port auf dem Remote-Host. Ändern Sie nicht bei jedem Verbindungsproblem das Passwort.

Schlüsselanmeldung testen, bevor Sie Passwortanmeldungen deaktivieren

Erstellen Sie einen eigenen Ed25519-Schlüssel für Ihren lokalen Rechner und schützen Sie den privaten Schlüssel mit einer Passphrase. Fügen Sie nur den Inhalt des öffentlichen Schlüssels zur Datei des Remote-Benutzers hinzu: ~/.ssh/authorized_keysLassen Sie den privaten Schlüssel auf Ihrem lokalen Rechner. Laden Sie ihn weder auf einen Host noch in ein Repository oder ein Support-Ticket hoch.

Wenn bereits ein Schlüssel mit demselben Namen existiert, überschreiben Sie ihn nicht. Verwenden Sie einen neuen Dateinamen und geben Sie ihn beim Verbindungsaufbau mit -i an. Öffentliche Schlüsseldateien enden auf .pub , private Schlüsseldateien haben diese Endung nicht.

Eigenen Verbindungsschlüssel erstellen
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/armrdp_ed25519

Unter macOS und Linux sollten Sie das Verzeichnis ~/.ssh des Remote-Benutzers üblicherweise auf die Berechtigung 700und die Dateiauthorized_keys auf die Berechtigung 600setzen. Beschränken Sie den Zugriff auf den privaten Schlüssel unter Windows über die Dateiberechtigungen. Unix-Berechtigungsbefehle sollten nicht einfach übernommen werden.

Bild und Verbindung

Erst die Bildlast reduzieren, dann die Entfernung des Standorts bewerten

Der Build läuft auf dem Remote-Host. Die Reaktionsfähigkeit des Desktops hängt außerdem von Ihrem lokalen Netzwerk, der netzübergreifenden Route, der Auflösung und den Bildänderungen ab. Ziehen Sie aus der Reaktion beim Verschieben eines VNC-Fensters keine Rückschlüsse auf die Build-Leistung des Hosts. Auch die geografische Entfernung ist kein direkter Messwert für die Latenz.

  1. 01

    Bildfläche zuerst verkleinern

    Verwenden Sie nur einen Bildschirm und reduzieren Sie hochauflösende Desktops, animierte Hintergründe und Animationen in mehreren Fenstern. Eine kleinere Größe des Remote-Desktops verringert die zu übertragenden Bilddaten stärker als das bloße Verkleinern des lokalen Viewer-Fensters.

  2. 02

    Immer nur eine Einstellung ändern

    Testen Sie Auflösung, Farbtiefe und Komprimierung nacheinander. Wiederholen Sie dabei dieselbe Aktion, etwa dasselbe Projekt zu öffnen oder dasselbe Fenster zu verschieben. Wenn Sie mehrere Optionen gleichzeitig ändern, lässt sich kaum feststellen, welche Einstellung geholfen hat.

  3. 03

    Anschließend den Netzwerkpfad prüfen

    Pausieren Sie große lokale Dateiübertragungen und nutzen Sie nach Möglichkeit eine stabile kabelgebundene Verbindung. Vergleichen Sie die Reaktion in SSH mit der Aktualisierung des VNC-Bildes: Läuft SSH flüssig, während das Bild verzögert reagiert, prüfen Sie zuerst die Bildeinstellungen, statt sofort das Modell zu wechseln.

Geografische Lage und Zeitzonen der fünf Standorte. Die Angaben sind keine Messungen der Latenz zu einzelnen Städten. Die aktuelle Verfügbarkeit sehen Sie im Kundenportal.
Standort Lokale Zeitzone Bei der Auswahl beachten
Singapur UTC+8 Wenn sich Ihr Team überwiegend in Südostasien befindet, eignet sich dieser Standort als erster Verbindungstest.
Japan (Tokio) UTC+9 Wenn sich Ihr Team überwiegend in Japan oder Ostasien befindet, vergleichen Sie die tatsächliche Netzwerkroute zu diesem Standort.
Südkorea (Seoul) UTC+9 Wenn sich Ihr Team überwiegend in Südkorea oder Nordostasien befindet, beziehen Sie das Routing Ihres Internetanbieters in die Auswahl ein.
Hongkong UTC+8 Wenn sich Ihr Team überwiegend in Südchina oder Südostasien befindet, prüfen Sie Bedienbarkeit und Zugriffsweg zum Repository.
US-Westküste UTC−8 / UTC−7 Wenn sich Ihr Team überwiegend an der US-Westküste befindet, prüfen Sie zuerst diesen Standort. Die Zeitzone ändert sich mit der Sommerzeit.

Wenn Sie den Desktop nur gelegentlich einrichten, sollten Sie bei der Standortwahl auch die Verbindung zu Ihrem Code-Repository, dem Abhängigkeits-Cache und dem Upload von Artefakten berücksichtigen. Bei dauerhaften Builds haben eine stabile Toolchain und Pipeline Vorrang. VNC muss dafür nicht die ganze Nacht verbunden bleiben.

Verbindungssicherheit

Bei jeder Rechteänderung einen getesteten Zugangsweg behalten

Die Reihenfolge der Sicherheitseinstellungen ist wichtig. Prüfen Sie zuerst, ob der neue Zugangsweg funktioniert, und widerrufen Sie erst danach den alten. Ändern Sie nicht gleichzeitig Schlüssel, erlaubte Quelladressen und Authentifizierungsregeln – sonst lässt sich die Fehlerursache kaum eingrenzen.

Bevor Sie die Passwortanmeldung deaktivieren

Lassen Sie die aktuelle SSH-Sitzung geöffnet. Starten Sie in einem zweiten Terminal eine neue Verbindung mit dem vorgesehenen privaten Schlüssel und prüfen Sie, ob die benötigten Verwaltungsrechte vorhanden sind. Passen Sie erst danach die SSH-Passwortauthentifizierung an. Prüfen Sie vorab die Syntax der Konfiguration und wenden Sie die Änderungen entsprechend der Dienstverwaltung des Systems an.

Erfolgreich ist der Test, wenn Sie sich in einer neuen Sitzung mit einem öffentlichen Schlüssel anmelden und die benötigten Befehle ausführen können.

Bevor Sie Quell-IP-Adressen einschränken

Prüfen Sie zunächst, ob Ihre öffentliche lokale IP-Adresse statisch ist. Erlauben Sie sie anschließend in den passenden Netzwerk- oder Host-Zugriffsregeln. Behandeln Sie die wechselnde externe IP Ihres Heimnetzwerks nicht als dauerhaft. Wenden Sie Firewall-Befehle nicht auf Schnittstellen an, deren Funktion Sie nicht kennen.

Erfolgreich ist der Test, wenn die erlaubten Netzwerke eine Verbindung herstellen können und andere Quellen keinen Zugriff auf den betreffenden Port haben.

Zugangsdaten regelmäßig erneuern

Verwenden Sie für jedes Teammitglied und jeden Automatisierungsjob eigene Schlüssel. Verlässt ein Mitglied das Team, geht ein Gerät verloren oder könnte ein Schlüssel offengelegt worden sein, richten Sie zuerst einen neuen öffentlichen Schlüssel ein und testen Sie ihn. Entfernen Sie danach den alten Schlüssel. Prüfen Sie außerdem gespeicherte CI-Zugangsdaten und zugehörige Zugriffsprotokolle.

Erfolgreich ist der Wechsel, wenn der alte Schlüssel widerrufen ist und der aktuelle Runner sowie die Verwaltungsverbindung weiterhin funktionieren.

Immer noch keine Verbindung? Grenzen Sie das Problem ein

Erstellen Sie im Kundenportal ein Support-Ticket. Geben Sie die Host-ID, Betriebssystem und Version des Clients, verwendetes Protokoll, den genauen Wortlaut der Fehlermeldung, Zeitpunkt und Zeitzone sowie an, ob Sie einen SSH-Tunnel verwenden. Schwärzen Sie in Screenshots Passwörter, Tokens und andere sensible Daten. Senden Sie weder private Schlüssel noch vollständige Zertifikate.

Erst verbinden, dann Builds an den Runner übergeben

Für einen kurzen Test können Sie tageweise mieten – ab $21.1/Tag. Prüfen Sie zuerst, ob SSH und Bildschirmfreigabe funktionieren. Fixieren Sie anschließend Xcode- und Abhängigkeitsversionen, damit tägliche Builds nicht mehr davon abhängen, dass Ihr lokaler Rechner ständig online ist.