Zugangstresor

Zugangstresor, Masterkey und Synchronisierung

Ab Beta 7: Auto-Lock und App-PIN ergänzen den Tresor. Aktives Auto-Lock erzwingt die Masterpasswort-Abfrage beim App-Neustart auch bei gespeicherter Gerätefreigabe. Das Anzeigen von Passwörtern und sensible Änderungen benötigen eine manuelle Freigabe, die nach zehn Minuten abläuft.

Jeder Arbeitsbereich besitzt eigene Verbindungen, Zugangsdaten, einen unabhängigen zufälligen Masterkey und ein eigenes Masterpasswort. Zugangsdaten können innerhalb dieses Arbeitsbereichs mehreren Profilen zugeordnet werden. Das Starten der App und jeder Wechsel des Arbeitsbereichs erfordern dessen Passwort, sofern keine Gerätefreigabe gespeichert wurde.

Einrichten und Migrieren

Beim ersten Start ab Beta 6 wird für jeden vorhandenen Arbeitsbereich ein Masterpasswort mit mindestens 12 Zeichen verlangt. Name, Tabzustände und Profilkennungen bleiben erhalten. Die zuvor globalen Verbindungen und Zugänge werden zur Bestandserhaltung in jeden vorhandenen Arbeitsbereich kopiert. Anschließend sind Änderungen unabhängig.

Bei einem bisherigen portablen .zvault zuerst das alte Passwort eingeben. Verfügbare private SSH-Schlüssel werden in den neuen Speicher eingebettet. Die ursprünglichen Schlüsseldateien bleiben unverändert. Eine unterbrochene Einrichtung lässt sich mit den bereits festgelegten Passwörtern fortsetzen. Ohne vollständige Einrichtung startet keine Verbindung.

Zwei Dateien pro Arbeitsbereich

Datei	Inhalt
Masterkey.zmasterkey	Mit Masterpasswort verschlüsselter, zufälliger 256-Bit-Datenschlüssel
Workspace.zstorage	Mit diesem Schlüssel verschlüsselte Verbindungen, Zugangsdaten und private SSH-Schlüsselinhalte

Bei der Einrichtung einen lokalen Ordner, externen Datenträger oder synchronisierten Cloudordner auswählen. Ohne Auswahl liegt das Paar unter %LOCALAPPDATA%\Zumbyte\ServerDesk\workspaces\<Kennung>. Beide Dateien zusammen sichern; ohne Passwort und passendes Dateipaar gibt es keine Wiederherstellung durch Zumbyte.

Exportieren / Speicherort kopiert das verschlüsselte Paar in einen neuen Unterordner. Die Option Diesen Speicherort künftig … verwenden bindet den Arbeitsbereich an die exportierten Dateien. Ursprüngliche Dateien bleiben bestehen. Bestehende Zieldateien werden nicht überschrieben.

Importieren fragt Masterkey, passende Speicherdatei und Passwort ab. Die Dateien bleiben an ihrem ausgewählten Ort. Ein bereits bekannter Masterkey wird dem vorhandenen Arbeitsbereich zugeordnet; die Kennungen der Verbindungen und Zugänge bleiben gleich. Lokale Tabs und Fensterpositionen werden nicht über das Speicherpaar synchronisiert.

Passwort auf diesem Gerät speichern

Standardmäßig ausgeschaltet. Unter Windows speichert diese Option eine mit DPAPI für das aktuelle Benutzerkonto geschützte Gerätefreigabe. Das eigentliche Passwort wird nicht gespeichert. Die Freigabe liegt nur lokal in device-unlock.json, ist an Masterkey-Datei und Speicherort gebunden und darf nicht zwischen Rechnern kopiert werden. Andere Personen mit Zugriff auf dasselbe entsperrte Windows-Konto können diesen Arbeitsbereich dann ebenfalls automatisch öffnen.

Im Zugangstresor die Option deaktivieren, um die Freigabe zu entfernen. Sperren trennt die Sitzungen dieses Arbeitsbereichs und entfernt entschlüsselte Zugangsdaten aus der aktiven Verwaltung. Offene Bearbeitungen zuvor sichern; bei einer von außen erzwungenen Sperre bleiben ungespeicherte Editorpuffer bis zum erneuten Entsperren erhalten. Eine macOS-Gerätefreigabe ist noch nicht integriert.

Gemeinsam zwischen Systemen arbeiten

1. Das Dateipaar in einem Cloud-Sync-Ordner ablegen und diesen Speicherort verwenden.
2. Synchronisierung beider Dateien auf dem anderen System abwarten.
3. Dort Importieren wählen und das Paar mit demselben Masterpasswort öffnen.
4. Änderungen an Verbindungen und Zugangsdaten werden im gemeinsamen Speicher gespeichert.

Die aktive Datei wird laufend überwacht: Dateiwächter mit regelmäßiger Prüfung, auch bei verpassten Ereignissen. Ab Beta 15 übernimmt die App gültige Änderungen automatisch im Hintergrund. Neue Verbindungen erscheinen; geänderte Namen und Zugänge werden aktualisiert; entfernte Verbindungen verschwinden. Offene Dialoge und ungespeicherte Editorinhalte verhindern die Aktualisierung nicht. Ein bereits geöffneter Änderungsdialog darf einen neueren Stand nicht überschreiben und zeigt bei einem veralteten Speicherversuch einen Hinweis.

Unveränderte Sitzungen bleiben aktiv. Geänderte oder entfernte Verbindungsziele und Zugangsdaten trennen nur die betroffenen Sitzungen. Falls dafür laufende Dateiaktionen beendet werden müssten, wartet die App bis zu deren Abschluss und übernimmt die Änderung anschließend selbstständig. Der Dateizugriff bleibt in dieser Zeit verfügbar. Bei entfernten oder geänderten Serverzielen bleiben offene Editorinhalte erhalten; automatischer Rückupload wird deaktiviert. Über Speichern unter lassen sich die Dateien lokal sichern.

Unvollständige, vorübergehend fehlende oder ungültige Cloud-Dateien werden erneut geprüft; bis dahin bleiben die zuletzt gültigen Daten für Dateioperationen nutzbar. Änderungen am Tresor können erst wieder gespeichert werden, wenn ein gültiger aktueller Stand verfügbar ist. Ein gültig geänderter Masterkey sperrt den Arbeitsbereich und hebt die bisherige Gerätefreigabe auf; diese Sicherheitsgrenze bleibt bestehen.

Vor jedem Speichern werden die eingelesenen Dateihashes verglichen. Veraltete Schreibversuche werden blockiert. Bei gleichzeitigen gültigen Ständen übernimmt die App automatisch den Cloudstand und legt die verdrängte lokale Fassung verschlüsselt unter Workspace.zstorage.history/before-sync-….zstorage ab. Es gibt keine automatische Zusammenführung einzelner Felder. Ältere Cloud-Zwischenstände überschreiben einen bereits neueren geladenen Stand nicht. Cloudanbieter können verzögert synchronisieren oder eigene Konfliktkopien erzeugen. Die App ist keine verteilte Datenbank und garantiert keine atomaren Schreibvorgänge zwischen mehreren Rechnern. Konfliktkopien des Cloudanbieters werden nicht ohne Auswahl importiert; verschlüsselte Verlaufskopien zusammen mit dem passenden Masterkey sichern.

.bak und .history/*.zstorage enthalten verschlüsselte Sicherungen. Die Migration legt eine zusätzliche verschlüsselte .zbackup mit der bisherigen lokalen Konfiguration an, geschützt durch den Masterkey des damals aktiven Arbeitsbereichs. Ursprüngliche externe Backups bleiben bestehen.

Private SSH-Schlüssel

Im Zugang Durchsuchen… wählen. OpenSSH-/PEM-Dateien oder Dateien ohne Endung wie id_ed25519 lassen sich auswählen. Der Inhalt wird gemeinsam verschlüsselt gespeichert und bleibt ohne ursprüngliche Datei verwendbar. Bei der Migration fehlende Dateien können nachträglich neu zugeordnet werden. Maximale Schlüsseldateigröße: 4 MB.

Weiter: Arbeitsbereiche · Cloudspeicher · Daten und Sicherheit

Passwörter beim Verbinden

Ein Profil kann unter Verbindung bearbeiten → Zugang aus dem Tresor einen vorhandenen Zugang verwenden. Eine neue Auswahl übernimmt dessen Benutzernamen. Ein abweichender Benutzer kann anschließend eingetragen werden. SSH-Schlüssel werden einschließlich des im Tresor gespeicherten Schlüsselinhalts und der Passphrase verwendet.

Ohne zugewiesenen Zugang erscheint beim Verbinden eine Anmeldung: vorhandenen Tresorzugang wählen oder Benutzer und Passwort eingeben. Zugang verschlüsselt im Tresor speichern ist standardmäßig ausgeschaltet. Ohne Speicherung bleibt die Eingabe nur im Arbeitsspeicher des entsperrten Arbeitsbereichs; Sperren, Arbeitsbereichswechsel und App-Ende verwerfen sie. Auch beim Anlegen eines Profils ist ein optionales Passwort mit Speichercheckbox möglich.

Beim Anmelden wird ein neues Passwort erst nach erfolgreicher SSH-Anmeldung gespeichert. Das Speichern beziehungsweise Zuordnen eines Zugangs benötigt die normale manuelle Masterpasswort-Freigabe; die Checkbox umgeht sie nicht. Das Bearbeiten eines Profils mit aktivierter Speichercheckbox speichert die ausdrücklich konfigurierten Daten direkt.

SSH und SFTP unterstützen Passwort und Keyboard Interactive für eindeutige Passwortabfragen. Zusätzliche Einmalcodes und andere interaktive Faktoren werden nicht mit dem gespeicherten Passwort beantwortet. Nach einer abgelehnten SSH-Anmeldung erscheint beim nächsten Versuch wieder die Zugangsauswahl. Private Schlüssel ohne verfügbaren Inhalt werden mit einer verständlichen Fehlermeldung abgewiesen.

Hostgruppen und Untergruppen

Ab Beta 17 erscheinen Verbindungen nach Host sortiert – in der Seitenleiste, der Serverübersicht, Remote Desktop, im Zugangstresor und bei der Auswahl und Verknüpfung von Zugängen. Bestehende Gruppen werden als Untergruppen des jeweiligen Hosts angezeigt. Benutzernamen, Ports, Protokolle und Verbindungsnamen bleiben je Profil erhalten. Cloud- und Speicherprofile bleiben unter Speicher.

Im Profil steht dafür Untergruppe zur Verfügung. Administration/root erzeugt zwei Ebenen unter dem Host; Benutzer/Andreas einen separaten Zweig. Leer oder Allgemein zeigt das Profil direkt unter dem Host. Bis zu acht Ebenen sind möglich. Per Rechtsklick auf ein Profil oder eine Gruppe öffnet Untergruppe zuweisen … die geschützte Zuordnung. Bei einer Gruppe werden deren ausgewählte Verbindungen in den angegebenen Pfad eingeordnet. Dadurch ändern sich weder Zieladresse noch Benutzer, Port oder Zugangsdaten. Die Zuordnung liegt verschlüsselt im Arbeitsbereich und wird zwischen Geräten übernommen.

Host- und Untergruppen lassen sich einzeln aufklappen; der Zustand wird auf diesem Gerät pro Arbeitsbereich gespeichert. Über das Host-Kontextmenü können neue Verbindungen mit vorbelegter Adresse angelegt werden. Verbinden, Trennen, Bearbeiten und Favoriten bleiben auch für Gruppen verfügbar.

Ein Tresorzugang, den mehrere Verbindungen oder Hosts verwenden, erscheint unter jedem passenden Host und jeder zugehörigen Untergruppe. Dabei wird der Zugang nicht vervielfältigt. Unverknüpfte Zugänge stehen unter Noch keinem Host zugeordnet. Zugang auswählen bietet eine Suche nach Host, Gruppe, Zugang, Benutzer, Protokoll und Port. Eine Gruppierung ersetzt keine serverseitige SSH-Freigabe: Der öffentliche Anmeldeschlüssel muss zum Zielkonto gehören und dort zugelassen sein; der angezeigte Fingerabdruck des SSH-Hosts ist davon getrennt.

Hostnamen werden bezüglich Groß-/Kleinschreibung, Ports und URL-/UNC-Schreibweise normalisiert. Unterschiedliche DNS-Aliase und IP-Adressen werden nicht automatisch zusammengelegt. Remote Desktop zeigt weiterhin ausschließlich RDP und VNC.

Verschieben und Anordnung ab Beta 18

Verbindungen lassen sich innerhalb ihres Hosts per Drag-and-drop in Untergruppen oder zurück direkt unter den Host verschieben. In der Mitte einer Gruppenüberschrift ablegen, um die Verbindung dort einzuordnen. Eine schmale Linie am oberen oder unteren Rand fügt Verbindungen oder Gruppen davor bzw. dahinter ein. Hostüberschriften lassen sich untereinander anordnen. Ganze Untergruppen nehmen beim Umziehen alle darunterliegenden Verbindungen und weiteren Untergruppen mit – auch wenn eine Ansicht gerade nur bestimmte Protokolle zeigt. Ein zusammengeklappter Zweig öffnet sich beim Darüberhalten; am Rand der Seitenleiste wird automatisch gescrollt.

Die Reihenfolge gilt in allen Ansichten, einschließlich Tresor und Zugangsauswahl. Der Tresor zeigt gemeinsam genutzte Zugänge je Zweig einmal; einzelne Zugangszeilen lassen sich dort nicht zum Umhängen von Verbindungen ziehen. Auswahlfenster bleiben reine Auswahlfenster. In der Seitenleiste, Serverübersicht und Remote-Übersicht lassen sich einzelne Verbindungen ziehen; Host- und Gruppenüberschriften können auch im Tresor angeordnet werden.

Unter Anordnung im Rechtsklickmenü gibt es zusätzlich Nach oben verschieben, Nach unten verschieben, Inhalt nach Namen sortieren und bei Hostgruppen Hostgruppen nach Namen sortieren. Die Anordnung liegt verschlüsselt im Speicher des jeweiligen Arbeitsbereichs, wird beim erneuten Entsperren wiederhergestellt und bei Änderungen der gemeinsamen Cloud-Datei automatisch übernommen. Ein neuer Arbeitsbereich beginnt mit eigener Anordnung. Ältere App-Versionen können diese zusätzliche Reihenfolge beim erneuten Speichern verwerfen; auf gemeinsam genutzten Geräten deshalb Beta 18 oder neuer verwenden.

Eine nötige Masterpasswort-Freigabe erscheint erst beim Ablegen und gilt wie andere sensible Änderungen zehn Minuten. Abbrechen verändert nichts. Zwischen unterschiedlichen Hosts werden keine Verbindungen verschoben, da Gruppierung keine Serveradresse ändern soll. Eine Gruppe kann weder in sich selbst noch in einen ihrer Unterzweige wandern. Besteht am Ziel schon eine gleichnamige Untergruppe, wird das Zusammenführen verhindert; ebenso mehr als acht Ebenen. Adresse, Benutzer, Port und Zugangsdaten bleiben erhalten. Unveränderte aktive SSH- und SFTP-Verbindungen laufen auch nach einer synchronisierten Anordnungsänderung weiter.

Gruppen verwalten ab Beta 19

Per Rechtsklick auf die Kategorie Verbindungen oder auf einen freien Bereich in Server & Computer öffnet Hostgruppe erstellen … einen Dialog für Hostadresse und Anzeigename. Die Gruppe darf zunächst leer bleiben. Bei bereits vorhandenen Verbindungen erscheint der Host automatisch; über Gruppe umbenennen … lässt sich dafür ein eigener Anzeigename setzen. Die Adresse des Servers und die Namen der einzelnen Verbindungen ändern sich dabei nicht.

Im Kontextmenü einer Hostgruppe legt Neue Hauptgruppe … einen neuen Zweig direkt unter dem Host an. Im Kontextmenü einer Gruppe fügt Neue Untergruppe … eine weitere Ebene hinzu. Auch dort kann Neue Hauptgruppe … einen Zweig direkt unter dem Host anlegen. Leere Gruppen sind eigenständige, verschlüsselt gespeicherte Einträge. Sie lassen sich anordnen, verschieben und als Drag-and-drop-Ziel für Verbindungen verwenden. Neue Verbindung in dieser Gruppe … belegt Host und Gruppenpfad passend vor.

Gruppe umbenennen … erhält enthaltene Untergruppen und Verbindungen sowie deren gespeicherte Reihenfolge. Gruppennamen bestehen aus 1 bis 100 Zeichen, ohne Pfadtrenner; bis zu acht Ebenen sind möglich. Gleichnamige Geschwistergruppen werden verhindert. Der Name Allgemein ist auf der obersten Ebene für Verbindungen direkt unter dem Host reserviert.

Gruppe löschen … zeigt eine Bestätigung und verschiebt alle darin enthaltenen Verbindungen, einschließlich der Verbindungen verschachtelter Untergruppen, direkt unter ihren Host. Der ganze betroffene Gruppenzweig wird dabei entfernt. Verbindungen und Tresorzugänge bleiben erhalten, ebenso Benutzer und Ports. Beim Löschen einer Hostgruppe werden deren Anzeigename und Gruppenstruktur entfernt; solange Profile für diesen Host existieren, bleibt er als automatischer Host sichtbar. Eine vollständig leere Hostgruppe wird entfernt. Einzelne Verbindungen werden weiterhin ausdrücklich über deren eigenes Kontextmenü gelöscht.

Gruppenaktionen benötigen die bestehende Masterpasswort-Freigabe. Abbrechen verändert keine Gruppen. Ein zwischenzeitlicher Wechsel oder eine Änderung der gemeinsamen Speicherdatei verhindert das Speichern eines veralteten Dialogstandes. Gruppen, Anzeigenamen und Anordnung bleiben je Arbeitsbereich getrennt und werden mit seiner verschlüsselten Datei zwischen Geräten synchronisiert. Alle beteiligten Geräte benötigen Beta 19 oder neuer, damit ältere Versionen neue Gruppenfelder beim Speichern nicht verwerfen. Auswahlfenster zeigen nur Zweige mit auswählbaren Einträgen und bieten weiterhin keine Gruppenverwaltung an. Cloud- und Speicherprofile bleiben im Bereich Speicher.