Fernzugriffsverwaltung

Die „Fernzugriffsverwaltung“ verwaltet SSH-Zugangsdaten und Fernverbindungen zentral. Die bisherige „Fernverbindungsverwaltung“ auf Flottenebene wurde umbenannt; auch auf Geräteebene steht ein entsprechender Zugang zur Verfügung.

Seitenzugänge und Berechtigungen

Seite	Inhalt
Flotte → Fernzugriffsverwaltung → Verbindungsverwaltung	Aktive Verbindungen anzeigen und entsprechend den Berechtigungen trennen
Flotte → Fernzugriffsverwaltung → Schlüsselverwaltung	Gemeinsam in der Flotte verwendete SSH-Zugangsdaten speichern
Gerät → Fernzugriffsverwaltung	Gerätespezifische SSH-Zugangsdaten speichern, geerbte Einträge anzeigen und Hostidentität bestätigen; ausschließlich Schlüsselverwaltung
Geräteübersicht → Remote-Desktop	Gespeicherte Zugangsdaten auswählen oder eine Verbindung mit Passwort starten; keine Uploadfunktion

Master und Admin verwalten Zugangsdaten und Hostidentitäten. Zugangsdaten sind standardmäßig auf „Nur Administratoren“ beschränkt. Administratoren können ihre Verwendung ausdrücklich für „Mitglieder mit Fernverbindungsberechtigung“ freigeben, einschließlich Developer. Observer dürfen ausschließlich Metadaten anzeigen und weder Verbindungen herstellen noch Änderungen vornehmen.

Nutzungs- und Verwaltungsberechtigungen für Zugangsdaten sind getrennt. Die Nutzungsberechtigung erlaubt nicht, private Schlüssel anzuzeigen oder herunterzuladen. Keine Rolle verfügt über eine Funktion zum Anzeigen oder Exportieren privater Schlüssel. Bei Verbindungsvorgängen wird der tatsächlich handelnde Benutzer protokolliert.

Ersteinrichtung

1. Der Geräteadministrator konfiguriert selbst den öffentlichen Benutzerschlüssel für das Zielsystemkonto oder den öffentlichen Schlüssel der ausstellenden CA und die zulässigen Principals.
2. Klicken Sie in der Schlüsselverwaltung der Flotte oder des Geräts auf „SSH-Zugangsdaten hinzufügen“ und geben Sie Name, Systemkonto des Geräts und Authentifizierungsverfahren an.
3. Laden Sie den privaten Benutzerschlüssel hoch. Für Zertifikatsauthentifizierung laden Sie zusätzlich das extern ausgestellte Benutzerzertifikat hoch; für verschlüsselte private Schlüssel geben Sie außerdem die Passphrase an. Laden Sie niemals den privaten CA-Schlüssel hoch.
4. Wählen Sie die zur Nutzung berechtigten Mitglieder aus, legen Sie den Eintrag bei Bedarf als Standard fest und speichern Sie ihn.
5. Erfassen Sie den öffentlichen Hostschlüssel auf der Geräteseite und bestätigen Sie ihn nach einem vertrauenswürdigen Fingerabdruckabgleich.
6. Der verbindende Benutzer wählt unter „Remote-Desktop“ Konto, Authentifizierungsverfahren und gespeicherte Zugangsdaten aus und prüft die Verbindung.

Beim Speichern werden der Algorithmus automatisch erkannt sowie Zertifikatssignatur, Gültigkeitszeitraum und Übereinstimmung mit dem privaten Benutzerschlüssel geprüft. Die gespeicherten Zugangsdaten und ihre Nutzungsrechte bilden die Verbindungsberechtigung auf der Plattform; separate Berechtigungen für öffentliche Schlüssel oder CAs müssen nicht angelegt werden. Öffentliche Schlüssel, CA- und Principal-Konfiguration sowie Authentifizierungsbeschränkungen auf dem Gerät pflegen Benutzer weiterhin selbst.

Das Gerät muss keine Schlüssel aus der Cloud abrufen und weder Versionen noch Anwendungsstatus zurückmelden. Die Plattform bearbeitet keine Dateien auf dem Gerät. Erfolgreiches Speichern bedeutet, dass die Cloud-Konfiguration gespeichert wurde; die tatsächliche Anmeldung prüft der SSH-Dienst des Geräts.

Die vollständige Anleitung für Windows PowerShell und Linux zur Schlüsselerzeugung, CA-Signierung, Autorisierung auf dem Gerät, zum Cloud-Upload und zur Verbindungsprüfung finden Sie unter SSH-Schlüssel- und Zertifikatsauthentifizierung. Eine normale Schlüsselanmeldung benötigt keine CA. Für die Anmeldung mit OpenSSH-Benutzerzertifikat werden das Benutzerzertifikat und der passende private Schlüssel benötigt. Der private CA-Schlüssel bleibt immer beim Aussteller.

Vorrang der Gerätekonfiguration, Flottenvererbung und Standardeinträge

Die Vererbung richtet sich nach Zielsystemkonto und Authentifizierungsverfahren:

• Liegt eine Gerätekonfiguration vor, können nur die entsprechenden gerätespezifischen Zugangsdaten verwendet werden. Der Flotteneintrag wird als überschrieben angezeigt;
• Fehlt eine entsprechende Gerätekonfiguration, wird der Flotteneintrag verwendet. Ein gesonderter Vererbungsschalter muss nicht konfiguriert werden;
• Ist ein Geräteeintrag abgelaufen, deaktiviert oder widerrufen, oder fehlt dem aktuellen Benutzer die Nutzungsberechtigung, erfolgt weder ein automatischer Rückfall auf die Flottenzugangsdaten noch ein Wechsel zur Passwortanmeldung;
• Auf derselben Ebene können mehrere Einträge gespeichert und ein Standard festgelegt werden. Die Standardmarkierung umgeht weder Verfügbarkeits- noch Berechtigungsprüfungen.

Geerbte Einträge sind schreibgeschützt und müssen auf Flottenebene bearbeitet werden. Bei Deaktivierung oder Widerruf bleibt der Vorrang der Gerätekonfiguration bestehen. Wird der letzte entsprechende Geräteeintrag gelöscht, kann die Flottenvererbung wieder wirksam werden. Prüfen Sie vorher die Auswirkungen, die im Bestätigungsdialog beschrieben werden.

Der Geltungsbereich der Zugangsdaten beschränkt nur den Zugang über JelinaCloud. Wenn unterschiedliche Flotten oder Konten auch lokal auf dem Gerät getrennt werden sollen, konfigurieren Sie selbst unterschiedliche öffentliche Schlüssel, CAs oder Regeln für Zertifikats-Principals.

Aktualisieren, deaktivieren, widerrufen und löschen

Vorgang	Verhalten
Bearbeiten	Name, berechtigte Mitglieder und Standardmarkierung ändern; privater Schlüssel und Passphrase werden nicht erneut angezeigt
Schlüssel oder Zertifikat aktualisieren	Neuen privaten Benutzerschlüssel, optionales Benutzerzertifikat und erforderliche Passphrase hochladen; Konto, Geltungsbereich und Verfahren bleiben unverändert
Deaktivieren / Aktivieren	Eine Deaktivierung ist reversibel. Neue Verbindungen sind danach nicht möglich; bestehende Verbindungen werden erneut geprüft und geschlossen
Zugangsdaten widerrufen	Der gespeicherte Eintrag kann nicht erneut aktiviert werden; sein verschlüsselter privater Schlüssel wird gelöscht. Andere separat gespeicherte Einträge und die Vertrauenskonfiguration des Geräts bleiben unberührt
Löschen	Verschlüsselte Daten löschen und Audit-Metadaten behalten; das Löschen eines Geräteeintrags kann die Flottenvererbung wiederherstellen

JelinaCloud stellt Benutzerzertifikate nicht automatisch aus und verlängert sie nicht automatisch. Fordern Sie vor Ablauf bei Ihrem CA-Administrator ein neues Zertifikat an, aktualisieren Sie es auf der Verwaltungsseite und prüfen Sie es. Eine Änderung des angezeigten Gültigkeitszeitraums verlängert kein Zertifikat.

Plattformaktionen betreffen ausschließlich Verbindungen über JelinaCloud. Sie bereinigen weder authorized_keys noch CA-Konfigurationen oder lokale KRL-Dateien auf dem Gerät automatisch. Um direkten SSH-Zugriff zu verhindern, muss der Geräteadministrator Widerrufe und das Entfernen alter Berechtigungen selbst umsetzen.

Gerätehostidentität bestätigen

Sowohl Schlüssel- als auch Zertifikatsverbindungen erfordern die Prüfung der Gerätehostidentität. Diese ist von Benutzerzertifikaten und ausstellenden CAs zu unterscheiden.

1. Führen Sie direkt auf dem Gerät oder über einen vertrauenswürdigen Zugang cat /etc/ssh/ssh_host_*_key.pub aus, um die vorhandenen öffentlichen Hostschlüssel abzurufen.
2. Klappen Sie in der „Fernzugriffsverwaltung“ des Geräts den Bereich „Gerätehostidentität“ auf, klicken Sie auf „Öffentlichen Hostschlüssel erfassen“ und fügen Sie jeweils eine Zeile ein.
3. Führen Sie auf dem Gerät ssh-keygen -lf <zugehörige_Hostschlüsseldatei.pub> -E sha256 aus und vergleichen Sie den vollständigen Fingerabdruck mit der Anzeige auf der Seite.
4. Klicken Sie bei Übereinstimmung auf „Prüfen und bestätigen“. Erfassen und prüfen Sie Schlüssel verschiedener Algorithmen jeweils separat.

Akzeptiert werden ausschließlich öffentliche Hostschlüssel, keine öffentlichen Benutzerschlüssel, Benutzerzertifikate, öffentlichen CA-Schlüssel oder privaten Schlüssel. Unterstützt werden Ed25519, ECDSA nistp256/384/521 und RSA mit 2048 bis 8192 Bit. Der Algorithmus wird automatisch erkannt. Das Backend wählt den bestätigten öffentlichen Schlüssel entsprechend dem tatsächlich mit dem Gerät ausgehandelten Algorithmus. Eine Anpassung von guacd oder eine Algorithmenauswahl durch den verbindenden Benutzer ist nicht erforderlich.

Nach einer Neuinstallation des Geräts oder einer Änderung der Hostidentität ist eine erneute vertrauenswürdige Prüfung erforderlich. Der Status Online führt nicht dazu, dass ein neuer öffentlicher Schlüssel automatisch als vertrauenswürdig gilt.

Verbindungseinstellungen und Kontingente

Die Verwaltungsseite verwaltet ausschließlich Anmeldezugangsdaten und Gerätehostidentitäten. Separate Berechtigungen für öffentliche Schlüssel oder CAs, persönliche Zertifikate sowie Flotten- oder Geräterichtlinien können dort nicht mehr bearbeitet werden. Welche Konten sich auf dem Gerät mit welchen öffentlichen Schlüsseln oder CA-Principals anmelden dürfen, konfiguriert der Geräteadministrator selbst.

Den standardmäßigen Verbindungsport und die global zulässigen Authentifizierungsverfahren verwaltet der Plattformadministrator zentral. Die Verbindungsseite zeigt weiterhin die aktuell erlaubten Verfahren. Um Authentifizierungswege wie direkte SSH-Passwortanmeldung am Gerät einzuschränken, ändern Sie dessen SSH-Konfiguration.

Verbindungskontingente, Obergrenzen pro Benutzer und Gerät sowie Leerlauf- und Höchstdauer werden weiterhin gemeinsam durch Organisationskontingente und Serverkapazität begrenzt. Mandanten sehen die wirksamen Werte schreibgeschützt und können sie nicht selbst erhöhen.

Aktive Verbindungen und Aktionsprotokolle

Die Verbindungsverwaltung zeigt aktive Verbindungen an und erlaubt deren Trennung entsprechend den Berechtigungen. Aktuelle Sitzungen liegen im Arbeitsspeicher des Dienstes; ein dauerhaft gespeicherter Sitzungsverlauf wird nicht angeboten. Aktionen werden weiterhin im bestehenden Aktionsprotokoll erfasst. Nach einem Dienstneustart oder der Freigabe des Sitzungszustands lassen sich alte Verbindungen nicht wiederherstellen; bauen Sie eine neue Verbindung auf.

Schutz privater Schlüssel und Geräteverschiebung

Private Benutzerschlüssel und erforderliche Passphrasen werden verschlüsselt gespeichert. Die Metadatenliste zeigt ausschließlich Name, Systemkonto, Geltungsbereich, Algorithmus, Gültigkeitszeitraum, Berechtigungen und Status. Private CA-Schlüssel verbleiben beim eigenen Aussteller und werden nicht auf die Plattform hochgeladen. Für wiederholte Anmeldungen speichert die Plattform keine privaten Schlüssel im lokalen Browsercache.

Nach dem Verschieben eines Geräts in eine neue Flotte oder Organisation sind die bisherigen gerätespezifischen Zugangsdaten und Berechtigungen nicht mehr verwendbar; ihre verschlüsselten Daten werden gelöscht. Auch beim Zurückverschieben werden sie nicht automatisch wiederhergestellt. Konfigurieren Sie die Zugangsdaten für den aktuellen Geltungsbereich erneut und prüfen Sie die Hostidentität. Alte Vertrauenseinstellungen auf dem Gerät pflegt weiterhin der Geräteadministrator selbst.