SSH-Verbindungen

External SSH verbindet Opfield mit einem benannten entfernten Host über Zugangsdaten, die ein Administrator konfiguriert hat. Es ist weder ein Connector für Git-Repositories noch ein verwalteter Bastion-Node noch ein Ersatz für die Registrierung von Daemons. Verwenden Sie Git-Hosting für den Repository-Zugriff und Nodes für dauerhafte, von Daemons verwaltete Operationen.

Eine Verbindung konfigurieren

1. Öffnen Sie den Abschnitt External SSH unter Settings > Integrations.
2. Geben Sie Anzeigenamen, Host, Port und entfernten Benutzernamen ein. Verwenden Sie ein Konto, das nur die Betriebssystemrechte hat, die für die vorgesehene Operation nötig sind.
3. Wählen Sie Passwort-Authentifizierung oder einen von Opfield generierten SSH-Schlüssel. Neue Verbindungen akzeptieren keine Importe beliebiger privater Schlüssel. Installieren Sie den generierten öffentlichen Schlüssel für das entfernte Konto; wo angeboten, kann ein vorhandener geeigneter Schlüssel wiederverwendet werden.
4. Wählen Sie bei Bedarf eine bestehende Jump-Verbindung und prüfen Sie den Zugriff über diesen Weg.
5. Ermitteln Sie den Fingerabdruck des Host-Schlüssels und prüfen Sie ihn über einen unabhängigen vertrauenswürdigen Kanal, bevor Sie ihn akzeptieren.
6. Speichern Sie die Verbindung und testen Sie die Authentifizierung. Ändert sich der Host-Schlüssel, untersuchen Sie die Änderung, statt die Prüfung zu umgehen.

Zugangsdaten werden verschlüsselt gespeichert. Ein SSH-Benutzername namens root und die Rolle des Systemadministrators in Opfield gehören zu verschiedenen Autorisierungssystemen: Entfernte Berechtigungen folgen nicht der Rolle des Opfield-Benutzers.

Das entfernte Konto und den öffentlichen Schlüssel vorbereiten

SSH hat keine API-Scopes eines Anbieters. Seine Berechtigungsgrenze ist das entfernte Unix-Konto, dessen Dateiberechtigungen und jede ausdrücklich konfigurierte Rechteausweitung.

1. Stellen Sie sicher, dass das Opfield-Backend den SSH-Host und -Port (normalerweise 22) direkt oder über die konfigurierte Jump-Verbindung erreichen kann.
2. Generieren Sie in Opfield einen Schlüssel und kopieren Sie den öffentlichen Schlüssel. Generieren Sie lokal keinen zweiten, unabhängigen Schlüssel und fügen Sie keinen privaten Schlüssel in authorized_keys ein.
3. Melden Sie sich in einer vertrauenswürdigen Konsole als das vorgesehene entfernte Konto an. Bereiten Sie dessen SSH-Verzeichnis vor:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

4. Öffnen Sie ~/.ssh/authorized_keys in einem Editor und hängen Sie den öffentlichen Schlüssel als eine Zeile an, wobei bestehende Schlüssel erhalten bleiben. Stellen Sie sicher, dass Verzeichnis und Datei diesem Konto gehören. Wenn Sie als Administrator bearbeiten, verwenden Sie das Home-Verzeichnis des Zielkontos, nicht das des Administrators.
5. Prüfen Sie den Host-Schlüssel des Servers über die Konsole des Anbieters oder einen anderen unabhängig vertrauenswürdigen Kanal. Für einen Ed25519-Host-Schlüssel:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

6. Vergleichen Sie diesen SHA-256-Fingerabdruck mit dem gleichen Host-Schlüssel-Algorithmus, den Opfield anbietet. Ein Wert, der nur über die nicht vertrauenswürdige Verbindung ermittelt wurde, ist keine unabhängige Prüfung. Speichern Sie den geprüften Fingerabdruck und testen Sie die Authentifizierung.

Vorgesehene Verwendung	Anforderung an das entfernte Konto
Anmelden	Gültiges Passwort oder installierter öffentlicher Schlüssel; SSH-Anmeldung durch die Serverrichtlinie erlaubt
Dateien lesen/gewöhnliche Befehle ausführen	Datei- und Ausführungszugriff für dieses Konto
Einen Daemon installieren oder reparieren	Die administrativen Rechte des Installationsablaufs; eine gewöhnliche Anmeldung allein reicht nicht
Einen Jump-Host verwenden	Anmeldung am Jump-Host plus ein erlaubter Weiterleitungspfad zum Ziel; die Authentifizierung am Ziel bleibt getrennt

Vergeben Sie kein uneingeschränktes sudo ohne Passwort, nur um einen SSH-Verbindungstest zu bestehen. Ein Passwort ist das Passwort des entfernten Kontos, kein Anmeldepasswort für Opfield. Deaktivieren Sie bei der Schlüssel-Authentifizierung während des Tests des neuen Schlüssels weder die Host-Prüfung noch den bestehenden Zugriff.

Referenz: OpenSSH authorized_keys und Server-Authentifizierung.

Zugriff und Hosting-Installation

integrations:ssh:view, integrations:ssh:manage und integrations:ssh:use trennen Sichtbarkeit, Verwaltung und Verwendung. In 2.11 können diese Scopes auch an API-Tokens und OAuth-Freigaben delegiert werden, und Opfield MCP stellt Agenten, die sie besitzen, einen Werkzeugsatz für External SSH bereit. Die OAuth-Zustimmung lässt integrations:ssh:use standardmäßig unmarkiert, sodass das Ausführen von Befehlen über einen Agenten ausdrücklich ausgewählt werden muss. Siehe API und MCP.

Bei einer unterstützten Hosting-Installation prüft Opfield, dass das SSH-Ziel eine tatsächlich zugewiesene Adresse der ausgewählten VM ist. Eine funktionierende Verbindung zu einem anderen Host ist kein Installationskanal für diese VM. Das Hosting kann stattdessen einen unterstützten Guest-Agent-Kanal verwenden; fügen Sie SSH nicht nur deshalb hinzu, weil ein Anbieterkonto existiert.

Verbindungsfehler diagnostizieren

Trennen Sie DNS- oder TCP-Erreichbarkeit, Zugriff auf den Jump-Host, abweichenden Fingerabdruck, abgelehnte Authentifizierung und die Berechtigung, den vorgesehenen Befehl auszuführen. Eine erfolgreiche Erkennung des Host-Schlüssels ist keine erfolgreiche Authentifizierung. Eine erfolgreiche Anmeldung beweist weder sudo- noch Installationsrechte. Prüfen Sie den konkreten Fehler und korrigieren Sie die passende Ebene, ohne Passwörter oder private Schlüssel offenzulegen.