Wie deine SSH-Zugangsdaten gehandhabt werden

Das ist der sicherheitskritischste Teil von Server Manager. Hier ist genau beschrieben, was in jeder Phase mit deinen SSH-Zugangsdaten passiert.

Wenn du einen Server verbindest (ohne Speichern)

Der Standardweg: Gib im Verbindungsdialog die IP-Adresse deines Servers, den Benutzernamen und das Passwort bzw. den privaten Schlüssel ein und klicke auf „Verbinden“.

• Deine Zugangsdaten werden über HTTPS an Server Manager gesendet
• Sie werden im Prozessspeicher der serverseitigen Sitzung gehalten, die mit deinem Server kommuniziert
• Nichts wird auf die Festplatte geschrieben. Keine Datenbank, keine Logdatei, kein Cache.
• Wenn du die Verbindung trennst, deinen Browser-Tab schließt oder die Sitzung abläuft, werden die Zugangsdaten aus dem Speicher verworfen

Wenn unser Server neu gestartet wird, sind deine Zugangsdaten weg — beim nächsten Mal musst du dich wieder manuell verbinden. Das ist so beabsichtigt.

Wenn du ein Serverprofil speicherst (optional)

Wenn du beim Verbinden „Diesen Server speichern“ auswählst, verschlüsseln wir deine Zugangsdaten mit einer Passphrase, die nur du kennst.

Was verschlüsselt wird

Der verschlüsselte Blob enthält entweder dein SSH-Passwort ODER deinen privaten Schlüssel plus optionale Passphrase für den Schlüssel. Dazu kommt ein kleiner Metadaten-Header, damit wir wissen, welche Art von Zugangsdaten verwendet werden soll.

Wie die Verschlüsselung funktioniert

• Du gibst beim Speichern eine Passphrase an (wir empfehlen etwas, das du nirgendwo sonst verwendest)
• Die Passphrase wird durch scrypt geleitet — eine absichtlich langsame passwortbasierte Schlüsselableitungsfunktion — zusammen mit einem zufälligen 16-Byte-Salt pro Server, um einen 256-Bit-AES-Schlüssel zu erzeugen
• Deine Zugangsdaten werden mit AES-256-GCM verschlüsselt (authentifizierte Verschlüsselung — manipulierte Ciphertexts können nicht entschlüsselt werden, keine Padding-Oracle-Angriffe)
• Wir speichern den verschlüsselten Ciphertext, den Salt, die GCM-Nonce und den GCM-Authentifizierungs-Tag in der Datenbank
• Deine Passphrase wird niemals gespeichert. Nicht gehasht, nicht abgeleitet, nicht irgendwo auf unserer Seite vorhanden.

Wie wir „falsche Passphrase“ von „manipulierte Daten“ unterscheiden

Beides schlägt auf dieselbe Weise fehl: Die Prüfung des AES-GCM-Authentifizierungs-Tags schlägt fehl. Es gibt keinen gespeicherten Prüfer, mit dem wir deine Passphrase vergleichen könnten, und keinen Hash, der durchsickern könnte. Falsche Passphrase = Entschlüsselungsfehler = du gibst sie erneut ein und versuchst es noch einmal.

Wenn du dich erneut mit einem gespeicherten Server verbindest

Du fügst deine Passphrase ein. Wir leiten den Schlüssel erneut mit scrypt und dem gespeicherten Salt ab, entschlüsseln den Zugangsdaten-Blob, verwenden die entschlüsselten Zugangsdaten zum Öffnen der SSH-Sitzung und verwerfen die entschlüsselten Zugangsdaten sofort wieder aus dem Speicher, sobald die Sitzung hergestellt ist.

Die entschlüsselten SSH-Zugangsdaten befinden sich nur im Code, der die Sitzung verarbeitet, und nur für die Dauer der SSH-Verbindung selbst. Genau wie beim Ablauf ohne Speichern oben — nur im Speicher, nicht auf der Festplatte.

Was passiert, wenn unser Server kompromittiert wird

Gegen diese Bedrohung ist das Design ausgelegt. Konkret:

• Ein Angreifer erhält Lesezugriff auf die Datenbank: Er bekommt Ciphertext. Um gespeicherte Zugangsdaten zu verwenden, muss er die Passphrase für jeden Server per Brute Force knacken. - scrypt ist absichtlich langsam — jeder Passphrase-Versuch benötigt auf moderner Hardware etwa 100 ms oder mehr CPU-Zeit. Selbst das Brute-Forcing einer zufälligen Passphrase mit 6 Zeichen dauert auf einer einzelnen Maschine Jahre, auf handelsüblichen GPUs Jahrzehnte.
• Ein Angreifer erhält vollständige Kontrolle über den Server (RCE — Remote Code Execution — während einer laufenden Sitzung): Er könnte entschlüsselte Zugangsdaten von Benutzern auslesen, die gerade online sind. Er erhält aber keinen Zugriff auf die Zugangsdaten von gespeicherten Servern, deren Benutzer offline sind.
• Ein Angreifer erhält ein Datenbank-Backup von letzter Woche: Das ist dasselbe wie Lesezugriff — er hat nur Ciphertext.

Was das praktisch für dich bedeutet

Die drei Szenarien oben führen in der Praxis zu sehr unterschiedlichem Risiko:

• Datenbank-Lesezugriff oder gestohlenes Backup (die häufigste Art von Sicherheitsvorfall): Der Angreifer erhält verschlüsselte Blobs und sonst nichts. Um gespeicherte Zugangsdaten tatsächlich zu verwenden, müsste er deine Passphrase per Brute Force knacken; mit scrypt ist das bei einer starken Passphrase praktisch nicht machbar. Deine Server bleiben sicher.
• Vollständige Serverkompromittierung, während du aktiv verbunden bist (selten und schwerwiegend): Da eine offene SSH-Sitzung deine echten Zugangsdaten im Speicher benötigt, könnte ein Angreifer, der unseren laufenden Prozess in diesem Zeitfenster kontrolliert, die entschlüsselten Zugangsdaten der Benutzer auslesen, die in diesem Moment verbunden sind und sich damit auf den tatsächlichen Servern dieser Benutzer anmelden. Wenn du zu diesem Zeitpunkt offline bist, sind deine gespeicherten Zugangsdaten für ihn weiterhin nur Ciphertext — du bist nicht betroffen.

Die wichtigste Eigenschaft: Selbst im Albtraumszenario einer vollständigen Kompromittierung ist der Schadensradius auf „wer während des Angriffs gerade online ist“ begrenzt, nicht auf „alle, die Server Manager jemals genutzt haben“. Bei den meisten katastrophalen Sicherheitsvorfällen werden die Geheimnisse aller Benutzer auf einmal offengelegt; dieses Design verhindert genau das bewusst.

Das ist ein wirksamer Schutz gegen das häufigste Muster bei Sicherheitsvorfällen (Datenexfiltration). Gleichzeitig akzeptiert das Design bewusst, dass ein Angreifer mit vollständiger Kontrolle über einen laufenden Live-Server eine andere, schwierigere Bedrohung darstellt, die wir nicht vollständig abzuwehren beanspruchen — wobei selbst dieser schlimmste Fall weiterhin auf aktuell online befindliche Benutzer begrenzt bleibt.

Empfehlung für starke Passphrasen

Das gesamte Verschlüsselungskonzept ist nur so stark wie deine Passphrase. Empfohlen:

• Mindestens 20 zufällige Zeichen, oder
• Fünf zufällige englische Wörter (wie bei „correct horse battery staple“) — leicht zu merken, schwer per Brute Force zu knacken
• Verwende niemals dieselbe Passphrase wie für die Anmeldung auf deinem Laptop, deinen Passwortmanager oder deine E-Mail
• Gib sie nicht weiter. Server Manager selbst braucht sie nicht — sie ist nur zwischen dir und dem verschlüsselten Blob.

Wenn du die Passphrase verlierst, können die gespeicherten Zugangsdaten nicht wiederhergestellt werden. Du müsstest das gespeicherte Serverprofil löschen und es von Grund auf neu hinzufügen.

Warum wir keinen „passwortlosen“ oder besonders bequemen Schlüsselzugriff anbieten

Einige Produkte speichern SSH-Schlüssel unverschlüsselt („Vertrau uns, wir bewahren sie sicher auf“) oder schützen sie nur mit dem Kontopasswort des Benutzers. Server Manager tut das nicht. Der Passphrase-Mechanismus ist die Grenze zwischen „jeder mit unserer Datenbank kann sich per SSH auf deinen Servern anmelden“ und „jeder mit unserer Datenbank muss zuerst deine Passphrase per Brute Force knacken“. Wir finden, dass das die einmalige kleine Unbequemlichkeit wert ist, eine Passphrase auszuwählen.

Was NIEMALS gesendet oder gespeichert wird

• Private SSH-Schlüssel im Klartext in unserer Datenbank
• SSH-Passwörter im Klartext in unserer Datenbank
• Deine Verschlüsselungs-Passphrase — nirgendwo, in keiner Form
• Entschlüsselte Zugangsdaten in irgendeinem persistenten Speicher — Festplatte, Logs, Backups, Cache

Der einzige Ort, an dem entschlüsselte Zugangsdaten existieren, ist der Prozessspeicher der laufenden Sitzung, und das nur für die Dauer der Sitzung.

Fragen oder Bedenken?

Wenn etwas in diesem Artikel unklar ist oder du eine konkrete Sicherheitsfrage dazu hast, wie deine Zugangsdaten gehandhabt werden, melde dich über Kontakt — wir erklären es dir gern genauer.