ich möchte euch eigentlich nicht mit noch einem weiteren beitrag zum thema vollverschlüsselung langweilen, zumal es hier im forum eine sehr gute anleitung dazu gibt - allerdings bezogen auf btrfs und lvm und einer swapfile.
das klingt alles sehr reizvoll, ich bin mir aber nicht sicher, ob ich das wirklich möchte bzw benötige. darum also noch einmal von vorne
ich liebäugele also mit einer vollverschlüsselung von eos (uefi, gpt, ext4 ssd).
nun ist mein laptop nicht wirklich der neuste und dank meldown und spectre updates hat meine arme i5 ivy bridge sowieso schon arg gelitten. also die erste frage vorab:
lohnt sich der spaß mit vollverschlüsselung überhaupt, oder ist die leistungseinbuße danach eine katastrophe?
partinionieren würde ich vorab mit gparted oder partitionmanager, dann manuell mit calamares installieren (klappt das?).
zu /boot/efi habe ich vor langer zeit (glaube es war auf der refind seite) von einer minimalgröße gelesen, die nicht unterschritten werden sollte. es war ein kruder wert, glaube um die 775 mb. da platz nicht mehr die oberste priorität ist, habe ich 1024 mb dafür gewählt.
über die notwendigkeit von /boot in bezug auf eine vollverschlüsselung im jahr 2020 bin ich mir nicht wirklich sicher? man liest immer wieder, es sei ein relikt aus vergangenen tagen, wo diese unverschlüsselte partition absolut geboten war.
swap oder swapfile oder gar nicht? ich habe aus sentimentalität mal eine swap partition hinzugefügt, die aber wohl mehr als placebo dient, denn in aktion habe ich sie noch nie gesehen. ram sei dank.
habe ich noch etwas essentielles vergessen / gibt es noch etwas zu beachten?
Du kannst ohne extra /boot partition und wenn gewünscht auch mit seperater /home partition eos komplett verschlüsselt installieren. Ob mit swap und der option für hibernate ist dir überlassen, es kann auch nachträglich swap-file eingesetzt werden, dann ohne swap installieren und nachträglich swap-file konfigurieren.
Was die Systemgeschwindigkeit angeht sehe ich keinen großen Verlust an verschlüsselten Systemen.
Und wenn es sich um ein Notebook handelt das mobil ist kann eine Verschlüsselung schon zu deiner Sicherheit beitragen, bei Diebstahl z.B.
Dein i5 sollte keine performance Probleme mit der Verschlüsselung machen, ganz alte core2 Prozessoren mit nur 2 Kernen sind da etwas schwächer… ich habe ein altes Thinkpad mit 4GB Ram und einem schnellen Dualcore mit Vollverschlüsselung und das geht auch ohne große Einbußen.
dann werde ich definitiv auf /boot verzichten! habe momentan noch so ein layout, da mir das immer als grundbedingung für eine eventuelle (spätere) verschlüsselung im kopf herumgeisterte. alles relikte
swap partition vs datei, gibt es da unterschiede? falls datei, muß es dann zwingend auf /home sein? vielleicht mache ich bei root die 30gb voll und lege sie dann dort an. eigentlich benutze ich hibernate nicht - ist es von der swapgröße abhängig oder was eigenständiges?
gut das zu wissen, was die performance angeht. ich hatte irgendwo mal etwas von einbußen bis zu 30% auf älteren systemen, wahrscheinlich dann core2, gelesen.
noch etwas in sachen clonezilla:
beim wiederherstellen von luks2 verschlüsseltem /boot/efi und /root muß ich mir doch keine sorgen das passwort betreffend für das ebenfalls verschlüsselte /home machen, oder?
was ist, wenn man aus irgendeinem grund das backup nicht wiederherstellen kann, dann ist /home mit sicherheit verloren, sehe ich das richtig?
ach so, noch was grundlegendes: man wird dann immer im grub 1x nach einem passwort gefragt, das wars? du siehst, es ist echt das erste mal
genauso wie wenn du /home seperat hast und das backup nicht herstellen kannst…
Was du meinst ist sicher das wenn /home eine seperate Partition ist kannst du diese auch einfach einzeln wieder herstellen und entschlüsseln… das stimmt,
Backups sind nur dann sicher wenn es mehrere verschiedene varianten auf verschiedenen Festplatten – Speichern gibt.
wenn du nicht seperat verschlüsselst wird nur einmal vor dem Grub start nach dem Entschlüsselungspassword gefragt genau. Wenn ich mich richtig erinnere ist das auch so wenn das selbe Password für seperate Partitionen verwended wird habe ich jetzt aber nicht genau im Kopf.
Du solltest nur einmal gefragt werden. Das Passwort bzw. die Passwörter weiterer zu entschlüsselnden Partitionen, die du selbst gewählt hast, spielen allerdings keine Rolle. Diese kannst du durchaus variieren. Bei der Installation werden i. d. R. automatisch weitere Schlüssel (key files) zu deinen LUKS Partitionen hinzugefügt, damit dein System diese nach der ersten Entschlüsselung mit deinem Passwort ohne dein weiteres Hinzutun entschlüsseln und einhängen kann. Manuel einrichten ist aber auch kein Problem.
nicht ganz, wenn es unverschlüsselt ist, sind die daten ja noch abrufbar. wenn nun aber verschlüsselt…
natürlich sollte man immer auf backups bauen, aber in dem fall ist man trotz intakter daten ausgesperrt
klasse, da war ich mir nicht sicher. hatte gelesen, jede partition muß einzeln entsperrt werden. so wie du es beschreibst, kann man ja sogar mehrere passwörter einplanen.
noch etwas wichtiges:
bezieht sich nocheinmal auf einbußen, sollte aber dank ssd auch auf meinem system keine probleme machen.
wie sieht es mit aufnahmen & latenzen in audacity aus? hat da jemand erfahrungen mit einem ähnlichen rechner? clicks, aussetzter usw wären schon ein manko.
glaube zwar fest, das dies möglich ist: ab und zu überprüfe ich alle partitionen auf fehler mit gparted bzw partitionmanager im livemodus.
wie genau funktioniert das dann mit einem komplett verschlüsselten system? wird man beim zugriff auf die ssd bzw den partitionen vorab vom jeweiligen programm (also auch clonezilla etc) nach dem passwort gefragt und kann dann ganz normal fortfahren?
Du solltest beim Bootvorgang ein einziges Mal dein Passwort eingeben müssen, danach müssten alle weiteren Partitionen automatisch entschlüsselt werden.
Die Verschlüsselung ist absolut transparent, d. h. alle deine Programme funktionieren wie sonst auch; wie gesagt, du musst nur beim Start das System einmal freischalten.
Mach dir wegen Latenz und generellen Leistungsverlust keine Sorgen. Ich verschlüssele alle meine Geräte seit über einem Jahrzehnt stets “voll”. War damals schon auch auf schwächeren CPUs meist kein Problem und ist heute erst recht keines. Du wirst es höchstwahrscheinlich überhaupt nicht merken.
Die Erstinstallation ist zugegeben für Neuverschlüsseler eine “kleine” Hürde. Nicht wirklich schwer aber oft sind doch auch manuelle Schritte notwendig.
Einfachste Variante: Du kannst das System komplett mit Calamares (dem EOS Installer) verschlüsseln, hast dann aber keine getrennte /home Partition. Siehe Wiki.
Wenn es getrennte Partitionen sein sollen, kannst du unter anderem auf kleinschrittige Anweisungen hier im Forum zurückgreifen. Siehe BTRFSonLUKS oder LVMonLUKS
danke für den hinweis. schade, daß calamares+/home manuell noch nicht so weit ist.
ich hätte jetzt so begonnen wie in post1 (bzw wie von joe angedeutet)?
eine getrennte /home partition ist mir wichtig. bei einer sicherung bzw wiederherstellung möchte ich nicht immer die ganze platte auswählen müssen (nur sda1+2). home spiegel ich dann. eine swapfile lege ich vielleicht noch nachträglich in /root an.
die beiträge bin ich zuvor schon mal durchgegangen, verliere mich aber in den vielen details, die für mein “simples” vorhaben gar nicht relevant sind. vielleicht hast du ja noch ein, zwei gezielte tipps für mich?
ich habe mich nun für eine komplette neuinstallation inkl. neuer partitionierung & verschlüsselter /home partition via calamares entschieden. die installation verlief übrigens mit ventoy ohne probleme.
login funktioniert einwandfrei (1x passwortabfrage für sda3) und wird bei falschem passwort wiederholt.
mich macht diese einmalige systemfehlermeldung aber stutzig:
Failed to open key file.
Failed to activate with key file ‘/crypto_keyfile.bin’. (Key file missing?)
Eigentlich macht die Fehlermeldung nichts, weil Dein System ja funktioniert. Beseitigen würde ich sie trotzdem.
Schau, ob in Deinem /-Verzeichnis diese Datei liegt. Außerdem schau nach, ob in der Datei /etc/crypttab auf diese Datei verwiesen wird. Wenn die Datei nicht dort liegen sollte und in der Crypttab eine Zeile mit Verweis auf diese Datei drin sein sollte, dann kommentiere diese Zeile mit # in der Crypttab aus.
Aber Achtung! Ggf. startet danach Dein System doch nicht mehr. Du solltest Dir daher erst einen USB-Stick für ein Live-System zur Rettung bereitlegen und dann wissen, wie Du die auskommentierte Zeile in der Crypttab wieder aktivieren kannst.
Ups!
Bitte poste den Inhalt von /etc/crypttab und /etc/fstab
Vermutlich muss die Zeile in der Crypttab so angepasst werden, dass das Passwort im normalen Boot-Prozess abgefragt wird. @2000: Hast Du noch eine Idee, was da passiert sein kann?
fstab’s /dev/mapper/luks-xxx und crypttab’s luks-xxx sind identisch.
Summary
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=xxx /boot/efi vfat umask=0077 0 2
UUID=xxx / ext4 defaults,noatime 0 1
/dev/mapper/luks-xxx /home ext4 defaults,noatime 0 2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
#
# selbst eingetragen:
#
/swapfile none swap defaults 0 0
#
tmpfs /home/xxx/.cache tmpfs defaults,noatime,mode=1777 0 0
# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: Do not list your root (/) partition here, it must be set up
# beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
# to encrypted swap, which should be set up with mkinitcpio-openswap
# for resume support.
#
# <name> <device> <password> <options>
luks-xxx UUID=xxx /crypto_keyfile.bin luks
noch etwas - /boot/efi flags mußte ich trotz auswahl in calamares nach der installation händisch mit gparted von msftdata zu boot,esp ändern. warum auch immer?
Da du ja nur sda3 (/home) verschlüsselt hast, darf bzw. sollte /crypto_keyfile.bin auf keinen Fall auf sda2 existieren.
Diese Datei wird i. d. R. ja als Schlüssel generiert und auch in deiner verschlüsselten Partition als Schlüssel (Slot 1) eingetragen. Da sda2 allerdings unverschlüsselt ist, wäre es keine besonders gute Idee dort einen Schlüssel zu hinterlassen.
Du entsperrst sda3 beim Booten ganz normal mit deinem, beim Erstellen hinterlegtem, Passwort.
Wie der Eintrag in /etc/crypttab gelangt ist, ist allerdings ein Rätsel.
Versuch doch bitte noch einmal folgendes:
Auskommentieren in /etc/crypttab
Gefolgt von …
sudo mkinitcpio -p linux
sudo grub-mkconfig -o /boot/grub/grub.cfg
Neustart
Mit mkinitcpio -p linux erstellen wir ein neues Kernel-Image ohne Verweis auf die nicht existente Datei. Die Fehlermeldung müsste dann verschwinden.