Leitfaden für den Fernzugriff

In zehn Minuten nach dem Start
mit Ihrem Mac verbinden

Prüfen Sie zuerst per SSH, ob die Verbindung funktioniert, und öffnen Sie anschließend die Bildschirmfreigabe. Sie erhalten einen exklusiv für Sie bereitgestellten physischen Mac mini mit voll nutzbarer macOS-Oberfläche und Kommandozeile – ideal für Remote-Arbeit, Builds und Tests.

Die zehn Minuten sind ein Richtwert für die Einrichtung, sobald Zugangsdaten, Client und Netzwerk bereitstehen. Sie beziehen sich nicht auf die Bereitstellung der Bestellung. Verbindungsadresse, Ports und Authentifizierung entnehmen Sie bitte dem Kundenportal.

Cloud-Mac mieten Zugangsdaten im Portal
Zugriffsweg auswählen

Desktop per Bildschirmfreigabe, Automatisierung per SSH

Für alltägliche Einstellungen eignet sich die grafische Oberfläche. Builds, Logs und Dateiübertragungen erledigen Sie am besten über die Kommandozeile. Beide Wege ergänzen sich – der Desktop muss nicht bei jedem Build geöffnet bleiben.

Die Tabelle zeigt die Standardports der Dienste. Verwenden Sie für die Verbindung die Ports aus dem Kundenportal.
VerbindungsartGeeignet fürPortAuthentifizierung und Hinweise
macOS-BildschirmfreigabeXcode einrichten, Simulator bedienen, grafische Oberfläche prüfen und remote arbeitenVNC: TCP 5900 (Standard); im Tunnelmodus zusätzlich der SSH-PortMit dem bereitgestellten Systembenutzer anmelden. Eine Desktopverbindung ersetzt keine SSH-Public-Key-Authentifizierung.
VNC-Client eines DrittanbietersmacOS-Desktop unter Windows oder Linux nutzenVNC: TCP 5900 (Standard) oder lokaler Tunnelport des ClientsDer Client muss die Authentifizierung des Servers unterstützen. Deaktivieren Sie die Authentifizierung nicht und lassen Sie nicht alle Quellen zu, um Kompatibilitätsprobleme zu umgehen.
SSH-KommandozeileBuilds ausführen, Logs prüfen, Runner registrieren und Dateien per SFTP übertragenSSH: TCP 22 (Standard); für die öffentliche Portzuordnung gilt das KundenportalNutzen Sie bevorzugt die Public-Key-Anmeldung. Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerprint, bevor Sie ihm vertrauen.

Prüfen Sie zuerst den Port, dann den Client. Bei einem Verbindungs-Timeout sollten Sie zunächst Adresse, ausgehende Verbindungen und Zielport prüfen. Erscheint bereits eine Authentifizierungsaufforderung, ist der Netzwerkpfad in der Regel erreichbar – kontrollieren Sie dann Benutzername, Passwort oder Schlüssel.

Schritte für Ihr Betriebssystem

Drei Clients, eine einheitliche Prüfreihenfolge

Stellen Sie zuerst eine SSH-Verbindung her und prüfen Sie Instanz und Arbeitsverzeichnis. Verbinden Sie sich danach mit dem Desktop. Sie müssen dafür weder die lokale Firewall deaktivieren noch Ihren Cloud-Mac für beliebige Quellen freigeben.

Verbindung unter macOS

  1. Öffnen Sie das Terminal und verbinden Sie sich mit Benutzername, Adresse und SSH-Port aus dem Kundenportal. Prüfen Sie den Fingerprint sorgfältig, wenn er beim ersten Verbindungsaufbau angezeigt wird.
  2. Für den Desktop öffnen Sie „Bildschirmfreigabe“ und geben die Adresse für die Bildschirmfreigabe der Instanz ein. Bei einem Tunnel verwenden Sie stattdessen die lokale Adresse und den lokalen Port.
  3. Geben Sie Systembenutzer und Passwort ein. Prüfen Sie nach dem Anmelden Tastaturbelegung, Bildschirmauflösung und Zeitzone, bevor Sie Ihr Projekt öffnen.
  4. Vergewissern Sie sich vor dem Beenden der Desktop-Sitzung, dass die Build-Logs gespeichert wurden. Das Trennen der Bildschirmfreigabe beendet weder das Mietverhältnis noch automatisch Hintergrundaufgaben.

Erste Prüfung: Das Terminal zeigt Systeminformationen, der Finder lässt sich öffnen und das Projektverzeichnis ist beschreibbar.

Verbindung unter Windows

  1. Prüfen Sie in PowerShell, ob der OpenSSH-Client verfügbar ist. Wenn Sie auf einem Unternehmensgerät keine Komponenten installieren dürfen, fragen Sie zuerst die lokale IT.
  2. Testen Sie Adresse und Port mit einem SSH-Befehl. Dass beim Eingeben des Passworts keine Zeichen angezeigt werden, ist normal. Fügen Sie es deshalb nicht wiederholt ein.
  3. Installieren Sie einen VNC-Client, der die Authentifizierung der macOS-Bildschirmfreigabe unterstützt. Geben Sie Host und Port getrennt ein; das Adressformat kann je nach Client variieren.
  4. Greifen Sie möglichst über einen SSH-Tunnel auf den Desktop zu. Schlägt der Verbindungsaufbau fehl, prüfen Sie erst die Authentifizierungskompatibilität und dann den Dienststatus. Raten Sie nicht wiederholt das Passwort.

Erste Prüfung: SSH-Verbindung steht, VNC-Authentifizierung funktioniert und die Tastenkürzel eignen sich für den Alltag.

Verbindung unter Linux

  1. Verwenden Sie den OpenSSH-Client Ihrer Distribution. Prüfen Sie die Berechtigungen Ihrer lokalen Schlüssel und stellen Sie sicher, dass andere Benutzer keinen Zugriff auf den privaten Schlüssel haben.
  2. Verbinden Sie sich mit den bereitgestellten Angaben per SSH. Für Projektdateien und Build-Ergebnisse können Sie denselben SSH-Zugang auch mit SFTP nutzen.
  3. Wählen Sie einen VNC-Client, der die Serverauthentifizierung unterstützt. Verbinden Sie sich vorzugsweise mit einem per SSH weitergeleiteten lokalen Port, statt den Desktop-Dienst direkt freizugeben.
  4. Prüfen Sie nach dem ersten Anmelden Zwischenablage und Eingabemethode. Übertragen Sie mehrere Dateien per SFTP, statt die Desktop-Zwischenablage zur Projektsynchronisierung zu verwenden.

Erste Prüfung: Schlüsselanmeldung funktioniert, SFTP erreicht das Zielverzeichnis und Eingabe sowie Anzeige auf dem Desktop laufen wie erwartet.

SSH- und Desktop-Tunnel-Befehle

Legen Sie die Variablen im lokalen Terminal fest: SSH_USER steht für den Systembenutzer, SSH_HOST für die Instanzadresse und SSH_PORT für den SSH-Port aus dem Kundenportal. Schreiben Sie Passwörter niemals in Befehle oder Skripte.

ssh -p "$SSH_PORT" "$SSH_USER@$SSH_HOST"

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:15900:127.0.0.1:5900 \
  -p "$SSH_PORT" "$SSH_USER@$SSH_HOST"

Der zweite Befehl funktioniert nur, wenn der Dienst für die Bildschirmfreigabe auf dem entfernten Mac an TCP 5900 lauscht und SSH-Weiterleitungen erlaubt sind. Lassen Sie das Terminal geöffnet und verbinden Sie den VNC-Client mit 127.0.0.1:15900. Das ist ein lokaler Port, kein öffentlicher Port der Instanz. Ist er bereits belegt, wählen Sie einen anderen freien lokalen Port.

Flüssig arbeiten

Weniger Bildlast hilft oft mehr als zusätzliche Bandbreite

Die Leistung eines Remote-Desktops hängt von Latenz, Paketverlust, Bildänderungen und der Kodierungsleistung des Clients ab. Die folgenden Werte sind ein Ausgangspunkt, keine Messwerte oder Bandbreitengarantie für einen Standort. Maßgeblich ist Ihre eigene Netzwerkverbindung.

Starten Sie mit einer niedrigeren Auflösung und einer stabilen Verbindung. Erhöhen Sie die Bildqualität anschließend schrittweise.
Netzwerk und AufgabeAuflösung zum StartBildqualität und FarbtiefeAnpassungen
Mobilfunk oder schwankende Verbindung über weite Entfernungen1280 × 720Adaptive Komprimierung bevorzugen; sofern der Client es unterstützt, 16-Bit-Farbe testenAnimationen auf dem Desktop deaktivieren, große Synchronisierungen pausieren und zuerst die Reaktion auf Eingaben prüfen.
Stabile Breitbandverbindung, Code und Dokumente1920 × 1080Mit automatischer Bildqualität beginnen; erst bei unscharfem Text die Qualität erhöhenImmer nur einen Wert ändern und Scrollen, Fensterbewegungen sowie Tastatureingaben vergleichen.
Oberflächen prüfen und Bilder bearbeitenAb 1920 × 1080Für feinere Farbdetails 24-Bit-Farbe oder höher verwenden, sofern der Client dies unterstütztSkalierung und Kompressionsartefakte prüfen. Für die endgültige Bildqualität ist die exportierte Datei ausschlaggebend.

Der Desktop ist zum Arbeiten da, nicht zur Echtzeitkontrolle von Audio und Video

Videovorschauen, schnelle Animationen und Interaktionen mit hoher Bildrate verändern viele Bildpunkte und belasten die Verbindung. Audio- und Videodateien können remote transkodiert werden. Prüfen Sie das fertige Video anschließend lokal – einzelne ausgelassene Frames auf dem Remote-Desktop sagen nichts über die exportierte Datei aus.

Empfohlene Reihenfolge: Auflösung reduzieren → adaptive Qualität aktivieren → Paketverlust prüfen → Farbtiefe anpassen.

Builds und Übertragungen brauchen keinen dauerhaft offenen Desktop

Nutzen Sie für längere Builds einen Runner oder verwaltete Hintergrundaufgaben und speichern Sie Logs in Dateien. Übertragen Sie Projekte und Build-Ergebnisse per SFTP. Ob Aufgaben nach dem Trennen des Desktops weiterlaufen, hängt davon ab, wie sie gestartet wurden – verlassen Sie sich nicht darauf, dass jeder Terminalbefehl weiterläuft.

Wenn Sie dauerhaft remote arbeiten möchten, testen Sie zuerst einen vollständigen Arbeitsablauf und wählen Sie danach die Mietdauer.

Grenzen beim Testen auf echten Geräten

Ein gestarteter Simulator findet nicht automatisch Ihr Smartphone

Ein exklusiv für Sie bereitgestellter Cloud-Mac und die Netzwerkerreichbarkeit mobiler Geräte sind zwei verschiedene Dinge. Xcode, Simulatoren und Builds können remote ausgeführt werden. Für ein lokales iPhone oder iPad müssen zusätzlich die Gerätezuordnung, das Vertrauen und die Netzwerkerkennung funktionieren.

Weg 1: zuerst den Remote-Simulator testen

Öffnen Sie das Projekt auf dem Cloud-Mac und prüfen Sie, ob Xcode, SDK und Projekteinstellungen zusammenpassen. Führen Sie anschließend den Simulator aus, um Oberfläche, Logik und grundlegende Regressionen zu testen. So lassen sich Probleme mit Build und Laufzeitumgebung zuerst ausschließen.

Ein Simulator ersetzt keine Tests mit Kamera, Sensoren, Mobilfunk, Leistung oder Temperaturverhalten eines echten Geräts. Für diese Funktionen müssen Sie zusätzliche Tests auf echten Geräten einplanen.

Ergebnis: reproduzierbare Build-Daten, Test-Logs und Resultate aus dem Simulator.

Weg 2: Netzwerkbedingungen für Gerätetests prüfen

Für das Debugging über das Netzwerk müssen das Gerät und der Ziel-Mac in der Regel zuerst erfolgreich gekoppelt werden. Außerdem müssen die Anforderungen der jeweiligen Xcode- und Systemversion erfüllt sein. Mac und Gerät müssen einander im Netzwerk finden oder über einen geprüften Netzwerkpfad kommunizieren können.

Ein SSH-Tunnel löst nicht automatisch Probleme mit Geräteerkennung, erstmaliger Kopplung oder Vertrauensstellung. Eine erreichbare öffentliche Adresse allein reicht nicht aus, um drahtlos auf einem echten Gerät zu debuggen.

Vor der Bestellung klären: Kopplungsmethode, Netzwerktopologie, Systemversion des Geräts und erforderliche Zugriffsrechte.

Die Verbindung zu einem Remote-Gerät muss separat geprüft werden. USB-Weiterleitung und andere Lösungen für den Fernzugriff auf Geräte hängen von Protokollkompatibilität, Treibern, erneuter Geräteverbindung und Netzwerkqualität ab. Sie gehören nicht zum standardmäßigen Leistungsumfang und ein Smartphone ist nicht enthalten. Wenn Ihr lokales Gerät mit Xcode auf dem Cloud-Mac verbunden werden muss, teilen Sie unserem Team vorab Gerätemodell, Systemversion, Kopplungsweg und Testziel mit. Wir prüfen die Machbarkeit, bevor Sie die Arbeit einplanen. Für reine Installationsprüfungen können Sie das signierte Build an Tester übergeben, die es lokal auf einem Gerät testen – eine dauerhaft aktive Debugging-Sitzung ist dafür nicht nötig.

Machbarkeit von Gerätetests klären
Nach erfolgreicher Verbindung

Zugriff absichern, dann Projekte und Schlüssel bereitstellen

Ein exklusiv für Sie bereitgestellter physischer Mac teilt seine Rechenressourcen nicht mit anderen Mietern. Die Sicherheit Ihres Kontos ersetzt das jedoch nicht. Erledigen Sie zuerst diese drei Schritte, bevor Sie Build-Zertifikate, Quellcode und Zugangsdaten für Automatisierungen bereitstellen.

  1. Public-Key-Anmeldung einrichten

    Erstellen Sie den Schlüssel auf einem vertrauenswürdigen lokalen Gerät und hinterlegen Sie den öffentlichen Schlüssel in der Autorisierungsdatei des passenden Benutzers auf dem Remote-Mac. Der private Schlüssel bleibt lokal und gehört weder auf den Mac noch in ein Support-Ticket. Öffnen Sie ein weiteres Terminal und testen Sie die Public-Key-Anmeldung. Lassen Sie die ursprüngliche Sitzung als Rückfallmöglichkeit geöffnet, bevor Sie die Passwortauthentifizierung anpassen.

  2. Bereitgestelltes Passwort ändern

    Ändern Sie nach dem ersten Login das Systempasswort und speichern Sie es in einem vertrauenswürdigen Passwortmanager. Passwörter gehören weder in Runner-Konfigurationen noch in den Befehlsverlauf oder ein Projekt-Repository. Vergeben Sie für die Zusammenarbeit nachvollziehbare Zugänge, statt dauerhaft dieselben Zugangsdaten gemeinsam zu nutzen.

  3. Nur benötigte Ports freigeben

    Behalten Sie nur die tatsächlich genutzten SSH- und Desktop-Zugänge bei. Wenn möglich, verwenden Sie einen Tunnel. Prüfen Sie vor Änderungen an Firewall- oder Zugriffsregeln den aktuellen Verwaltungszugang und halten Sie einen Wiederherstellungsweg bereit. Deaktivieren Sie nicht pauschal alle Schutzmaßnahmen, um Verbindungsprobleme zu untersuchen.

Welche Angaben gehören in ein Support-Ticket?

Nennen Sie die Instanz-ID, Betriebssystem und Version des Clients, die Verbindungsart, Zeitpunkt und Zeitzone des Fehlers sowie den genauen Fehlertext. Beschreiben Sie, ob ein Timeout, eine abgelehnte Verbindung oder ein Authentifizierungsfehler auftritt. Sie können einen unkenntlich gemachten Screenshot anhängen, aber keine Passwörter, privaten Schlüssel oder vollständigen Zugangsdaten.

Ticket im Kundenportal erstellen
Vor dem Verbinden prüfen

Erst anmelden, wenn alle vier Voraussetzungen erfüllt sind

Gehen Sie die Punkte der Reihe nach durch. Fehlt etwas, ergänzen Sie es zuerst, statt durch wiederholte Versuche Zeit zu verlieren. Wenn Ihr Unternehmensnetzwerk die benötigten ausgehenden Verbindungen blockiert, beantragen Sie zunächst eine passende Zugriffsregel.

  • Zugangsdaten sicher gespeichert
    Instanzadresse, Systembenutzer, Authentifizierungsdaten und tatsächliche Ports wurden im Kundenportal geprüft und sicher abgelegt.
  • Client installiert
    SSH lässt sich über die Kommandozeile starten. Für die grafische Oberfläche ist ein kompatibler Client für Bildschirmfreigabe oder VNC eingerichtet.
  • Public Key hinterlegt und geprüft
    Bei Public-Key-Authentifizierung ist der öffentliche Schlüssel dem richtigen Benutzer zugeordnet und in einer neuen Sitzung getestet. Der private Schlüssel bleibt lokal.
  • Ausgehende Ports im lokalen Netzwerk erlaubt
    Der tatsächliche SSH-Port ist geprüft. Bei einer direkten Desktopverbindung ist auch der VNC-Port berücksichtigt; bei einem Tunnel zusätzlich der lokale Port.

Notieren Sie nach dem ersten erfolgreichen Test Client-Version, Verbindungsart und funktionierende Einstellungen. Das Team kann die Schritte wiederverwenden, sollte aber nicht Ihren privaten Schlüssel oder Ihr Passwort kopieren.

Erst den Verbindungsweg klären, dann die Arbeit verlagern.

Testen Sie zuerst Desktop, Kommandozeile und die tatsächlichen Aufgaben. Wenn Sie mieten möchten, wählen Sie die passende Konfiguration für Ihre Arbeitslast. Bei einer bestehenden Instanz finden Sie die Zugangsdaten im Kundenportal.

Cloud-Mac mieten Zum Kundenportal