Hai. Ich würde gerne mein /home/ Verzeichnis (dass nicht auf einer seperaten Partition liegt) nachträglich verschlüsseln, da ich doch in letzter Zeit ein wenig Paranoid geworden bin. Möglichst so, dass die Passwortabfrage beim booten kommt. Wer weiß wies geht?
Das habe ich mir mal angesehen und gelöst.
Nachträglich verschlüsseln ist kein Problem!
Es setzt voraus, dass das /home in einer eigenen Partition liegt, was sowieso gute Sitte ist und leicht nachtraeglich zu erledigen ist.
Und dass man die Daten mind. 2x sichert, als Dateien und als Image usw., denn man muss (je nach freiem Platz auf einer Platte) die Originaldaten überschreiben. Beim Zurückkopieren darf nichts schief gehen. Zum Kopieren einschließlich Links und Sondertypen und Rechten und Datum und Besitzer mit tar gibt es gute Hinweise im Netz.
Abgrenzung:
Dies ist KEINE Anleitung zur völligen Verschlüsselung des ganzen Systems. Das geht anders. Hier werden einzelnen Partitionen (nachträglich) verschlüsselt.
Ganz am Schluss habe ich einen Hinweis beschrieben, wie man die kaputte Password-Eingabe überlistet:
Erstens timeout lang genug setzen und dann
WAEHREND des angezeigten checks 1x Enter druecken.
Danach irgendwann kommt die pwd.-Aufforderung.
Doof aber lösbar.
Grundsätzlich:
) Eine neue Partition bereitstellen (ggf. wiederverwendet)
) Partition konditionieren
) Den mount vorbereiten
) Die eingebauten Linux tools (crypttab, fstab) kuemmern sich um Entschlüsseln und mounten im richtigen Moment.
Hier mit der Abfrage des Passwords geloest. Aber Hinweis: Die Abfrage wird nicht korrekt angezeigt. Bugs dazu wurden reichlich geöffnet, man muss sich behelfen.
Ich habe das mit Ubuntu 17.10 u.a. auf verschiedenen Rechnern selbst ausprobiert. Ich berichte hier von realen Erfahrungen auf realen Maschinen, die ich für mich aufgeschrieben habe als Gedächtnisstütze (allerdings auf Englisch - dieses level dürfte niemanden überfordern).
Ubuntu 12.x bis 17.10 dürften bei LUKS gleich sein, hier wird der Kernel aber kein Graphik-Manager genutzt.
Beispiele sind
1 2 | ein mal generisch und ein mal ein ganz reales Beispiel |
Encrypt the home partition retroactively
very good reference: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch29s04.html
reference comprehensive: https://wiki.archlinux.org/index.php/Disk_encryption
Prepare
Create the partition / block device (parted, not so much gparted)
File system does not matter much; partition is device:
<device> = /dev/sda3
<name> = luks-56956....bfa1bc42
Set up a partition:
1 2 | (cryptsetup luksFormat <device> sudo cryptsetup luksFormat -s 192 -c twofish-ecb /dev/sda3 |
Verify it works:
1 2 | cryptsetup -v isLuks <device> sudo cryptsetup -v isLuks /dev/sda3 (shows "Command successful") |
See details about the encrypted device:
1 2 3 | cryptsetup luksDump <device> sudo cryptsetup luksDump /dev/sda3 |
This shows the device-name: The LUKS device's UUID.
Create a mapping to allow access to the device's decrypted contents
This makes the device accessible via mapping (a build in kernel function!)
1 2 3 | cryptsetup luksUUID <device> sudo cryptsetup luksUUID /dev/sda3 |
Create a name and make the mapping happen. To be used later in mounting
This asks for a name! Should be luks-<uuid>.
1 2 3 | cryptsetup luksOpen <device> <name> sudo cryptsetup luksOpen /dev/sda3 luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 |
Verify the mapping
1 2 | ls -latr /dev/mapper/ |
There should now be a device node, /dev/mapper/<name>, which represents the decrypted device. This block device can be read from and written to like any other unencrypted block device.
1 2 3 | dmsetup info <name> sudo dmsetup info luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 |
Format the device, create filesystems on the mapped device
1 2 3 | mke2fs /dev/mapper/<name> sudo mkfs.ext4 -v /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 |
Try to mount the new device in mapper as normal device
1 2 3 | make a mount point first mount /dev/mapper/<name> /mnt/test sudo mount /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 /mnt/gefieder/ |
mount result, manual:
1 | /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 on /mnt/gefieder type ext4 (rw,relatime,data=ordered) |
Crypttab
Make the device be decryptable and mapped at boot time before the fstab mounts with crypttab.
It is handled by OS without further installation of tools or so. None is for password / no keyfile.
1 2 3 4 5 | edit /etc/crypttab and enter <name> <device> none [most simple form.] # <target name> <source device> <key file> <options> luks-69fe88d8-00o0-9b76-qr20-f242a64a9320 UUID="69fe88d8-00o0-9b76-qr20-f242a64a9320" none luks,tries=5,timeout=300 |
Don't get confused: UUID is reliable while /dev/sda3 is NOT RELIABLE! Modern BIOS change to unexpected values!
"luks" -option implicitly defines several parameters, do not overdefine here.
see: https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#crypttab
Problems with Plymouth
?? Plymouth may swallow the password prompt, making a system boot impossible (complete encrypt only).
better not "silent" boot in grub!
fstab
Mount in fstab; use the decrypted device,
/dev/mapper/<name> in the /etc/fstab file
1 2 | /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 /home ext4 rw,users,defaults 0 2 |
Keys ^= password
Add a new passphrase to an existing device
1 2 | cryptsetup luksAddKey <device> sudo cryptsetup luksAddKey /dev/sda3 [asks for new password now] |
remove password:
1 2 3 | cryptsetup luksRemoveKey <device> sudo cryptsetup luksRemoveKey [valid password] |
Check / information / analyse / verify:
1 2 3 4 5 6 7 8 9 10 | sudo cryptsetup -v isLuks /dev/sda3 (it verifies the header!) sudo cryptsetup luksDump /dev/sda3 dmsetup info <name> look into //dev/mapper/ look into /etc/crypttab look into /etc/fstab maybe look at /etc/crypttab.initramfs |
e2fsck
run e2fsck on the /dev/mapper/<name>
1 | sudo e2fsck -cvf /dev/mapper/luks-595682c3-cb1f-4315-a20c-db20bfa1bc42 |
while it is not mounted.
The mapping is not a mount itself!
Password entry issue No luks password prompt - plymouth
Plymouth swallows the password request.
Reproducible, when you prematurely press "enter" during(!) the checking step the displayed lines shift up (and display an empty line). The password request becomes visible in this empty line after finalised checking procedure.
Reproducible you can try to guess when the request should be there, manually enter the matching password and the mounting goes on well.
So it is clearly a display issue caused by Plymouth.
Moderiert von sebix:
Leichenschändung von /home/ Verzeichnis nachträglich verschlüsseln abgetrennt. Bitte entführe keine Themen (Verhaltenscodex)!