Erst verbinden, dann testen

Befehle per SSH, Desktop per VNC,
beides funktioniert

Sie verbinden sich mit einem exklusiv für Sie bereitgestellten physischen Mac, nicht mit einer virtuellen Maschine. Rufen Sie auf der Detailseite Ihrer Maschine im Portal IP-Adresse, Port und Zugangsdaten ab. Führen Sie Builds und Tests per SSH aus und prüfen Sie die macOS-Oberfläche per VNC. Beide Zugriffsarten lassen sich kombinieren – Sie müssen nicht jeden Build am Remote-Desktop starten.

Cloud-Mac mieten Im Portal anmelden

Bereits bestellt? Prüfen Sie zuerst, ob Ihre Maschine bereitgestellt wurde. Port, Benutzername und Authentifizierung finden Sie in den Details Ihrer Instanz – übernehmen Sie keine Beispielwerte.

Zugriff passend zur Aufgabe wählen

Builds per SSH, GUI-Probleme per VNC

Sorgen Sie zuerst für eine stabile Kommandozeilenverbindung und öffnen Sie anschließend den Desktop. So lassen sich Netzwerk- und Authentifizierungsprobleme getrennt untersuchen. Außerdem beansprucht die Desktop-Aktualisierung dann nicht die Bandbreite, die für Build-Protokolle benötigt wird.

SSH: Befehle auf der Maschine ausführen

Ideal für xcodebuild, Skripte, Protokolle und Build-Artefakte. Sie können das macOS-Terminal, OpenSSH in Windows Terminal oder einen SSH-Client unter Linux verwenden.

  • Den SSH-Port finden Sie in den Instanzdetails. 22 ist ein gängiger Standardwert, gilt aber nicht zwangsläufig für Ihre Instanz.
  • Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerabdruck. Authentifizieren Sie sich erst, wenn Sie das Ziel bestätigt haben.
  • Richten Sie die Anmeldung per öffentlichem Schlüssel ein. Der private Schlüssel bleibt auf Ihrem Gerät und gehört weder ins Projekt-Repository noch in ein Support-Ticket.
  • Führen Sie längere Aufgaben in einer eingerichteten persistenten Sitzung oder einem Pipeline-Runner aus. Eine offene lokale Terminalsitzung ist keine zuverlässige Absicherung für laufende Tasks.
SSH- und Build-Beispiele

VNC: macOS-Desktop direkt öffnen

Geeignet, um Projekteinstellungen anzupassen, Simulatoransichten zu prüfen und Probleme zu untersuchen, die nur in der grafischen Oberfläche auftreten. Verwenden Sie die macOS-Bildschirmfreigabe oder einen kompatiblen Client wie RealVNC. Welche Authentifizierung unterstützt wird, hängt vom Client und den Instanzeinstellungen ab.

  • Geben Sie im Client die IP-Adresse und den VNC-Port der Instanz ein. Verwenden Sie für den Desktop nicht den SSH-Port.
  • Nutzen Sie die Desktop-Zugangsdaten aus den Instanzdetails. Gehen Sie nicht davon aus, dass dieselbe Authentifizierung wie bei SSH gilt.
  • Starten Sie mit einer Auflösung von 1440 × 900 und passen Sie sie anschließend an Ihren Bildschirm und Ihre Netzwerkverbindung an.
  • Wenn Ihr Client es unterstützt, testen Sie zunächst eine Farbtiefe von 16 Bit. Für eine genauere Farbbeurteilung können Sie die Bildqualität anschließend erhöhen.
Desktop-Einstellungen optimieren

VNC ersetzt keinen lokalen Zugriff auf USB-Geräte. Simulator-Tests lassen sich direkt mit dem Remote-Desktop planen. Wenn Ihre Tests externe Geräte benötigen, prüfen Sie zuerst die Anschlussmöglichkeiten und wählen Sie danach das passende Mietmodell.

Von der Verbindung zum Testergebnis

Fingerabdruck prüfen, dann Projektbefehle ausführen

Das folgende Beispiel dient der Veranschaulichung und zeigt keine Live-Ergebnisse eines aktuellen Standorts. Setzen Sie die Umgebungsvariablen vorab lokal auf die tatsächlichen Werte Ihrer Instanz. App ist ein Beispiel-Scheme – ersetzen Sie es vor der Ausführung durch einen Namen, der in Ihrem Projekt existiert.

metalvnc — tokyo-node — zsh 
$ ssh -p "$SSH_PORT" "$MAC_USER@$MAC_IP"

The authenticity of host cannot be established.
ED25519 key fingerprint is displayed by your SSH client.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes
Authenticated using publickey.

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcrun simctl list devices available
== Devices ==
Available simulators are listed by the installed runtime.

$ xcodebuild -scheme App -destination 'platform=iOS Simulator' test
Test Suite 'AppTests' started.
Executed 128 tests, with 0 failures.
** TEST SUCCEEDED **

$ fastlane beta
Build processing completed.
Upload completed successfully.
fastlane finished successfully.

Reihenfolge: SSH-Authentifizierung bestätigen → Toolchain prüfen → Simulatoren prüfen → Tests ausführen → Build- und Upload-Ergebnis kontrollieren.

Die 128 bestandenen und 0 fehlgeschlagenen Tests im Beispiel veranschaulichen lediglich, wie sich Protokolle lesen lassen. Anzahl, Dauer und Upload-Ergebnis hängen von Ihrem Projekt ab.

Fingerabdruck stimmt nicht überein? Erst prüfen

Vergleichen Sie den beim ersten Verbindungsaufbau angezeigten Fingerabdruck mit einer vertrauenswürdigen Quelle. Wird auf der Detailseite keiner angegeben, lassen Sie ihn über ein Ticket im Portal bestätigen. Wenn später eine Änderung der Host-Identität gemeldet wird, löschen Sie nicht einfach den alten Eintrag, um die Prüfung zu umgehen. Klären Sie zuerst, ob die Maschine neu installiert oder ersetzt wurde.

Ein ausführbarer Befehl heißt nicht, dass das Projekt bereit ist

Prüfen Sie vor dem Test den Xcode-Pfad, die Simulator-Runtime, Projektabhängigkeiten und das freigegebene Scheme. Für fastlane beta müssen im Projekt die passende Lane, Signaturmaterialien und Upload-Zugangsdaten vorhanden sein. Der Befehl ist keine universelle Upload-Lösung für beliebige Projekte.

Standorte unter gleichen Bedingungen vergleichen

Zuerst die Round-Trip-Latenz messen

Zur Auswahl stehen Singapur, Tokio, Seoul und Hongkong. Die Verbindung zwischen Ihrem Standort und dem jeweiligen Knoten beeinflusst die Reaktionszeit stärker als die geografische Entfernung. Auch verschiedene Internetanbieter in derselben Stadt können unterschiedliche Ergebnisse liefern.

Datenstatus: Für einzelne Städte liegen derzeit keine überprüfbaren Messwerte vor. Die Tabelle kennzeichnet diese daher korrekt als „Nicht gemessen“ und gibt keine Schätzungen als gemessene Medianwerte aus. Messen Sie Ihre eigene Verbindung vor der Auswahl. Wenn Sie die Verbindung vorab einschätzen möchten, kontaktieren Sie uns per E-Mail oder über ein Ticket im Portal.

Ausgangsstadt × Standort: mediane ICMP-Round-Trip-Zeit in ms
AusgangsstadtSingapurTokioSeoulHongkong
ShanghaiNicht gemessenNicht gemessenNicht gemessenNicht gemessen
ShenzhenNicht gemessenNicht gemessenNicht gemessenNicht gemessen
TaipehNicht gemessenNicht gemessenNicht gemessenNicht gemessen
BangkokNicht gemessenNicht gemessenNicht gemessenNicht gemessen
SydneyNicht gemessenNicht gemessenNicht gemessenNicht gemessen
Los AngelesNicht gemessenNicht gemessenNicht gemessenNicht gemessen
Einheitliche Messbedingungen: Heimanschluss während der abendlichen Hauptnutzungszeit in Peking. Senden Sie 100 ICMP-Anfragen an jedes Ziel, berechnen Sie den Median der Round-Trip-Zeit erfolgreicher Antworten und erfassen Sie zusätzlich den Paketverlust. Die Tabelle enthält noch keine Messwerte und ist kein abgeschlossener Messbericht. Spätere Ergebnisse dienen nur als Orientierung und sind keine Latenzgarantie.

Lokal messen, nicht auf dem Remote-Mac

Führen Sie den folgenden Befehl lokal unter macOS oder Linux aus. Unter Windows können Sie ping -n 100 mit der Ziel-IP verwenden. Notieren Sie Anbieter, Uhrzeit, Anzahl erfolgreicher Antworten und die vollständige Ausgabe. Vergleichen Sie die Standorte unter möglichst gleichen Bedingungen.

ping -c 100 "$MAC_IP"

Auch Schwankungen und Paketverlust beachten

Der von ping ausgegebene Durchschnitt ist nicht der Median. Berechnen Sie den Median anhand der einzelnen Antwortzeiten. Anhaltender Paketverlust oder gelegentliche hohe Latenz können VNC ruckelig machen, selbst wenn der Median niedrig ist. Werden ICMP-Pakete gefiltert, heißt das nicht automatisch, dass SSH oder VNC nicht funktioniert. Prüfen Sie in diesem Fall die tatsächlichen Verbindungsports.

Testen Sie den Desktop anschließend mit derselben Auflösung, Farbtiefe und denselben Arbeitsschritten: Geben Sie Text ein, ziehen Sie ein Fenster und prüfen Sie, ob die Aktualisierung flüssig bleibt.

Immer nur eine Einstellung ändern

Bandbreite für das nutzen, was Sie sehen möchten

Beginnen Sie mit ressourcenschonenden Einstellungen und erhöhen Sie die Bildqualität schrittweise. Wiederholen Sie nach jeder Änderung Eingaben, Scrollen und das Verschieben von Fenstern. Ändern Sie nicht alle vier Optionen gleichzeitig – sonst lässt sich kaum erkennen, was geholfen hat.

  1. 01

    Farbtiefe reduzieren

    Wählen Sie, sofern Ihr Client es zulässt, zunächst 16 Bit oder eine niedrigere Qualitätsstufe. So werden bei jeder Aktualisierung weniger Daten übertragen. Erhöhen Sie die Qualität wieder, wenn Sie Designs, Farben oder Screenshots prüfen. Eine niedrige Farbtiefe eignet sich nicht zur Farbkontrolle.

  2. 02

    Animierten Hintergrund deaktivieren

    Verwenden Sie ein statisches Hintergrundbild und schließen Sie unnötige Videos sowie laufende Animationen. Wird auch der Hintergrund ständig aktualisiert, verbraucht er Bandbreite für Bildinhalte, die mit Ihrer aktuellen Aufgabe nichts zu tun haben. Lassen Sie beim Prüfen von Simulatoranimationen nur die benötigten Fenster geöffnet.

  3. 03

    Auflösung begrenzen

    Beginnen Sie mit 1440 × 900 und erhöhen Sie die Auflösung erst, wenn Editor und Testfenster gut lesbar sind. Übernehmen Sie nicht einfach die hohe Auflösung Ihres lokalen Bildschirms für den Remote-Desktop. Mehr Pixel erhöhen den Übertragungs- und Dekodierungsaufwand.

  4. 04

    Bei schwacher Verbindung die CLI nutzen

    Führen Sie Builds, die Installation von Abhängigkeiten und die Protokollprüfung per SSH aus. Öffnen Sie VNC nur, wenn Sie die grafische Oberfläche tatsächlich benötigen. Übertragen Sie Artefakte und Protokolle getrennt, damit große Dateien und Desktop-Aktualisierungen nicht gleichzeitig die Upload-Bandbreite beanspruchen.

Nach dem Verbinden Zugriffsrechte einschränken

Erst einen Rückweg sichern, dann die Anmeldung ändern

Bei einem exklusiven physischen Mac verwalten Sie die Umgebung selbst. Das bedeutet nicht, dass eine Verbindung über das öffentliche Internet automatisch sicher ist. Bevor Sie Authentifizierung oder Firewall ändern, lassen Sie eine funktionierende Sitzung geöffnet und prüfen die neuen Einstellungen in einer zweiten Sitzung.

Initialpasswort ändern

Ersetzen Sie das Initialpasswort nach der Bereitstellung so bald wie möglich durch ein ausreichend langes, individuelles Passwort. Verwenden Sie nicht das Passwort für Ihr Code-Repository oder E-Mail-Konto erneut. Speichern Sie Zugangsdaten nur in einem geschützten Passwortmanager, nicht in Build-Protokollen oder Repositories.

Prüfen: Öffnen Sie eine neue Sitzung mit den neuen Zugangsdaten. Schließen Sie die alte erst, wenn die Anmeldung funktioniert.

SSH-Anmeldung nur mit Schlüssel

Hinterlegen Sie zunächst den öffentlichen Schlüssel und prüfen Sie die Anmeldung mit dem privaten Schlüssel. Passen Sie erst danach die SSH-Authentifizierung an. Verwenden Sie für Automatisierungen separate Schlüssel und vergeben Sie Rechte pro Aufgabe. Widerrufen Sie den jeweiligen öffentlichen Schlüssel, wenn jemand das Team verlässt oder ein Schlüssel kompromittiert wurde.

Prüfen: Eine zweite Terminalsitzung kann sich mit dem vorgesehenen privaten Schlüssel anmelden, ohne die alte Sitzung zu verwenden.

Nur benötigte Ports öffnen

Beschränken Sie offene Zugänge auf das, was Ihre Aufgaben erfordern, und begrenzen Sie nach Möglichkeit die zulässigen Quell-IP-Adressen. Nutzen Sie für den Remote-Desktop bevorzugt eine geschützte Verbindung. Prüfen Sie SSH- und VNC-Regeln getrennt und deaktivieren Sie zum Beheben von Problemen nicht dauerhaft den gesamten Schutz.

Prüfen: Benötigte Ports sind erreichbar, unnötige Zugänge bleiben geschlossen.

Desktop beim Verlassen sperren

Sperren Sie den Bildschirm und trennen Sie den Client, wenn Sie mit dem Debuggen fertig sind. Entfernen Sie vorübergehend heruntergeladene vertrauliche Dateien. Teilen Sie im Team keine privaten Schlüssel. Verwalten Sie die für Builds erforderlichen Schlüssel und Zertifikate nach den etablierten Teamprozessen.

Prüfen: Beim erneuten Zugriff auf den Desktop ist eine Anmeldung erforderlich. Protokolle und Screenshots enthalten keine Geheimnisse.

Verbindung Schritt für Schritt prüfen

Bei Verbindungsproblemen nicht gleich das System neu installieren

Unterscheiden Sie zuerst zwischen Zeitüberschreitung, abgelehnter Verbindung und fehlgeschlagener Authentifizierung. Prüfen Sie immer nur eine Ebene und bewahren Sie die vollständige Fehlermeldung auf. Wenn Sie Passwort, Port und Firewall wiederholt gleichzeitig ändern, gehen wichtige Hinweise verloren.

  1. 01

    IP-Adresse und Instanz prüfen

    Öffnen Sie die Maschinendetails im Portal erneut und prüfen Sie, ob die Instanz bereitgestellt wurde und die Zieladresse zu dieser Maschine gehört. Verwenden Sie keine alten Notizen, Screenshots oder die Adresse einer anderen Maschine. Tragen Sie auch nicht einfach die Variablennamen aus einem Beispiel im Client ein.

  2. 02

    Protokoll und Port prüfen

    Verwenden Sie im SSH-Client den SSH-Port und im VNC-Client den Desktop-Port. Bei einer Zeitüberschreitung prüfen Sie zuerst Netzwerk und Regeln; bei einer abgelehnten Verbindung zuerst Port und Dienststatus. Eine erreichbare IP-Adresse bedeutet nicht, dass auch der Anwendungsport erreichbar ist.

  3. 03

    Benutzernamen und Zugangsdaten prüfen

    Prüfen Sie bei einem Authentifizierungsfehler den Benutzernamen, die Schlüsseldatei und die im Client gewählte Authentifizierungsmethode. Achten Sie auf versehentlich kopierte Leerzeichen und verwenden Sie die Zugangsdaten der aktuellen Instanz. Prüfen Sie bei einem ungewöhnlichen Host-Fingerabdruck zuerst die Identität, statt die Warnung zu umgehen.

  4. 04

    Lokale Netzwerkregeln prüfen

    Prüfen Sie die lokale Firewall, den Proxy, den Unternehmensnetzwerkzugang und die Berechtigungen des Clients. Wenn möglich, testen Sie die Verbindung über ein anderes autorisiertes Netzwerk und prüfen Sie, ob sich das Problem mit der Verbindung ändert. Deaktivieren Sie Sicherheitssoftware nicht dauerhaft, nur um einmal eine Verbindung herzustellen.

Immer noch keine Verbindung? Erstellen Sie ein nachvollziehbares Ticket

Geben Sie die Instanz-ID, das Verbindungsprotokoll, den Zielport, den vollständigen Fehlertext, Datum und Uhrzeit samt Zeitzone sowie die bereits durchgeführten Schritte an. „SSH funktioniert, aber VNC nicht“ ist hilfreicher als „Verbindung geht nicht“. Entfernen Sie vor dem Anhängen von Screenshots oder Protokollen Passwörter, private Schlüssel, Token und andere vertrauliche Daten.

Bei Problemen mit einer bereits gemieteten Maschine erstellen Sie das Ticket im Portal, damit es der richtigen Instanz zugeordnet werden kann. Fragen zu Leitungswegen vor dem Kauf oder zur Client-Kompatibilität richten Sie per E-Mail an support@metalvnc.com.

Im Portal Ticket erstellen Weitere Hilfe
Zugriffsweg geklärt

Wählen Sie den nächstgelegenen Standort

Vergleichen Sie die beiden M4-Modelle anhand von Arbeitsspeicher und Speicherplatz und wählen Sie anschließend Standort und Abrechnungszeitraum. Prüfen Sie SSH und Desktop zunächst mit Ihrer tatsächlichen Netzwerkverbindung, bevor Sie dauerhafte Build-Aufgaben einrichten. Die Verfügbarkeit sehen Sie aktuell im Portal.

Cloud-Mac mieten Modelle und Laufzeiten