[Sammelthread] napp-it cs, Web-GUI für fast jeden ZFS Server oder Clustergruppen

[gea]

Im Kern bleibt es natürlich so dass die Qualität eines Passwort(hash) mit der Länge des pw steigt.

Es geht bei dieser Funktion letztlich darum,:
- alle key gleich lang, auch bei kurzem pw
- wenn der Hash oder ein Teil davon abgegriffen wird, so soll man daraus nicht einfach per Tabelle auf das pw schliessen können
- dataset name ist quasi das Hash Salz. Damit wird verhindert dass besonders einfach aus dem Hash das pw ermittelt wird
- man kann damit einfach merkbare pw als key nehmen wie "meine Katze heisst Fritz"

Insgesamt gilt natürlich, das ist nur ein Kiss Hilfsmittel. Bei Besonderheiten oder Änderungen auch bei alten Datasets muss man den alten Key kennen und eingeben, die easy 123 Option geht dann nicht.

ps
wenn man den alten key kennt, kann man einen neuen, passenden setzen: zfs change-key pool/dataset.
In System > SHA256hash kann man den key aus hash der art datasetpath + pw generieren

 

[Rach78]

okay das verstehe ich. Aber als salt würde ich persönlich doch eher eine Dataset Eigenschaft nehmen die nicht veränderbar ist wie zB entstehungsdatum oder ein random string der als optionales ZFS Parameter an das Dataset geheftet werden kann (sofern möglich). So würde ein rename von Pool und/oder Dataset hier für keine Probleme sorgen. Den Namen finde ich etwas suboptimal hier aus den genannten Gründen weil ich damit eine ungewollte und unnötige Abhängigkeit zwischen 2 Dingen herstelle die gar nicht vorhanden sein muss.

Änderungen auch bei alten Datasets muss man den alten Key kennen und eingeben,

Wie entsperrt man denn in CS ein Dataset was schon etwas älter ist und mit SE erstellt worden ist? Habe das nicht hinbekommen. Der Key 1:1 wird von SE akzeptiert von CS aber nicht. Und wenn ich in CS über die sha256 hex funktion Poolname+Datasetname+Key nehmen und dadurch nen Hash generiere und mit diesem Hash versuche zu entsperren geht auch nicht.

Also ist kein Weltuntergang weil entsperren durch SE ja nocht geht aber wollte eigentlich komplett nur noch CS am Ende irgendwann dann am laufen haben.

 

[gea]

ist wie immer ein Kompromiss zwischen KISS und Sicherheit.
Eine deutliche Verbesserung wäre nur ein random salt, dann muss man den aber irgendwo mitführen. Eine private ZFS property ist auch nicht unproblematisch weil die nur bei zfs send -p oder -r übertragen wird. Ein salt als Keyanfang wäre denkbar, ist aber inkompatibel zum aktuellen key. Käme als Switch infrage wenn künftig nötig.

Generell gilt, der dataset name soll vor allem die Sicherheit bei sehr kurzen PW wie 123 verbessern, ansonst

Gemini: "Ein SHA-256-Hash (unabhängig davon, ob er als Hexadezimal-String oder Rohdaten dargestellt wird) gilt nach heutigem Stand der Wissenschaft und Technik als extrem sicher und für praktische Angriffe als unknackbar"

Zum Öffnen von enc se datasets in cs Menüs
Das Problem ist, dass cs kurze keys aus se <31 char als Passwort und nicht als Key sieht. Man müsste also das Dataset mit dem alten key in se oder auf console in cs entsperren und dann mit einen langen oder passenden sha256hex key versehen.

 

[Rach78]

Käme als Switch infrage wenn künftig nötig.

Ja ich seh das halt nur als suboptimal an was die usebility angeht. Einmal den Namen geändert und schon lässt sich nicht mehr entsperren mit dem kurzen pw und am Ende weiß kein Mensch mehr wieso "ach stimmt da war ja was hab das Dataset mal umbenannt". Auf meinem Backupserver heißt der Pool ggf auch anders.

Eine private ZFS property ist auch nicht unproblematisch weil die nur bei zfs send -p oder -r übertragen wird

Muss ja einfach nur etwas sein was halt über die ganze "lebzeit" des Datasets quasi identisch bleibt. Ansonsten muss man es irgendwie mit speichern ja. Könnte man aber ja mit dem Backup der Configuration machen.

Der Salt selbst muss ja darüber hinaus auch kein Geheimnis sein. Wäre ggf auch okay wenn jedes Dataset was auf dem selben Server erstellt wird erstmal das gleiche bekommt und optional dann zu ändern wäre.

 

[gea]

Letztendlich führt nichts an der Erkenntnis vorbei, das jedes Bemühen ohne eine Mindestkomplexität des PW vergeblich ist. Jede Salt oder Pepper Variante um kurze PW hash sicher zu machen sind vergeblich wenn Salt oder Pepper auf dem Rechner oder dem Dataset verfügbar sind.

Ich werde wohl dazu übergeben
- das jetzige Verfahren mit passsphrase und dataset zu belassen (Kompatibilität), hilft etwas gegen Hash Tabellen für pw wie 123)
- bei der PW Eingabe deutlich zu machen oder gar zu fordern, dass ein PW aus drei Worten, getrennt durch Sonderzeichen, idealerweise mit einer Zahl bestehen MUSS um sicher zu sein z.B. Katze-Mond-Hammer oder noch besser mit einer Zahl zusammen wie Katze-Mond-Hammer24 (Groß/Kleinschreibung egal)
- Beim Öffnen Kompatibilität mit kurzen se Alt-Keys herstellen z.b. durch retry on error

 

[Rach78]

Jede Salt oder Pepper Variante um kurze PW hash sicher zu machen sind vergeblich wenn Salt oder Pepper auf dem Rechner oder dem Dataset verfügbar sind.

Nein. Afaik ist die Aufgabe von Salt die einen Angriff über Rainbow Tables zu verhindern. Sprich auf große Tabellen zurückgreifen zu können wo man einfach nur nach dem Hash suchen kann, der dann auf das Passwort "123" zurückzuführen ist.
Durch den Salt ist das Passwort von dem der Hash gebildet wird nicht mehr 123 sondern 123+Salt und die Rainbow Table ist nutzlos sofern sie nicht zu exakt diesem Salt passt was äußerst unwarscheinlich ist.
Also der Salt an sich ist nichts was besonders schützenswert ist, das Geheimnis sollte am Ende so oder so das Passwort sein. Wenn man einfache Passwörter unterbinden will muss man sie bei der Vergabe schon ablehnen (Mindestlänge, mindestens GroßKleinschreibung, Zahlen etc)

Was einfache Passwörter angeht verhindert ein Salt auch nur den Angriff über RainbowTables. Der Salt muss ja so oder so immer auf dem Rechner gespeichert sein sonst kann der Rechner bei der Passworteingabe ja den korrekten Hash mit der Salt gar nicht bilden.
Und der Poolname und Datasetname ist ja ohnehin immer sichtbar und über den Quellcode vo Nappit bzw Doku ist ja eh bekannt wie der Salt lautet. Wenn ich Poolname und Dataset Name kenne kenne ich eh schon den Salt.
Das ist nicht schlimm, aber im Grunde könntest du statt diesem String auch einen anderen nehmen, das würde sicherheitstechnisch gar kein Unterschied machen.

Beispiel wie es bei mqtt Broker Mosquito läuft: https://dmelo.eu/blog/mosquitto_passwd_gen/

Der salt wird einfach zufällig erzeugt und dann mit abgespeichert.

wenn Salt oder Pepper auf dem Rechner oder dem Dataset verfügbar sind.

Sind sie bei der aktuellen Umsetzung aber eh weil Dataset und Poolname bekannt sind.

Ich sehe hier eine grundsätzliche Frage die man klären muss: Möchte ich das Dataset mit dem kurzen Passwort auch auf anderen Servern öffnen können oder will ich das nicht.
Wenn ich das eh nicht will würde ja nichts dagegen sprechen den Salt einfach auf dem Server selbst zu belassen. Dann kann ich das Dataset in Server1 der den passenden Salt zu dem Dataset kennt eben mit dem kurzen Passwort öffnen, aber anderswo benötige ich dann die volle passphrase.
Will ich auf Server2 auch mit dem Passwort öffnen können muss ich den Salt mit rüber kopieren. Ich meine es gibt ja pro Dataset eindeutige IDs worüber dann die Salt mit dem passenden Dataset zu verknüpfen wäre sodass Nappit weiß welche Salt es für welches Dataset nehmen muss. ggf wäre auch die guid denkbar als salt. Diese sollte ja immer gleich bleiben auch wenn ich den Pool umbenenne (mit dem Nachteil dass diese dann natürlich nicht mehr zu ändern ist so einfach), da bin ich aber nicht tief genug in ZFS drin und weiß net was bei Cloning ggf passiert mit der GUID etc.

Oder man spart sich das mit dem Salt und sagt einfach der User soll vernünftige Passwörter einsetzen.

 

[gea]

Genau das ist der Kern des Problems

Pw 123 oder 123Salt unterscheiden sich nur in der Frage ob es Sekunden, Minuten oder allenfalls Stunden dauert um das PW aus dem Hash zu ermitteln. Wenn man das so akzeptiert kann man den Salt/Pepper Aufwand bei single Word PW lassen. Ohne vernünftige PW (z.B. 3 Worte mit Bindestrich, idealerweise mit Zahl z.B. Hase-Mond-Stein24) wird das nichts.

 

[gea]

Interaktive Remote Console (Puttý alike)
Für Nutzer voller Consolezugriff (System > Console)

Für AI nach Console Modus Freigabe + manueller PW Eingabe
AI kann dann selbstständig Checks, Installationen oder Reparaturen vornehmen.

napp-it_4ai_rc_26.09.06.09
(currently you must download dev edition for new features)

- cs-console for any member OS (first rc)
Console and Expect mode for interactive commands eg change user pw
https://github.com/guenther-alka/cs-console

Update in About > Frontend Update (update dev release)
Use menu About > Download cs tools to download cs console on member
Open Menu System > Console for a full intractive console on member

 

[Rach78]

Wenn man das so akzeptiert kann man den Salt/Pepper Aufwand bei single Word PW lassen. Ohne vernünftige PW (z.B. 3 Worte mit Bindestrich, idealerweise mit Zahl z.B. Hase-Mond-Stein24) wird das nich

Bei der aktuellen Umsetzung würde ich persönlich es lieber weglassen weil mir die Verbindung Salt=Poolname+Datasetname nicht gefällt und ich hier eine unnötige Fehlerquelle sehe wie schon erklärt wegen Umbenennung oder weil mein Pool auf meinem Backuprechner vielleicht schon anders heißt.
Sofern nicht geschehen sollte das zumindest in die Doku dass ein Umbennenen hier etwas "kaputt machen" kann. Sonst weiß man ggf nichtmal woran es liegt.

 

[gea]

Ich werde in der nächsten Version nur noch hash aus pw als hash quelle nutzen, kein Pfad mehr aber mit der Aufforderung drei Worte mit Trennzeichen optional mit Zahl al pw zu nehmen. Das bisherige Verfahren bleibt dann nur als Fallback beim Unlock, genau wie Keys aus se. Kompletteingabe des SHA256 Keys bei unlock bleibt immer eine Option, kompletter key sollte immer irgendwo gesichert sein.

Bin nur die nächsten Tage eingespannt, das muss ein paar Tage warten.

 

[Rach78]

Kompletteingabe des SHA256 Keys bei unlock bleibt immer eine Option, kompletter key sollte immer irgendwo gesichert sein.

Ja das wäre vom Verhalten dann identisch zu Windows und Bitlocker. Normalerweise reicht der Pin zum entsperren. Und im WorstCase das Wiederherstellungspasswort.

Mit dem langen Schlüssel bekomme ich es dann auch entsperrt in anderen Betriebssystemen wie zB TrueNAS etc.

Der einzige " Schönheitsfehler" ohne Salt wäre nur dass identische Keys/Passwörter zu gleichen Hashes führen. Aber der Hash selbst ist ja sowieso nicht auf dem Server gespeichert weil er das eigentliche Geheimnis darstellt. Denke das dürfte hier aber irrelevant sein und stellt kein Problem da.

Das Problem ist, dass cs kurze keys aus se <31 char als Passwort und nicht als Key sieht. Man müsste also das Dataset mit dem alten key in se oder auf console in cs entsperren und dann mit einen langen oder passenden sha256hex key versehen.

Ich weiß nicht ob ich das korrekt verstehe aber meine alten SE Keys sind 64 zufällige Zeichen. Dürften also nicht unter die Kategorie unter 31 Zeichen fallen und er nimmt sie trotzdem nicht.

 

[gea]

Ich weiß nicht ob ich das korrekt verstehe aber meine alten SE Keys sind 64 zufällige Zeichen. Dürften also nicht unter die Kategorie unter 31 Zeichen fallen und er nimmt sie trotzdem nicht.

Waren die Keys in se passphrase?
Dann sollten sie funktionieren, wenn nicht müsste man das umstellen.

 

[Rach78]

ssdpool/123	encryption	aes-256-ccm	-
ssdpool/123	keylocation	prompt	local
ssdpool/123	keyformat	passphrase	-

Beitrag automatisch zusammengeführt: 07.09.2026

Wenn ich in CS versuche zu unlocken ist das Feld aber auch vorausgefüllt mit "prompt". Keine Ahnung ob das etwas zu sagen hat. Mein Key nimmt er jedenfalls nicht

Nachdem man den Key eingegeben hat und auf Bestätigen klickt kommt:

oops...​

error:: keylocation must be file:// (is: prompt)


back/ return to former menu



Die Datasets wurden damals auch über Nappit SE angelegt, also die WebUI

 

[gea]

es gibt eine neue .dev die enc datasets aus se öffnen sollte.

 

[Rach78]

Ja funktioniert. Allerdings tauchen die SMB Freigaben (von den entsperrten Datasets) bei mir erst dann auf wenn ich nach dem entsperren nochmal den SMB Server neustarte über die Webgui

 

[gea]

Das ist das Normalverhalten. Ich kann aber ein SMB restart nach unlock in napp-it 4ai/cs für Linux und OmniOS einbauen.

 

[Rach78]

Weiß nicht ob das notwendig ist, wenn dann konfugierbar. Weil ggf unterbricht ein Restart ja andere Filetransfers und da ist dann die Frage ob man das will

 

[gea]

Ein Restart des SMB Servers wird sonstige laufende Transfers abbrechen, ein automatisches Restart kann in der Tat problematisch sein. Ein Refresh/Reload wäre eine Option. Eigentlich sollten SMB Shares automatisch ohne SMB Server restart wieder zur Verfügung stehen.

Eine Unlock Funktion die mit jedem ZFS auf jedem OS mit jedem Client arbeitet, sollte aber vermutlich besser auf ein auto reload verzichten.

 

[Rach78]

Ja. Spielt für mich in der Praxis aber eh nicht so die Rolle weil beim Hochfahren des Servers die Datasets dann einfach automatisch entsperrt werden sollen und bleiben.
Ein Backup Server hat dann im Idealfall eh keinen Schlüssel, den er zum sichern ja eh nicht benötigt.
Man könnte beim manuellen Entsperren ggf ne Checkbox machen in dem Fenster die den SMB dann neustartet. Die kann man dann optional beim entsperren aktivieren bevor man auf okay drückt.

 

[gea]

Ja, sehe ich auch so, SMB restart allenfalls als Option beim Unlock