Pfad zur Remote-Sitzung

Vom Zugangsdaten-Setup zur stabilen Cloud-Mac-Verbindung

Prüfen Sie zuerst im Dashboard den Knoten und die erlaubte Zugriffsquelle. Bereiten Sie anschließend Benutzername und Schlüssel vor und wählen Sie je nach Aufgabe SSH, Desktop oder eine automatisierte Sitzung. Jede NowMini-Bestellung umfasst einen exklusiven physischen M4-Rechner, keine virtuelle Maschine.

Verbindungsphase
3 Schrittebis zur ersten Sitzung
Knotenumfang
4asiatische Knoten zur Auswahl
Betriebszeit
365 TageBetriebsbereit
Vor der Verbindung prüfen

Erst Umgebungsunterschiede ausschließen, dann den Client öffnen

Alle sechs Informationen müssen aus derselben Bestellung und vom selben Knoten stammen. Verwenden Sie keine alte Knotenadresse, den Benutzernamen eines anderen Teammitglieds oder einen früheren Schlüssel.

A1

Bestellung und Knotenstatus

Prüfen Sie im Dashboard, ob die Bestellung zur Nutzung bereit ist, und gleichen Sie die aktuelle Knoten-ID ab. Maßgeblich ist der Echtzeitstatus im Dashboard.

Abnahme: Bestell- und Knoten-ID stimmen überein
A2

Knotenregion

Die Auswahl umfasst Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong. Prüfen Sie, ob die Verbindungsdaten zur gewählten Region gehören, und verwenden Sie nicht die Adresse eines anderen Knotens.

Abnahme: Region und Bestelldaten stimmen überein
A3

Benutzername und Zugangsdaten

Benutzername, Schlüsseldatei und Gültigkeitsbereich der Zugangsdaten Zeichen für Zeichen prüfen. Private Schlüssel nur auf kontrollierten Geräten speichern, nicht per Chat oder im Repository übertragen.

Abnahme: Zugangsdaten gehören zum aktuellen Nutzer
A4

Zugriffsquelle

Prüfen Sie, ob der aktuelle öffentliche Ausgang oder das Team-Gateway den Quellenbeschränkungen des Knotens entspricht. Nach einem Netzwerkwechsel die Ausgangsadresse erneut prüfen.

Abnahme: Aktuelle Quelle ist zugelassen
A5

Lokales Netzwerk

Zuerst Proxy, Unternehmensfirewall, öffentliches WLAN und instabile Routen als Ursachen ausschließen. Bei Bedarf über ein zweites vertrauenswürdiges Netzwerk gegenprüfen.

Abnahme: Zielport akzeptiert Verbindungen
A6

Clientversion

Name und Version des SSH- oder Grafikclients sowie die Version des lokalen Systems dokumentieren. Im Team einheitliche Verbindungsparameter verwenden, um Clientunterschiede zu reduzieren.

Abnahme: Versionen und Parameter dokumentiert
Shell-Sitzung

Mit SSH die erste überprüfbare Verbindung herstellen

Hostadresse, Benutzername und Schlüsseldatei im Befehl sind Platzhalter. Vor der Ausführung die aktuellen Knotendaten aus dem Dashboard kopieren und die Beispielzeichen nicht unverändert übernehmen.

SCHRITT 01

Lokale Schlüsselberechtigungen einschränken

Zuerst prüfen, dass die Datei dem aktuellen lokalen Benutzer gehört, und anschließend den Lesezugriff anderer Konten beschränken. Der Schlüsseldateiname sollte Umgebungen unterscheiden, darf aber keine echten Passwörter oder Token enthalten.

SCHRITT 02

SSH-Sitzung starten

Schlüssel, Benutzername und Hostadresse explizit angeben. Bei der ersten Fehlersuche die Clientausgabe aufbewahren und Fehler nicht durch zahlreiche versteckte Parameter verschleiern.

SCHRITT 03

Ersten Host-Fingerabdruck prüfen

Den beim ersten Verbindungsaufbau angezeigten Fingerabdruck mit den Angaben im Dashboard abgleichen. Wenn sich der Fingerabdruck einer bereits verwendeten Adresse geändert hat, Verbindung stoppen und den Knoteneintrag prüfen.

SCHRITT 04

Sitzung abnehmen

Nach der Anmeldung Hostname, aktuellen Benutzer, Arbeitsverzeichnis und verfügbaren Speicher prüfen. In einer noch nicht verifizierten Sitzung keinen Code, keine Zertifikate und keine Modelldateien importieren.

SSH-Verbindungsprotokoll PLACEHOLDER VALUES
Schlüsselberechtigungen einschränken
chmod 600 ~/.ssh/<KEY_FILE>
Verbindung herstellen
ssh -i ~/.ssh/<KEY_FILE> <USERNAME>@<HOST_ADDRESS>
Ausführliche Diagnose ausgeben
ssh -vv -i ~/.ssh/<KEY_FILE> <USERNAME>@<HOST_ADDRESS>
Identität in der Sitzung prüfen
hostname
whoami
pwd
df -h
Grundsatz für die erste Verbindung Erst Fingerabdruck prüfen, dann Eintrag akzeptieren
Grafischer Desktop

Bild, Eingabe und Wiederverbindung getrennt prüfen

Grafische Sitzungen eignen sich für Xcode, Logic Pro und Aufgaben mit Fenstern. Eine erfolgreiche Verbindung garantiert noch keine stabile Nutzung: Auflösung, Tastatur und Zwischenablage müssen separat abgenommen werden.

  1. 01

    Sitzung starten

    Die aktuellen grafischen Verbindungsdaten aus dem Dashboard abrufen und Hostadresse, Benutzername sowie Zugriffsquelle prüfen. Bei der ersten Sitzung die Standardqualität beibehalten und den stabilen Einstieg in die grafische macOS-Oberfläche bestätigen.

    Ergebnis: Desktop sichtbar und Eingabe möglich
  2. 02

    Auflösung anpassen

    Schrittweise an lokalen Bildschirm und Verbindungsqualität anpassen. Eine hohe Auflösung erhöht Bandbreiten- und Codierlast. Bei anhaltendem Ruckeln zuerst die Bildgröße reduzieren und erst danach ein Knotenproblem prüfen.

    Ergebnis: Text klar und Bedienung flüssig
  3. 03

    Tastaturbelegung kalibrieren

    Umschaltung zwischen Deutsch und Englisch sowie Command, Option, Control, Funktionstasten und gängige Tastenkürzel prüfen. Lokale Systeme können Tasten unterschiedlich abbilden; die einheitliche Teambelegung dokumentieren.

    Ergebnis: Tastenkürzel funktionieren wie erwartet
  4. 04

    Zwischenablage prüfen

    Zunächst kurzen Text ohne sensible Informationen für ein- und zweiseitiges Kopieren verwenden. Private Schlüssel, vollständige Token oder unbereinigte Produktionsdaten niemals über die Zwischenablage übertragen.

    Ergebnis: Freigegebener Text kontrolliert übertragbar
  5. 05

    Verbindungsabbruch und Wiederverbindung behandeln

    Zuerst prüfen, ob das lokale Netzwerk gewechselt hat, danach Zugriffsquelle, Clientlogs und Knotenstatus kontrollieren. Vor der Wiederverbindung nicht mehrere identische Sitzungen nacheinander erstellen, damit Desktopreaktionen nicht falsch bewertet werden.

    Ergebnis: Zum ursprünglichen Arbeitskontext zurückgekehrt
Datei- und Codesynchronisierung

Übertragungsweg nach Inhalt auswählen

Quellcode, temporäre Dateien und Build-Artefakte sollten nicht über denselben Synchronisierungsweg laufen. Quelle, Ziel und Aufbewahrungsdauer festlegen und danach Git, sicheren Dateitransfer oder Artefaktrückgabe wählen.

Einsatz, Grenzen und Abnahme der drei Synchronisierungswege
Weg Geeignete Inhalte Vorgehen Sicherheitsgrenze Abnahmeergebnis
Git-Pull Versionskontrollierter Quellcode, Skripte und Konfigurationsvorlagen In einem separaten Arbeitsverzeichnis klonen oder pullen, Branch und Commit festlegen und Lockdateien für Abhängigkeiten dokumentieren Keine privaten Schlüssel, Token, Signaturmaterialien oder lokalen Zugangsdaten im Repository speichern Commit-Hash entspricht der Pipeline-Erwartung
Sicherer Dateitransfer Modelldateien, Assets, temporäre Daten und nicht für das Repository geeignete Eingaben Mit kontrolliertem Konto und eindeutigem Zielverzeichnis übertragen; anschließend Anzahl, Größe und Prüfsummen der Dateien prüfen Nur erforderliche Verzeichnisse freigeben; Verantwortliche und Zeitpunkt für die Bereinigung temporärer Dateien festlegen Dateien vollständig und Berechtigungen zweckgemäß
Build-Artefakte zurückübertragen Archive, Logs, Testberichte, Symboldateien und auslieferbare Pakete Nach Abschluss der Aufgabe aus dem Ausgabeverzeichnis zurückübertragen und mit Aufgabennummer, Commit-Hash und Build-Nummer benennen Vor der Rückgabe prüfen, ob Artefakte Umgebungsvariablen, Zugangsdatenfragmente oder unbereinigte Logs enthalten Artefakt eindeutig einer Aufgabe zuordenbar

Struktur für sichere Kopierbefehle

Geeignet für einzelne Dateien oder kleine Verzeichnisse. Host, Benutzer, Schlüssel und Pfade sind Platzhalter.

scp -i ~/.ssh/<KEY_FILE> <LOCAL_FILE> <USERNAME>@<HOST_ADDRESS>:<REMOTE_PATH>

Struktur für inkrementelle Synchronisierung

Geeignet für wiederholbare Verzeichnisübertragungen. Vor Parametern zum Löschen den Änderungsumfang im Vorschau-Modus prüfen.

rsync -av --dry-run -e "ssh -i ~/.ssh/<KEY_FILE>" <LOCAL_PATH> <USERNAME>@<HOST_ADDRESS>:<REMOTE_PATH>
Automatisierte Anbindung

CI-Runner ausführbar und revisionssicher machen

Automatisierungskonten dürfen nicht mit interaktiven Alltagskonten geteilt werden. Identität, Schlüssel, Arbeitsverzeichnis, Cache und Logs getrennt verwalten, damit sich Ursache und Berechtigung eines Fehlers nachvollziehen lassen.

RUNNER-01

Eigenes Konto verwenden

Für den Runner ein dediziertes Systemkonto erstellen, das ausschließlich Automatisierungsaufgaben ausführt. Interaktive Entwicklung, grafische Sitzungen und Pipeline-Ausführung durch getrennte Identitäten abgrenzen.

  • Kontoname lässt sich einem eindeutigen Pipelinezweck zuordnen
  • Keine Authentifizierungsmaterialien mit persönlichen Konten teilen
  • Beim Deaktivieren des Runners Kontoberechtigungen gleichzeitig widerrufen
KEY-02

Schlüssel mit minimalen Berechtigungen konfigurieren

Schlüssel nur die für die Aufgabe erforderlichen Anmelde- und Verzeichnisrechte geben. Für unterschiedliche Repositories, Teams oder Umgebungen verschiedene Schlüssel verwenden, damit ein Leck begrenzt bleibt.

  • Schlüsselzweck und verantwortliche Person nachvollziehbar
  • Private Schlüssel weder im Repository noch in Buildlogs speichern
  • Nicht verwendete Schlüssel regelmäßig prüfen und widerrufen
PATH-03

Arbeitsverzeichnis festlegen

Quellcode, Cache, temporäre Dateien und Artefakte jeweils in feste Verzeichnisse schreiben. Vor Aufgabenbeginn veränderliche Zustände bereinigen und danach notwendige Aufzeichnungen behalten.

  • Jede Pipeline verwendet ein eindeutig festgelegtes Stammverzeichnis
  • Cache wiederverwendbar, überschreitet aber keine Berechtigungsgrenzen
  • Artefakt- und Quellverzeichnis getrennt
LOG-04

Auditierbare Logs aufbewahren

Aufgabennummer, Commit-Hash, Start- und Endzeit, Exit-Code und Artefaktpfad dokumentieren. Felder mit Zugangsdaten in Logs müssen bereinigt werden.

  • Fehlgeschlagene Aufgaben behalten vollständige Phasengrenzen
  • Client- und Runner-Versionen dokumentiert
  • Logs eindeutig Bestellung und Knoten zuordenbar
Verbindungsprobleme beheben

Vom lokalen Netzwerk bis zum Knoten die Fehlerstelle schichtweise eingrenzen

Nicht gleichzeitig Netzwerk, Adresse, Schlüssel und Clientparameter ändern. Jede Schicht einzeln prüfen und Ergebnisse dokumentieren, um lokale Probleme, Zugriffsbeschränkungen, Authentifizierungsfehler und Dienststatus zu unterscheiden.

  1. 1

    Lokales Netzwerk prüfen

    Sicherstellen, dass das Gerät normal auf das Netzwerk zugreifen kann; temporären Proxy deaktivieren, der Routen verändern könnte, und erneut versuchen. Mit einem zweiten vertrauenswürdigen Netzwerk gegenprüfen, ob das Problem am aktuellen Ausgang hängt.

    Nachweis: Netzwerk und Ausgangsadresse
  2. 2

    Zugriffsquelle prüfen

    Im Dashboard erlaubte Quelle mit dem aktuellen öffentlichen Ausgang abgleichen. Nach Wechsel zwischen Unternehmensnetz, mobilem Hotspot und Heimnetz kann sich die Ausgangsadresse ändern.

    Nachweis: Aufzeichnung der Quellenbeschränkung
  3. 3

    Berechtigungen der Zugangsdaten prüfen

    Sicherstellen, dass der Benutzername zum aktuellen Knoten gehört, der Pfad zum privaten Schlüssel stimmt und die lokalen Dateiberechtigungen ausreichend strikt sind. Bei Authentifizierungsfehlern nicht wahllos weitere Schlüssel versuchen.

    Nachweis: Ausgabe der Authentifizierungsphase
  4. 4

    Hostadresse prüfen

    Adresse erneut aus dem Dashboard kopieren und alte Einträge, Leerzeichen, fehlende Zeichen sowie eine Verwechslung von Knoten ausschließen. Bei Konfigurationsaliasen auch den tatsächlich aufgelösten Wert prüfen.

    Nachweis: Adresse des aktuellen Ziels
  5. 5

    Dienststatus prüfen

    Im Dashboard die Echtzeitantwort von Bestellung, Knoten und Verbindungsdienst prüfen. Den Knotenstatus nicht allein anhand eines allgemeinen lokalen Clientfehlers beurteilen.

    Nachweis: Aktuelles Ergebnis aus dem Dashboard
  6. 6

    Clientlogs lesen

    Dokumentieren, ob der Fehler beim Auflösen der Adresse, beim Aufbau der Netzwerkverbindung, bei der Protokollaushandlung, bei der Identitätsprüfung oder beim Einstieg in die Sitzung auftrat. Vor einer Supportanfrage Zugangsdaten und sensible Pfade entfernen.

    Nachweis: Bereinigte Clientlogs

Verbindung weiterhin nicht möglich

Über das Dashboard ein Ticket einreichen und Bestell-ID, Knotenregion, Zeitpunkt, Reproduktionsschritte, Clientversion und bereinigte Logs beifügen. Wenn noch keine Bestellung vorliegt, den gewünschten Workflow und die bevorzugte Region über die Kontaktseite beschreiben.

Sitzung sicher abschließen

Am Ende der Aufgabe Zugriffsrechte und temporäre Daten gemeinsam entfernen

Das Schließen des Fensters beendet nur einen Teil der Sitzung. Temporäre Zugangsdaten, Cache, übertragene Dateien und Berechtigungen von Teammitgliedern benötigen jeweils eine dokumentierte Behandlung.

Remote-Sitzung beenden

Laufende Befehle und grafische Anwendungen ordnungsgemäß beenden und anschließend SSH- oder grafische Sitzung schließen. Prüfen, dass keine interaktiven Prozesse Arbeitsverzeichnisse oder Ausgabedateien blockieren.

Abschluss: Sitzung eindeutig beendet

Temporäre Zugangsdaten widerrufen

Temporäre Schlüssel, Token und Kontofreigaben löschen, die nur für diese Aufgabe erstellt wurden. Nach dem Widerruf prüfen, dass alte Zugangsdaten keinen Zugriff mehr auf den Knoten ermöglichen.

Abschluss: Temporärer Zugriff deaktiviert

Cache-Dateien bereinigen

Wiederverwendbaren Build-Cache, temporäre Aufgabedateien und sensible Eingaben unterscheiden. Nur Inhalte mit definiertem Zweck und Aufbewahrungszeitraum behalten; alles andere gemäß Aufgabenliste löschen.

Abschluss: Verzeichnis entspricht den Aufbewahrungsregeln

Änderungen bei Teammitgliedern bearbeiten

Wenn ein Teammitglied das Projekt verlässt oder die Zuständigkeit wechselt, Zugriffsschlüssel rotieren, alte Kontoberechtigungen entfernen und prüfen, ob Runner, Skripte oder lokale Konfigurationen noch alte Zugangsdaten verwenden.

Abschluss: Mitglieder und Berechtigungen neu zugeordnet
Abschlussdokumentation

Ergebnisse behalten, Geheimnisse löschen

Aufgabennummer, Commit-Hash, Artefaktpfad, Exit-Code, Bearbeiter und Abschlusszeit dürfen dokumentiert werden. Passwörter, private Schlüssel, vollständige Token oder sensible Geschäftsdaten gehören nicht in die Abnahmedokumentation.

Knotendaten vorbereiten und Verbindung starten

Im Dashboard zuerst Bestellung, Region, Hostadresse und Zugangsdaten prüfen. Für einen neuen Knoten NowMini M4 bestellen: M4, 16 GB RAM, 256 GB SSD, exklusiver physischer Rechner, keine virtuelle Maschine.