staging.inyokaproject.org

Baustelle ist angelegt und damit auch eine neue Diskussion, damit die beiden Artikel zukünftig unabhängig diskutiert werden können.

Hi,

der Artikel ist vom Aufbau her fertig ueberarbeitet und zusammengefuehrt. Er mag an einigen Stellen etwas sprunghaft (im wahrsten Sinne 😀 ) sein, aber ich hoffe, dass nun die Redundanz minimiert wurde. Ausserdem bitte ich um Rueckmeldung, Verbesserungsvorschlaege, Kritik, Anpassungen in Forensyntax und Inhalt. Ich werde das getestet-Tag entsprechend meinen Tests dann im Verlauf der naechsten Tage anpassen.

Gruss Lasall

Oha, da hast Du ja schon einiges an Arbeit reingesteckt - bitte entschuldige, dass ich mir erst jetzt den Artikel anschauen kann. Beseitigung von Redundanz ist immer eine noble Aufgabe im Wiki, danke dass Du Dich der annimmst. ☺

Im Wiki werden grundlegende Themen in Grundlagenartikeln aufbereitet, die dann in konkreten Anleitungen über die Wissens-Box referenziert werden. In diesem Fall sollten also eher schwierig zu pflegende Detail-Informationen aus dem Artikel entfernt (und so nötig, in den Grundlagenartikel ausgelagert) werden. Deshalb wurden die ganzen Informationen rund um LUKS auch aus den einzelnen Crypto-Anleitungen herausgenommen. ☹

Ich sehe einige gute Verbesserungen im Artikel, gerade was die Wissen-Box-Referenzen angeht - meinst Du, Du kannst diese auch so einpflegen?

Hi RvD,

heisst das ein Rollback wieder auf die zwei Artikel, der eine Grundlagen, der andere Anleitung ☹ ?

Gruss Lasall

Ich habe mir das noch etwas angeschaut und überlegt - so eine wirkliche Alternative sehe ich leider nicht. ☹

Einfach nur die Teile, ohne die Verbesserungen zurückzusetzen ist nicht möglich.

Hi,

soll ich das dann so machen, dass in die (Grundlagen)-Artikel (LUKS allg., Schluesselableitung, formatieren, ...) immer verlinkt wird oder aber eine exakte Anleitung (wie vorher schon)?

Gruss Lasall

Ich habe mal das Rollback gemacht. ☺

Als ersten Schritt würde ich vorschlagen, dass Du den Artikel einfach einmal auf den neusten Stand, gerade von den Versionen her bringst. Anschließen wäre es toll, wen Du Deine Detail-Verbesserungen einbringst.

Hi,

tut mir Leid, ich habe wegen Zeitgruenden den Artikel nun unveraendert aus der Baustelle wieder ins Wiki verschoben.

Gruss Lasall

Servus,

ich habe gerade eine Mail:

Hallo Wiki-Team,

sonst sind die Anleitungen von euch stets bestens, fehlerfrei, detailreich und bringen auch Anfänger an's Ziel. Bei dem Artikel hier hab ich evtl. nen Fehler entdeckt: http://wiki.ubuntuusers.de/System_verschlüsseln/Schlüsselableitung

Und zwar geht's um den Schritt: chroot /mnt /bin/bash Da bekomm ich die Fehlermeldung file or directory not found. Bitte probiert die Anleitung selbst mal aus, bei mir jedenfalls hat's schon zweimal nicht geklappt, obwohö /bin/bash logischerweise existiert hat. Naja sorry, dass ich nicht mehr beitragen kann, aber ich kann den Fehler nur melden, ne Lösung hab ich leider nicht.

Mehr Infos habe ich auch nicht 😐

MarkusH.

Btrfs ist ja noch kein Standard, bietet sich aber als 3. Lösung zwischen LVM und der hier starren Methode an.

Als Reminder, wenn BTRFS stabil ist und ins wiki darf:

# Format mit BTRFS statt ext4
mkfs.btrfs --label "root" /dev/mapper/root
...
# Ins verschlüsselte System wechseln
mount /dev/mapper/root /mnt -o subvol=@
mount /dev/mapper/root /mnt/home -o subvol=@home
...

Dabei wurde berücksichtigt, dass Ubuntu beim installieren auf BTRFS automatisch Subvolumes anlegt.

Viele Grüße u1000

Neuer Abschnitt: == Workaround Ubuntu 15.04 und systemd ==

Hinsichtlich systemd und dem Öffnen mehrerer mit LUKS verschlüsselter Partitionen ohne LVM sind wir zu folgenden Ergebnis unter Xenial Xerus (LTS 16.04) gekommen:

• Einträge in der /etc/crypttab:

  • home PARTUUID=3c68e7d7-ba9d-42c5-a3f5-3219351c74c7 none luks
    root PARTUUID=f28dbdd4-fdab-4ba1-b326-f10d27a0c317 none luks
    swap PARTUUID=8c806a2d-5779-40db-a256-09a4d373f410 none luks

Wichtig dabei

• Die Bezeichnung aus /dev/mapper/ - im Beispiel

• home, root und swap

sollten in der /etc/crypttab

• in alphabetischer Reihenfolge eingetragen sein

• es ist kein Bezug einzutragen, das "keyscript=" kann entfallen

• die Passphrasen für alle Partitionen sind identisch

  • ggf. über luksAddKey anpassen

Damit lässt sich dann obige Kombination mit einer einzigen Abfrage öffnen. Ausgelöst wird das dann durch den Eintrag in der

• /grub/grub.cfg der Boot-Partition

  • linux	/vmlinuz-4.4.0-18-generic.efi.signed root=/dev/mapper/root ro  quiet splash $vt_handoff

Alternativ kann man auf Notebooks die Swap auch so aufbereiten, das damit der Modus

• suspend to disk

sichergestellt wird - dann die Partition normal als Swap formatieren und in der /etc/crypttab eintragen:

• swap PARTUUID=08e8c77b-a330-4038-b30e-b7c2bda601a6 /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256

Auch haben wir bei der Erstellung der Partitionen und dem Anlegen der Passphrase etwas andere (vereinfachte) Wege beschritten. Ergebnis:

ls /dev/mapper 

• control  home  root swap

Wir bitten alle, die eine vergleichbare Installation haben bzw. anlegen wollen, diese Hinweise zu überprüfen - erst danach werden wir diesen Artikel, sofern erwünscht überarbeiten.

gruß syscon-hh

Ich habe gerade die Anleitung zur Installation von Xenial Xerus (LTS 16.04) getestet. Funktioniert soweit alles wunderbar, bei Systemen die noch mit BIOS laufen muss man für den Swap allerdings statt der PARTUUID /dev/disk/by-id oder /dev/disk/by-path verwenden.

Der Anleitung von syscon-hh konnte ich leider nicht folgen. Ist es möglich diese etwas detaillierter auszuführen?

Ich habe eure letzten Ergebnisse (vor einiger Zeit) verlinkt, aber um eine bessere Methode ergänzt, weil sie auch die von euch geforderten unterschiedlichen Passworte/ Schlüssel ermöglicht:

Vergleich

Selbst getestet - übrigens (relevant nur für die Verfolger der Diskussion durch Suchmaschinen, wodurch ich auch wieder hier landete) in einem Dualboot mit zwei komplett verschlüsselten Systemen für je eine andere Personen, aber wegen begrenztem LTS-Internetvolumen/ begrenzter Downloadgeschwindigkeit/ grundsätzlich (doppelter) benötigter Downloadzeit daher mit gemeinsam benutztem apt-cache (/var/cache/apt/archives) in jeder fstab für die Aktualisierungen beider Systeme. Falls es da Probleme gibt - noch keine Kurz- oder gar Langzeiterfahrungen!

Jedes System kann die LUKS-Partition entschlüsseln, zusätzlich bekam sie ein optionales weiteres LUKS-Passwort (keyslot), welches nur von System 2 aus geöffnet werden kann. Nutzer von System 1 hat keine sudo-Rechte - und keinen Key. Somit sind Manipulationen von Updates via Live-CD etc. ausgeschlossen. Es wird nur automatisch entsperrt, aber dann sind die Standardrechte auf Lesen statt Schreiben gesetzt - auch hier kann Nutzer 1 schwer aus seinem goldenen Käfig ausbrechen, um evtl. Nutzer 2 zu kompromittieren oder durch eigene Fehler in Mitleidenschaft zu ziehen.

Die Pakete selbst werden ja signiert (sicher) heruntergeladen und dann beim Entpacken nochmals auf Defekte geprüft, falls bei Nutzer 1 die Aktualisierung mal unterbrochen wurde. Auf die Wartezeit bei Nutzer 1 durch einen automatischen chroot/Live-CD (ohne CD, aber Hinweise beachten) mit automatischem Anwenden der Aktualisierungen habe ich verzichtet - wäre ja auch ohne Entschlüsseln nicht möglich. Die Löschfrist des apt-Caches von 30 Tagen wird noch heraufgesetzt, wie es benötigt wird.

Hätte ich die Hinweise hier komplett eher gesehen, hätte ich mir für mich meine Tests und vorherige Fehler teils sparen können, allerdings kam bei der englischen Suche gleich das englische Wiki zu ZFS, wo ich diese wertvollen Infos extrahieren und testen konnte. So konnte ich wieder einige Erfahrungen sammeln und wollte euch daran teilhaben lassen und mir ein späteres Wiederfinden ermöglichen, auch wenn die Edits der ganzen Artikelserie nun schon wieder knapp 2h andauern. Kleinvieh und Vernetzen macht auch viel Mist. Inhaltlich ist es nicht viel. Hab da mal bisschen, wie im Link in der Beschreibung + in den Farben ersichtlich, aufgeräumt.

rumo453 schrieb:

Der Anleitung von syscon-hh konnte ich leider nicht folgen. Ist es möglich diese etwas detaillierter auszuführen?

Ist doch eigentlich vollständig, wenn du sudo, Editor, ls sowie die Datei /etc/default/grub für die genannte Bootoption (in Vertretung für die genannte'grub.cfg) kennst - fehlt noch was?

Hoffe, euch geholfen zu haben. Ich hab auch genug gelernt und Zeit verbraten. Gerade dann, wenn es mal nicht nach Plan läuft oder sich viele kleine Dinge zu suboptimalen, unbrauchbaren Ergebnissen verketten.

Grüße, Benno

Im Abschnitt https://wiki.ubuntuusers.de/System_verschl%C3%BCsseln/Schl%C3%BCsselableitung/#Verschluesselung-der-Partitionen führt der beschriebene Befehl

/lib/cryptsetup/scripts/decrypt_derived root | cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/sdX2 

mit der Fehlermeldung

Kann die Passphrase-Verifikation nur auf Terminal-Eingaben durchführen.

quittiert.