SSH- und VNC-Fernzugriff

Verbindungsart wählen

Nach der Arbeitsweise wählen, nicht nach dem Toolnamen

Ein Cloud-Mac kann gleichzeitig Kommandozeilen- und Grafikaufgaben übernehmen. Bewährt hat sich: SSH für lange Aufgaben und Diagnosen, VNC für Vorgänge, bei denen der Desktop sichtbar sein muss.

Geringer Interaktionsaufwand

SSH: Builds, Automatisierung und Logs

Geeignet für xcodebuild, fastlane, die Installation von Abhängigkeiten, Repository-Synchronisierung, Log-Prüfung und Hintergrundskripte. Bei kurzen Netzwerkaussetzern können Sie mit einem Sitzungs-Tool laufende Aufgaben auf dem Remote-System fortsetzen.

Geeignet: Befehle, Skripte, kontinuierliche Builds
Vorteil: Geringe Bandbreitennutzung, vollständige Diagnoseinformationen
Grenze: Keine grafische macOS-Oberfläche

Vollständiger Desktop

VNC: Xcode, Videoschnitt und visuelle Bedienung

Geeignet für Xcode mit grafischer Oberfläche, Simulatoren, Medienverwaltung, Schnitt-Timelines und andere Aufgaben, bei denen der Desktop sichtbar sein muss. Bei hoher Latenz sollten Sie zuerst Bildqualität und Auflösung reduzieren, statt wiederholt die Verbindung aufzubauen.

Geeignet: Grafische Entwicklung, Videoschnitt, interaktive Prüfung
Vorteil: Vollständige Bedienung des Remote-macOS-Desktops
Grenze: Empfindlicher gegenüber Latenz, Schwankungen und Bandbreite

SSH-Konfiguration

Fünf Parameter prüfen, dann die erste Verbindung herstellen

Übernehmen Sie Adresse und Port nicht aus anderen Bestellungen. Maßgeblich sind immer die Verbindungsdaten, die für den aktuellen Dienst in der Konsole angezeigt werden.

01

Host und Port ablesen

Kopieren Sie Hostadresse und SSH-Port aus den Details des aktuellen Dienstes. Adresse, Port und Knoten bilden gemeinsam das Verbindungsziel; nach einem Wechsel des Knotens oder Dienstes müssen Sie sie erneut prüfen.

02

Remote-Benutzernamen bestätigen

Der Benutzername muss exakt den Verbindungsdaten entsprechen. Verwenden Sie nicht den lokalen Computernamen, ein Repository-Konto oder den Namen eines Teammitglieds im SSH-Befehl.

03

Schlüsselberechtigungen einschränken

Die private Schlüsseldatei darf nur vom aktuellen lokalen Benutzer gelesen werden. Unter macOS oder Linux können Sie chmod 600 ~/.ssh/lemonvm_keyausführen und anschließend mit -i die Datei angeben.

04

Ersten Fingerabdruck prüfen

Wenn beim ersten Verbinden ein Hostschlüssel-Fingerabdruck erscheint, vergleichen Sie ihn zuerst mit der Anzeige in der Konsole. Schreiben Sie ihn nur bei vollständiger Übereinstimmung in known_hostsund überspringen Sie die Prüfung nicht.

05

Wiederverwendbare Konfiguration speichern

Tragen Sie Host, HostName, User, Port und IdentityFile in die lokale SSH-Konfiguration ein, um Tippfehler zu vermeiden. Schreiben Sie jedoch niemals den Inhalt des privaten Schlüssels in die Konfigurationsdatei.

Befehlsformat

ssh -i ~/.ssh/lemonvm_key -p Port Benutzername@Hostadresse

VNC-Konfiguration

Zuerst eine nutzbare Sitzung herstellen, dann die Bildqualität schrittweise erhöhen

Starten Sie die erste Verbindung mit mittlerer Bildqualität und niedrigerer Auflösung. Sobald Eingabe, Zwischenablage und Fensterwechsel funktionieren, passen Sie die Anzeigeparameter an die verfügbare Leitungsbandbreite an.

01

Adresse eingeben

Verwenden Sie VNC-Host und -Port aus der Konsole, nicht den SSH-Port. Wenn der Client eine kombinierte Adresse verlangt, geben Sie Host und Port im Format des Clients ein.

02

Mit mittlerer Bildqualität beginnen

Sorgen Sie zuerst für eine reaktionsfähige Maus, Tastatur und Fensterbedienung. Erhöhen Sie Farb- und Bildqualität erst, wenn die Textdarstellung ausreicht, damit die Bandbreite beim ersten Verbinden nicht ausgelastet wird.

03

Auflösung steuern

Eine hohe Auflösung erhöht die Datenmenge pro Frame. Verwenden Sie bei schwacher Verbindung zunächst einen einzelnen Bildschirm und eine niedrigere Auflösung; passen Sie die Größe des Remote-Desktops erst nach Stabilisierung an.

04

Zwischenablage prüfen

Testen Sie nach dem Verbinden die bidirektionale Kopie zunächst mit einem Text ohne vertrauliche Informationen. Übertragen Sie private Schlüssel, vollständige Zugriffstoken oder langfristige Zugangsdaten nicht über die gemeinsame Zwischenablage.

05

Vollbild-Tastenkürzel bestätigen

Notieren Sie die Tastenkürzel des Clients zum Beenden des Vollbildmodus und zum Freigeben der Tastaturerfassung. So verhindern Sie, dass Tastenkombinationen der Remote-Sitzung vom lokalen System abgefangen und fälschlich als Sitzungsfehler bewertet werden.

06

SSH-Diagnosekanal beibehalten

Wenn das VNC-Bild stehen bleibt, prüfen Sie Auslastung und Netzwerk zunächst per SSH. Ist SSH weiterhin erreichbar, ist der physische Knoten in der Regel online; das Problem liegt wahrscheinlich in der grafischen Sitzung oder Verbindung.

Verbindungsdiagnose

Von Handshake und Leitung bis zum Remote-Build schrittweise prüfen

Ändern Sie bei der Diagnose immer nur eine Variable. Prüfen Sie zuerst den SSH-Handshake, beobachten Sie anschließend die Netzwerkmessung und führen Sie zuletzt einen überprüfbaren Remote-Befehl aus. So lassen sich Probleme mit Zugangsdaten, Port, Verbindung und Aufgabenumgebung unterscheiden.

Nach Connecting to keine Antwort: Adresse, Port und lokale Ausgangsbeschränkungen prüfen.

Schlüsselverhandlung beginnt, aber Authentifizierung schlägt fehl: Benutzernamen, Pfad des privaten Schlüssels und Dateiberechtigungen prüfen.

SSH funktioniert, VNC ruckelt: Bildqualität und Auflösung reduzieren und Hintergrundübertragungen pausieren.

Verbindung funktioniert, Build schlägt fehl: vollständiges Build-Log lesen und den Aufgabenfehler nicht dem Netzwerk zuschreiben.

remote-diagnostic.log

$ ssh -v -p Port Benutzername@Hostadresse
debug1: Connecting to host [Adresse] port [Port]
debug1: Server host key: SHA256:[Fingerabdruck]
debug1: Authentication succeeded (publickey)

$ ping -c 5 Hostadresse
5 packets transmitted, 5 packets received
round-trip min/avg/max = 41.2/44.8/49.1 ms

$ ssh lemon-node "xcodebuild -version"
Xcode [aktuelle Version]
Build version [aktuelle Buildnummer]

$ ssh lemon-node "cd ~/project && xcodebuild build"
** BUILD SUCCEEDED **

Gemessene Knotenlatenz

Fünf Knoten nach einheitlichen Kriterien vergleichen

Die Tabelle zeigt die relativen Unterschiede von verschiedenen Zugangsstandorten zu Singapur, Tokio, Seoul, Hongkong und dem Westen der USA. Für interaktives VNC sind Latenz und Schwankungen entscheidend, für Hintergrund-Builds dagegen Verbindungsstabilität und anhaltender Durchsatz.

MesszeitraumWerktags 20:00–22:00 Uhr, Ortszeit

Anzahl der Messungen30 ICMP-Messungen pro Gruppe

AuswertungMedian nach Ausschluss des ersten Pakets

ZugangsleitungLokales Festnetz oder Unternehmensfaser

Medianer Ping in Millisekunden von wichtigen Zugangsstandorten zu den fünf verfügbaren LemonVM-Knoten
Zugangsstandort und Anbieter	Singapur	Tokio	Seoul	Hongkong	Westen der USA
Shanghai · China Telecom	68 ms	42 ms	51 ms	35 ms	146 ms
Peking · China Unicom	91 ms	54 ms	46 ms	58 ms	139 ms
Shenzhen · China Mobile	53 ms	67 ms	76 ms	24 ms	168 ms
Taipeh · Festnetz	62 ms	39 ms	48 ms	31 ms	126 ms
Los Angeles · Unternehmensfaser	171 ms	112 ms	124 ms	143 ms	27 ms

So lesen Sie die Werte: Vergleichen Sie am selben Zugangsstandort zuerst die Zahlen in einer Zeile. Bei VNC sollten Sie zusätzlich Schwankungen und Paketverlust kontinuierlich beobachten. Die tatsächliche Verbindungsqualität hängt gemeinsam von lokalem WLAN, Provider-Ausgang, internationalem Routing und Hintergrundübertragungen ab.

Fehleranalyse bei hoher Latenz

Vom lokalen Netzwerk zum Remote-System eingrenzen

Wechseln Sie nicht gleichzeitig den Knoten, ändern Sie die Bildqualität und starten Sie den Client neu. Prüfen Sie die folgenden sechs Schritte einzeln und protokollieren Sie jeweils Latenz, Paketverlust oder Bedienreaktion vor und nach der Änderung.

01

Lokales Netzwerk prüfen

Wechseln Sie zu einer kabelgebundenen Verbindung oder stabilem 5-GHz-WLAN und pausieren Sie lokale Downloads und Cloud-Synchronisierung. Wenn auch andere Geräte im selben LAN Schwankungen zeigen, beheben Sie zuerst die lokale Verbindung.

02

Internationale Verbindung beobachten

Messen Sie mindestens mehrere Minuten kontinuierlich, um dauerhaft hohe Latenz von sporadischem Paketverlust zu unterscheiden. Kurzzeitige Spitzen verursachen eher springende VNC-Mauszeiger und Bildaussetzer.

03

Ausgewählten Knoten vergleichen

Wählen Sie zwischen Singapur, Tokio, Seoul, Hongkong und dem Westen der USA den Knoten, der der wichtigsten Zugriffsrichtung am nächsten liegt. Teams sollten sich nach der Richtung der Hauptnutzer oder Build-Abhängigkeiten richten.

04

VNC-Bildqualität reduzieren

Reduzieren Sie zunächst Farbqualität, Komprimierungsstufe oder Bildrate und prüfen Sie, ob die Eingabereaktion besser wird. Wenn das Bild klar, die Bedienung aber verzögert ist, erhöhen Sie nicht einfach nur die Bandbreiteneinstellung.

05

Auflösung reduzieren

Wechseln Sie vorübergehend zu einem einzelnen Bildschirm und niedrigerer Auflösung. Verbessert sich die Reaktion deutlich, überschreitet die Datenmenge pro Frame wahrscheinlich den für die aktuelle Leitung geeigneten Bereich.

06

Hintergrundübertragungen pausieren

Prüfen Sie Repository-Abrufe, Abhängigkeitsdownloads, Medien-Uploads, Artefaktübertragungen und Remote-Synchronisierungen. Große Dateien sollten nicht gleichzeitig mit interaktiver VNC-Bedienung übertragen werden.

Sitzungssicherheit

Verbindungsdaten nur an berechtigte Personen weitergeben

Die Sicherheitsgrenzen des Fernzugriffs werden durch lokale Schlüssel, Anfangszugangsdaten, Sitzungssperren und die Übergabe im Team bestimmt. Fügen Sie langfristige Zugangsdaten nicht in öffentliche Chats oder Repositorys ein.

Schlüssel bevorzugen

Verwenden Sie für jedes Gerät einen eigenen Schlüssel und speichern Sie private Schlüssel nur auf kontrollierten Endgeräten. Entfernen Sie den zugehörigen öffentlichen Schlüssel umgehend, wenn ein Gerät aus dem Team ausscheidet oder verloren geht.

Anfangszugangsdaten aktualisieren

Aktualisieren Sie temporäre Zugangsdaten nach der ersten Anmeldung und Umgebungsprüfung. Hinterlassen Sie keine direkt nutzbaren Zugangsdaten in Skripten, Build-Logs oder Repository-Konfigurationen.

Sitzung vor dem Weggehen sperren

Sperren Sie den Remote-Desktop bei vorübergehender Abwesenheit, ohne noch laufende Hintergrundaufgaben zu beenden. In gemeinsam genutzten Arbeitsbereichen sollte zusätzlich der lokale Computer gesperrt werden.

Zugriff nach Mitgliedern vergeben

Dokumentieren Sie bei der Zusammenarbeit, wer welche Aufgabe zu welcher Zeit ausführt, und verwenden Sie keinen gemeinsamen dauerhaften Schlüssel. Halten Sie bei der Übergabe Aufgabenstatus, Log-Speicherort und nächste Schritte fest.

Wiederherstellung nach Verbindungsabbruch

Zuerst prüfen, ob die Aufgabe noch läuft, dann neu verbinden

Ein verschwundenes VNC-Bild bedeutet nicht, dass der physische Knoten angehalten wurde. Bestätigen Sie den Status zunächst über einen anderen Verbindungskanal, um Builds nicht doppelt zu starten, Ausgaben zu überschreiben oder laufende Aufgaben zu unterbrechen.

Netzwerkunterbrechung

SSH und VNC gleichzeitig getrennt

Prüfen Sie zuerst das lokale Netzwerk und testen Sie anschließend Zielhost und Port. Verbinden Sie sich nach der Wiederherstellung erneut und prüfen Sie Aufgaben-Logs und Prozessstatus, statt den ursprünglichen Befehl direkt zu wiederholen.

Prüfpunkte: lokaler Ausgang, Zielport, Zeitpunkt des letzten Logs

Systemruhemodus

Verbindung hergestellt, aber Remote-System reagiert nicht

Prüfen Sie den aktuellen Dienststatus in der Konsole und testen Sie die Systemreaktion anschließend per SSH. Kontrollieren Sie nach der Wiederherstellung Energie- und Sitzungseinstellungen, damit lange Aufgaben nicht in einen ungeeigneten Ruhemodus wechseln.

Prüfpunkte: SSH-Reaktion, Systemzeit, laufende Prozesse

Grafische Sitzung

SSH funktioniert, aber VNC-Bild ist fehlerhaft

Reduzieren Sie die Anzeigeparameter und bauen Sie die grafische Sitzung neu auf. Starten Sie den gesamten Knoten nicht neu, bevor der Aufgabenstatus bestätigt ist; ein Hintergrund-Build kann weiterhin normal laufen.

Prüfpunkte: Remote-Auslastung, grafische Sitzung, Client-Einstellungen

Hintergrundaufgabe

Build läuft nach Verbindungsabbruch weiter

Lesen Sie nach dem erneuten Verbinden Logs, Exit-Code und Artefaktverzeichnis. Starten Sie erst dann einen weiteren Build, wenn die ursprüngliche Aufgabe beendet oder fehlgeschlagen ist, um parallele Schreibvorgänge am selben Ausgabeort zu vermeiden.

Prüfpunkte: Prozess-ID, Exit-Code, Änderungszeit der Artefakte

Weitere Einstiege

Von der ersten Verbindung bis zur laufenden Verwaltung

Wenn Bestellung und Umgebungsprüfung noch ausstehen, starten Sie mit dem Schnellstart. Bei einem konkreten Fehler suchen Sie im Hilfezentrum anhand der Fehlermeldung weiter.