pages tagged luksFeeding the Cloudhttps://feeding.cloud.geek.nz/tags/luks/Feeding the Cloudikiwiki2023-09-10T04:07:18ZMaking the mounting of an encrypted /home optional on a home serverhttps://feeding.cloud.geek.nz/posts/optional-encrypted-root-on-home-server/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2022-10-29T06:45:39Z2022-10-29T06:45:00Z
<p>I have a computer that serves as a home server as well as a desktop
machine. It has an encrypted home directory to protect user files and, in
the default configuration, that unfortunately interferes with unattended
reboots since someone needs to be present to enter the encryption password.</p>
<p>Here's how I added a timeout and made <code>/home</code> optional on that machine.</p>
<p>I started by adding a one-minute timeout on the password prompt by adding
<code>timeout=60</code> in my <code>/etc/crypttab</code>:</p>
<pre><code>crypt UUID=7e12c123-abcd-5555-8c40-900d1f8cc281 none luks,timeout=60
</code></pre>
<p>then I made <code>/home</code> optional by adding <code>nofail</code> to the appropriate mount
point in <code>/etc/fstab</code>:</p>
<pre><code>/dev/mapper/crypt /home ext4 nodev,noatime,nosuid,nofail 0 2
</code></pre>
<p>Before that, the password prompt would timeout but the system would be
unable to boot since one of the required partitions had failed to mount.</p>
<p>Now, to ensure that I don't accidentally re-create home directories for
users when the system is mounted without a <code>/home</code>, I made the <code>/home</code>
directory on the non-encrypted drive read-only:</p>
<pre><code>umount /home
cd /home
chmod a-w .
</code></pre>
<p>Finally, with all of this in place, I was now happy to configure the
machine to automatically reboot after a kernel panic by putting the
following in <code>/etc/sysctl.d/local.conf</code>:</p>
<pre><code># Automatic reboot 10 seconds after a kernel panic
kernel.panic = 10
</code></pre>
<p>since I know that the machine will come back up just fine and that all
services will be running. I simply won't be able to log into that machine as
any other user than <code>root</code> until I manually unlock and mount <code>/home</code>.</p>
Erasing Persistent Storage Securely on Linuxhttps://feeding.cloud.geek.nz/posts/erasing-persistent-storage-securely/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2023-01-14T04:10:33Z2019-01-08T16:55:00Z
<p>Here are some notes on how to securely delete computer data in a way that
makes it impractical for anybody to recover that data. This is an important
thing to do before giving away (or throwing away) old disks.</p>
<p>Ideally though, it's better not to have to rely on secure erasure and start
use full-disk encryption right from the start, for example, using
<a href="https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup">LUKS</a>. That way if the secure deletion fails for whatever reason, or
can't be performed (e.g. the drive is dead), then it's not a big deal.</p>
<h1 id="Rotating_hard_drives">Rotating hard drives</h1>
<p>With ATA or SCSI hard drives, <a href="https://sourceforge.net/projects/dban/">DBAN</a>
seems to be the ideal solution.</p>
<ol>
<li>Burn it on CD,</li>
<li>boot with it,</li>
<li>and following the instructions.</li>
</ol>
<p>Note that you should <strong>disconnect any drives you don't want to erase</strong>
before booting with that CD.</p>
<p>This is probably the most trustworth method of wiping since it uses free and
open source software to write to each sector of the drive several times. The
methods that follow rely on proprietary software built into the
firmware of the devices and so you have to trust that it is implemented
properly and not backdoored.</p>
<h1 id="ATA_.2F_SATA_solid-state_drives">ATA / SATA solid-state drives</h1>
<p>Due to the nature of solid-state storage (i.e. the lifetime number of writes
is limited), it's not a good idea to use DBAN for those. Instead, we must
rely on the vendor's implementation of <a href="https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase">ATA Secure
Erase</a>.</p>
<p>First, set a password on the drive:</p>
<pre><code>hdparm --user-master u --security-set-pass p /dev/sdX
</code></pre>
<p>and then issue a Secure Erase command:</p>
<pre><code>hdparm --user-master u --security-erase-enhanced p /dev/sdX
</code></pre>
<p>If you get errors like "bad/missing sense data", then you may need to
use one of the tricks <a href="https://superuser.com/questions/1213715/hdparm-error-sg-io-bad-missing-sense-data">described in this thread</a>. For me, suspending the laptop
and then waking it up did the trick.</p>
<h1 id="NVMe_solid-state_drives">NVMe solid-state drives</h1>
<p>For SSDs using an NVMe connector, simply request a <a href="https://www.mankier.com/1/nvme-format">User Data
Erase</a></p>
<pre><code>nvme format -s1 /dev/nvme0n1
</code></pre>
Recovering from an unbootable Ubuntu encrypted LVM root partitionhttps://feeding.cloud.geek.nz/posts/recovering-from-unbootable-ubuntu-encrypted-lvm-root-partition/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2021-06-11T20:43:57Z2017-05-16T04:10:00Z
<p>A laptop that was installed using the default Ubuntu 16.10 (xenial)
<a href="https://www.eff.org/deeplinks/2012/11/privacy-ubuntu-1210-full-disk-encryption">full-disk encryption</a>
option stopped booting after receiving a
kernel update somewhere on the way to Ubuntu 17.04 (zesty).</p>
<p>After showing the boot screen for about 30 seconds, a busybox shell pops up:</p>
<pre><code>BusyBox v.1.21.1 (Ubuntu 1:1.21.1-1ubuntu1) built-in shell (ash)
Enter 'help' for list of built-in commands.
(initramfs)
</code></pre>
<p>Typing <code>exit</code> will display more information about the failure before
bringing us back to the same busybox shell:</p>
<pre><code>Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/ubuntu--vg-root does not exist. Dropping to a shell!
BusyBox v.1.21.1 (Ubuntu 1:1.21.1-1ubuntu1) built-in shell (ash)
Enter 'help' for list of built-in commands.
(initramfs)
</code></pre>
<p>which now complains that the <code>/dev/mapper/ubuntu--vg-root</code> root partition
(which uses
<a href="https://gitlab.com/cryptsetup/cryptsetup/blob/master/README.md">LUKS</a> and
<a href="https://www.sourceware.org/lvm2/">LVM</a>) cannot be found.</p>
<p>There is some <a href="https://askubuntu.com/questions/567730/gave-up-waiting-for-root-device-ubuntu-vg-root-doesnt-exist#567897">comprehensive advice out there</a>
but it didn't quite work for me. This is how I ended up resolving the problem.</p>
<h1 id="Boot_using_a_USB_installation_disk">Boot using a USB installation disk</h1>
<p>First, create bootable USB disk using the latest Ubuntu installer:</p>
<ol>
<li><a href="https://www.ubuntu.com/download/desktop">Download an desktop image</a>.</li>
<li><p>Copy the ISO directly on the USB stick (overwriting it in the process):</p>
<pre><code> dd if=ubuntu.iso of=/dev/sdc1
</code></pre></li>
</ol>
<p>and boot the system using that USB stick (<a href="https://support.apple.com/en-us/HT201255">hold the <code>option</code> key during boot on Apple hardware</a>).</p>
<h1 id="Mount_the_encrypted_partition">Mount the encrypted partition</h1>
<p>Assuming a drive which is partitioned this way:</p>
<ul>
<li><code>/dev/sda1</code>: EFI partition</li>
<li><code>/dev/sda2</code>: unencrypted boot partition</li>
<li><code>/dev/sda3</code>: encrypted LVM partition</li>
</ul>
<p>Open a terminal and <a href="https://superuser.com/questions/165116/mount-dev-proc-sys-in-a-chroot-environment">mount the required partitions</a>:</p>
<pre><code>cryptsetup luksOpen /dev/sda3 sda3_crypt
vgchange -ay
mount /dev/mapper/ubuntu--vg-root /mnt
mount /dev/sda2 /mnt/boot
mount -t proc proc /mnt/proc
mount -o bind /dev /mnt/dev
</code></pre>
<p>Note:</p>
<ul>
<li><p>When running <code>cryptsetup luksOpen</code>, you must use the same name as the one
that is in <code>/etc/crypttab</code> on the root parition (<code>sda3_crypt</code> in this
example).</p></li>
<li><p>All of these partitions must be present (<strong>including <code>/proc</code> and <code>/dev</code></strong>) for
the initramfs scripts to do all of their work. If you see errors or
warnings, you must resolve them.</p></li>
</ul>
<h1 id="Regenerate_the_initramfs_on_the_boot_partition">Regenerate the initramfs on the boot partition</h1>
<p>Then "enter" the root partition using:</p>
<pre><code>chroot /mnt
</code></pre>
<p>and make sure that you have the necessary packages installed:</p>
<pre><code>apt install lvm2 cryptsetup-initramfs
</code></pre>
<p>before regenerating the initramfs for all of the installed kernels:</p>
<pre><code>update-initramfs -c -k all
</code></pre>
Manually expanding a RAID1 array on Ubuntuhttps://feeding.cloud.geek.nz/posts/manually-expanding-raid1-array-ubuntu/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2021-06-11T20:43:57Z2017-04-01T06:00:00Z
<p>Here are the notes I took while manually expanding an non-LVM encrypted
RAID1 array on an Ubuntu machine.</p>
<p>My original setup consisted of a 1 TB drive along with a 2 TB drive, which
meant that the RAID1 array was 1 TB in size and the second drive had 1 TB of
unused capacity. This is how I replaced the old 1 TB drive with a new 3 TB
drive and expanded the RAID1 array to 2 TB (leaving 1 TB unused on the new 3
TB drive).</p>
<h1 id="Partition_the_new_drive">Partition the new drive</h1>
<p>In order to partition the new 3 TB drive, I started by creating a
<strong>temporary partition</strong> on the old 2 TB drive (<code>/dev/sdc</code>) to use up all of
the capacity on that drive:</p>
<pre><code>$ parted /dev/sdc
unit s
print
mkpart
print
</code></pre>
<p>Then I initialized the partition table and creating the EFI partition
partition on the new drive (<code>/dev/sdd</code>):</p>
<pre><code>$ parted /dev/sdd
unit s
mktable gpt
mkpart
</code></pre>
<p>Since I want to have the RAID1 array be as large as the smaller of the two
drives, I made sure that the second partition (<code>/home</code>) on the
new 3 TB drive had:</p>
<ul>
<li>the same <strong>start position</strong> as the second partition on the old drive</li>
<li>the <strong>end position</strong> of the third partition (the temporary one I just
created) on the old drive</li>
</ul>
<p>I created the partition and flagged it as a RAID one:</p>
<pre><code>mkpart
toggle 2 raid
</code></pre>
<p>and then deleted the temporary partition on the old 2 TB drive:</p>
<pre><code>$ parted /dev/sdc
print
rm 3
print
</code></pre>
<h1 id="Create_a_temporary_RAID1_array_on_the_new_drive">Create a temporary RAID1 array on the new drive</h1>
<p>With the new drive properly partitioned, I created a new RAID array for it:</p>
<pre><code>mdadm /dev/md10 --create --level=1 --raid-devices=2 /dev/sdd1 missing
</code></pre>
<p>and added it to <code>/etc/mdadm/mdadm.conf</code>:</p>
<pre><code>mdadm --detail --scan >> /etc/mdadm/mdadm.conf
</code></pre>
<p>which required manual editing of that file to remove duplicate entries.</p>
<h1 id="Create_the_encrypted_partition">Create the encrypted partition</h1>
<p>With the new RAID device in place, I created the encrypted LUKS partition:</p>
<pre><code>cryptsetup -h sha256 -c aes-xts-plain64 -s 512 luksFormat /dev/md10
cryptsetup luksOpen /dev/md10 chome2
</code></pre>
<p>I took the UUID for the temporary RAID partition:</p>
<pre><code>blkid /dev/md10
</code></pre>
<p>and put it in <code>/etc/crypttab</code> as <code>chome2</code>.</p>
<p>Then, I formatted the new LUKS partition and mounted it:</p>
<pre><code>mkfs.ext4 -m 0 /dev/mapper/chome2
mkdir /home2
mount /dev/mapper/chome2 /home2
</code></pre>
<h1 id="Copy_the_data_from_the_old_drive">Copy the data from the old drive</h1>
<p>With the home paritions of both drives mounted, I copied the files over to
the new drive:</p>
<pre><code>eatmydata nice ionice -c3 rsync -axHAX --progress /home/* /home2/
</code></pre>
<p>making use of
<a href="https://feeding.cloud.geek.nz/posts/three-wrappers-to-run-commands-without-impacting-the-rest-of-the-system/">wrappers that preserve system reponsiveness</a>
during I/O-intensive operations.</p>
<h1 id="Switch_over_to_the_new_drive">Switch over to the new drive</h1>
<p>After the copy, I switched over to the new drive in a step-by-step way:</p>
<ol>
<li>Changed the UUID of <code>chome</code> in <code>/etc/crypttab</code>.</li>
<li>Changed the UUID and name of <code>/dev/md1</code> in <code>/etc/mdadm/mdadm.conf</code>.</li>
<li>Rebooted with both drives.</li>
<li>Checked that the new drive was the one used in the encrypted <code>/home</code> mount using: <code>df -h</code>.</li>
</ol>
<h1 id="Add_the_old_drive_to_the_new_RAID_array">Add the old drive to the new RAID array</h1>
<p>With all of this working, it was time to clear the mdadm superblock from the
old drive:</p>
<pre><code>mdadm --zero-superblock /dev/sdc1
</code></pre>
<p>and then change the second partition of the old drive to make it the same
size as the one on the new drive:</p>
<pre><code>$ parted /dev/sdc
rm 2
mkpart
toggle 2 raid
print
</code></pre>
<p>before adding it to the new array:</p>
<pre><code>mdadm /dev/md1 -a /dev/sdc1
</code></pre>
<h1 id="Rename_the_new_array">Rename the new array</h1>
<p>To
<a href="https://askubuntu.com/questions/63980/how-do-i-rename-an-mdadm-raid-array#64356">change the name of the new RAID array</a>
back to what it was on the old drive, I first had to stop both the old and
the new RAID arrays:</p>
<pre><code>umount /home
cryptsetup luksClose chome
mdadm --stop /dev/md10
mdadm --stop /dev/md1
</code></pre>
<p>before running this command:</p>
<pre><code>mdadm --assemble /dev/md1 --name=mymachinename:1 --update=name /dev/sdd2
</code></pre>
<p>and updating the name in <code>/etc/mdadm/mdadm.conf</code>.</p>
<p>The last step was to regenerate the initramfs:</p>
<pre><code>update-initramfs -u
</code></pre>
<p>before rebooting into something that looks exactly like the original RAID1
array but with twice the size.</p>
Poor man's RAID1 between an SSD and a hard drivehttps://feeding.cloud.geek.nz/posts/poor-mans-raid1-between-ssd-and-hard-drive/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2023-03-01T17:26:39Z2013-03-31T03:20:00Z
<p>After
<a href="https://feeding.cloud.geek.nz/posts/doing_a_fresh_debian_ubuntu_install_without_having_to_reconfigure_everything/">moving from a hard drive to an SSD</a>
on my work laptop, I decided to keep the hard drive spinning and use it as a
backup for the SSD.</p>
<p>With the following setup, I can pull the SSD out of my laptop and it should
still boot up normally with all of my data on the hard drive.</p>
<h1 id="Manually_setting_up_an_encrypted_root_partition">Manually setting up an encrypted root partition</h1>
<p>Before setting up the synchronization between the two drives, I had to
replicate the partition setup.</p>
<p>I used <code>fdisk</code>, <code>cfdisk</code> and <code>gparted</code> to create the following partitions:</p>
<pre><code> Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 499711 248832 83 Linux
/dev/sdb2 501760 500117503 249807872 5 Extended
/dev/sdb5 503808 500117503 249806848 83 Linux
</code></pre>
<p>and then loosely followed
<a href="http://linux.derkeiler.com/Mailing-Lists/Debian/2007-08/msg01240.html">these instructions</a>
to create an encrypted root partition on <code>/dev/sdb5</code>:</p>
<pre><code>$ cryptsetup luksFormat /dev/sdb5
$ cryptsetup luksOpen /dev/sdb5 sdb5_crypt
$ pvcreate /dev/mapper/sdb5_crypt
$ vgcreate akranes2 /dev/mapper/sdb5_crypt
$ vgchange -a y akranes2
$ lvcreate -L247329718272B -nroot akranes2
$ lvcreate -L8468299776B -nswap_1 akranes2
$ mkfs.ext4 -m1 /dev/akranes2/root
</code></pre>
<p>Finally, I added the new encrypted partition to the list of drives to bring up
at boot time by looking up its UUID:</p>
<pre><code>$ cryptsetup luksUUID /dev/sdb5
</code></pre>
<p>and creating a new entry for it in <code>/etc/crypttab</code>.</p>
<h1 id="Copying_the_boot_partition">Copying the boot partition</h1>
<p>Setting up the boot partition was much easier because it's not
encrypted. All that was needed was to format it and then copy the files
over:</p>
<pre><code>$ mkfs.ext2 /dev/sdb1
$ mount /dev/sdb1 /mnt/boot
$ cp -a /boot/* /mnt/boot/
</code></pre>
<p>The only other thing to remember is to install grub on the boot loader of
that drive. On modern Debian systems, that's usually just a matter of
running <code>dpkg-reconfigure grub-pc</code> and adding the second drive (<code>/dev/sdb</code>
in my case) to the list of drives to install grub on.</p>
<h1 id="Sync_scripts">Sync scripts</h1>
<p>To keep the contents of the SSD and the hard drive in sync, I set up a
regular rsync of the root and boot partitions using the following mount
points (as defined in <code>/etc/fstab</code>):</p>
<pre><code>/dev/mapper/akranes-root / ext4 noatime,discard,errors=remount-ro 0 1
/dev/mapper/akranes2-root /mnt/root ext4 noatime,errors=remount-ro,nofail 0 2
UUID=0b9109d0-... /boot ext2 defaults 0 2
UUID=6e6f05fb-... /mnt/boot ext2 defaults,nofail 0 2
</code></pre>
<p>I use this script (<code>/usr/local/sbin/ssd_boot_backup</code>) for syncing the boot
partition:</p>
<pre><code>#!/bin/sh
if [ ! -e /mnt/boot/hdd.mounted ] ; then
echo "The rotating hard drive is not mounted in /mnt/boot."
exit 1
fi
if [ ! -e /boot/ssd.mounted ] ; then
echo "The ssd is not the boot partition"
exit 1
fi
nocache nice ionice -c3 rsync -aHx --inplace --delete --exclude=/boot/ssd.mounted --exclude=/boot/hdd.mounted --exclude=/boot/lost+found/* /boot /mnt/
</code></pre>
<p>and a similar one (<code>/usr/local/sbin/ssd_root_backup</code>) for the root
partition:</p>
<pre><code>#!/bin/sh
if [ ! -e /mnt/root/hdd.mounted ] ; then
echo "The rotating hard drive is not mounted in /mnt/root."
exit 1
fi
if [ ! -e /ssd.mounted ] ; then
echo "The ssd is not the root partition"
exit 1
fi
nocache nice ionice -c3 rsync -aHx --delete --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/boot/* --exclude=/mnt/* --exclude=/lost+found/* --exclude=/media/* --exclude=/run/* --exclude=/scratch/* --exclude=/var/tmp/* --exclude=/ssd.mounted --exclude=/var/lock/* /* /mnt/root/
</code></pre>
<p>To ensure that each drive is properly mounted before the scripts run, I
created empty <code>ssd.mounted</code> files in the root directory of each of the
partitions on the SSD, and empty <code>hdd.mounted</code> files in the root directory
of the hard drive partitions.</p>
<p>Note that the boot partition <code>rsync</code> command uses the <code>--inplace</code> option.
That's to prevent <code>No space left on device</code> errors on due to the temporary
file copying (the <code>rsync</code> default mode of operation) on small partitions.</p>
<h1 id="Cron_jobs">Cron jobs</h1>
<p>The sync scripts are run every couple of hours through this crontab:</p>
<pre><code>10 */4 * * * root /usr/local/sbin/ssd_boot_backup
20 0,4,8,12,16,20 * * * root /usr/local/sbin/ssd_root_backup
20 2,6,10,14,18,22 * * * root /usr/bin/on_ac_power && /usr/local/sbin/ssd_root_backup
</code></pre>
<p>which includes a reduced frequency while running on battery to avoid
spinning the hard drive up too much.</p>
Encrypted system backup to DVDhttps://feeding.cloud.geek.nz/posts/encrypted-system-backup-to-dvd/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2023-09-10T04:07:18Z2011-04-02T23:30:00Z
<p>Inspired by <a href="http://worldbackupday.net/">World Backup Day</a>, I decided to take a backup of my laptop. Thanks to using a <a href="http://www.debian.org/">free operating system</a> I don't have to backup any of my software, just configuration and data files, which fit on a single DVD.</p>
<p>In order to avoid worrying too much about secure storage and disposal of these backups, I have decided to encrypt them using a standard <a href="https://feeding.cloud.geek.nz/2008/04/two-tier-encryption-strategy-archiving.html">encrypted loopback filesystem</a>.</p>
<p>(Feel free to leave a comment if you can suggest an easier way of doing this.)</p>
<h3 id="Cryptmount_setup">Cryptmount setup</h3>
<p>Install <a href="http://cryptmount.sourceforge.net/">cryptmount</a>:</p>
<pre><code>apt-get install cryptmount
</code></pre>
<p>and setup two encrypted mount points in <code>/etc/cryptmount/cmtab</code>:</p>
<pre><code>backup {
dev=/backup.dat
dir=/backup
fstype=ext4
mountoptions=defaults,noatime
keyfile=/backup.key
keyhash=sha512
keycipher=aes-xts-plain64
keyformat=builtin
cipher=aes-xts-plain64
}
testbackup {
dev=/media/cdrom/backup.dat
dir=/backup
fstype=ext4
mountoptions=defaults,noatime,ro,noload
keyfile=/media/cdrom/backup.key
keyhash=sha512
keycipher=aes-xts-plain64
keyformat=builtin
cipher=aes-xts-plain64
}
</code></pre>
<h3 id="Initialize_the_encrypted_filesystem">Initialize the encrypted filesystem</h3>
<p>Make sure you have at least 4.3 GB of free disk space on <code>/</code> and then run:</p>
<pre><code>mkdir /backup
dd if=/dev/zero of=/backup.dat bs=1M count=4096
cryptmount --generate-key 32 backup
cryptmount --prepare backup
mkfs.ext4 -m 0 /dev/mapper/backup
cryptmount --release backup
</code></pre>
<p>Alternatively, if you're using a double-layer DVD then use this <code>dd</code> line:</p>
<pre><code>dd if=/dev/zero of=/backup.dat bs=1M count=8000
</code></pre>
<h3 id="Burn_the_data_to_a_DVD">Burn the data to a DVD</h3>
<p>Mount the newly created partition:</p>
<pre><code>cryptmount backup
</code></pre>
<p>and then copy the files you want to <code>/backup/</code> before unmounting that partition:</p>
<pre><code>cryptmount -u backup
</code></pre>
<p>Finally, use your favourite DVD-burning program to burn these files:</p>
<ul>
<li><code>/backup.dat</code></li>
<li><code>/backup.key</code></li>
<li><code>/etc/cryptmount/cmtab</code></li>
</ul>
<h3 id="Test_your_backup">Test your backup</h3>
<p>Before deleting these two files, test the DVD you've just burned by mounting it:</p>
<pre><code>mount /cdrom
cryptmount testbackup
</code></pre>
<p>and looking at a random sampling of the files contained in <code>/backup</code>.</p>
<p>Once you are satisfied that your backup is fine, umount the DVD:</p>
<pre><code>cryptmount -u testbackup
umount /cdrom
</code></pre>
<p>and remove the temporary files:</p>
<pre><code>rm /backup.dat /backup.key
</code></pre>
Encrypting your home directory using LUKS on Debian/Ubuntuhttps://feeding.cloud.geek.nz/posts/encrypting-your-home-directory-using/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2021-06-11T20:43:57Z2008-05-24T07:47:00Z
<p>Laptops are easily lost or stolen and in order to protect your emails, web passwords, encryption keys, etc., you should really think about encrypting (at least) your home directory.</p>
<p>If you happen to have <code>/home</code> on a separate partition already (<code>/dev/sda5</code> in this example), then it's a really easy process.</p>
<p>Do the following as the <code>root</code> user:</p>
<ol>
<li><p>Install the <a href="https://packages.debian.org/stable/cryptsetup"><code>cryptsetup</code> package</a>:</p>
<pre><code>apt install cryptsetup
</code></pre></li>
<li><p>Copy your home directory to a temporary directory on a different partition:</p>
<pre><code>mkdir /homebackup
cp -a /home/* /homebackup
</code></pre></li>
<li><p>Encrypt your home partition:</p>
<pre><code>umount /home
cryptsetup -h sha512 -c aes-xts-plain64 -s 512 luksFormat /dev/sda5
cryptsetup luksOpen /dev/sda5 chome
mkfs.ext4 -m 0 /dev/mapper/chome
</code></pre></li>
<li><p>Add this line to <code>/etc/crypttab</code>:</p>
<pre><code>chome /dev/sda5 none luks,timeout=30
</code></pre></li>
<li><p>Set the home partition to this in <code>/etc/fstab</code> (replacing the original home partition line):</p>
<pre><code>/dev/mapper/chome /home ext4 nodev,nosuid,noatime 0 2
</code></pre></li>
<li><p>Copy your home data back into the encrypted partition:</p>
<pre><code>mount /home
cp -a /homebackup/* /home
rm -rf /homebackup
</code></pre></li>
</ol>
<p>That's it. Next time you boot your laptop, you will be prompted for the passphrase you set in Step 2.</p>
<p>Now to fully secure your laptop against theft, you should think about an <a href="http://packages.debian.org/sid/duplicity">encrypted backup strategy</a> for your data...</p>
Encrypted swap partition on Debian/Ubuntuhttps://feeding.cloud.geek.nz/posts/encrypted-swap-partition-on/
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
2021-06-11T20:43:57Z2008-03-30T01:29:00Z
<p>The swap partition can hold a lot of unencrypted confidential information and the fact that it persists after shutting down the computer can be a problem.</p>
<p>Encrypting a swap partition however is slightly tricky if one wants to also support suspend-to-disk (also called hibernation). Here's a procedure that worked for me on both Debian Stretch and Ubuntu 18.04 (Bionic Beaver):</p>
<ol>
<li><p>Install the <a href="https://packages.debian.org/stable/cryptsetup">cryptsetup package</a>:</p>
<pre><code>apt install cryptsetup
</code></pre></li>
<li><p>Add this line to <code>/etc/crypttab</code>:</p>
<pre><code>sda2_crypt /dev/sda2 /dev/urandom cipher=aes-xts-plain64,size=256,swap,discard
</code></pre></li>
<li><p>Set the swap partition to be this in <code>/etc/fstab</code>:</p>
<pre><code>/dev/mapper/sda2_crypt none swap sw 0 0
</code></pre></li>
</ol>
<p>You will of course want to replace <code>/dev/sda2</code> with the partition that currently holds your unencrypted swap.</p>
<p>This is loosely based on a similar <a href="http://www.c3l.de/linux/howto-completly-encrypted-harddisk-including-suspend-to-encrypted-disk-with-ubuntu-6.10-edgy-eft.html">procedure for Ubuntu 6.10</a>, but I don't use suspend-to-disk and so I simplified the setup and use a random encryption key instead of a passphrase.</p>