NSLU2-Linux
view · edit · print · history

HowTo.ProjectCryptSlug History

Hide minor edits - Show changes to markup

June 10, 2008, at 05:44 AM by none -- Adding pam_mount scripts
Changed lines 143-151 from:
	TODO: configure the NFS server
to:
	TODO: configure the NFS server

 mounting and umounting
To simplify mounting and unmounting the encrypted partitions, consider
using the pam_mount scripts mount.crypt and umount.crypt
        http://dev.computergmbh.de/gitweb.cgi?p=pam_mount;a=blob_plain;f=scripts/mount.crypt;hb=HEAD

http://dev.computergmbh.de/gitweb.cgi?p=pam_mount;a=blob_plain;f=scripts/umount.crypt;hb=HEAD

December 03, 2007, at 03:04 PM by fcarolo -- fixed false wikilinks
Changed lines 1-2 from:

Project CryptSlug?

to:

Project CryptSlug

Changed lines 22-24 from:
And thus, ProjectCryptSlug was born.
This HowTo will explain how to configure a freshly flashed NSLU2
to:
And thus, ProjectCryptSlug was born.
This HowTo will explain how to configure a freshly flashed NSLU2
Changed line 28 from:
Flashing your NSLU2 is not covered by this HowTo as it is already
to:
Flashing your NSLU2 is not covered by this HowTo as it is already
Changed lines 31-32 from:

Goals of this HowTo

to:

Goals of this HowTo

November 27, 2007, at 01:19 AM by ka6sox --
Changed line 10 from:
HR database with SSNs? for debugging purposes or your not-so-legal
to:
HR database with SSNs for debugging purposes or your not-so-legal
Changed line 18 from:
But what if these drives must be accessible to multiple client PCs?
to:
But what if these drives must be accessible to multiple client PCs
November 27, 2007, at 01:18 AM by ka6sox --
Changed line 33 from:
  • Sharing one or more fully encrypted HDDs? via NFS (or other means) \\
to:
  • Sharing one or more fully encrypted HDDs via NFS (or other means) \\
Changed line 45 from:
  • One or more HDDs? to be encrypted and used as shared drives
to:
  • One or more HDDs to be encrypted and used as shared drives
November 27, 2007, at 01:17 AM by ka6sox --
Changed lines 54-55 from:
not keep the HDDs? spinning uselessly.
to:
not keep the HDDs spinning uselessly.
Changed lines 66-67 from:
You should use ext3 instead of ext2 for HDDs?.
to:
You should use ext3 instead of ext2 for HDDs.
November 27, 2007, at 01:16 AM by ka6sox --
Changed line 64 from:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
to:
 mkfs.ext2 -m0 -L "Boot" /dev/sda1
November 27, 2007, at 01:15 AM by ka6sox --
Changed line 38 from:

Recuirements

to:

Requirements

Changed lines 54-55 from:
not keep the HDDS spinning uselessly.
to:
not keep the HDDs? spinning uselessly.
Changed lines 57-58 from:
I assume that you know how to partition an HDD at this point.
to:
(I assume that you know how to partition an HDD at this point.)
Changed lines 70-71 from:
turnup disk -i /dev/sda1 -t ext2
to:
 turnup disk -i /dev/sda1 -t ext2
Changed lines 73-75 from:
reboot
to:
 reboot
Changed lines 78-80 from:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 975112 9652 965460 1% /
to:
 Filesystem           1k-blocks      Used Available Use% Mounted on
 /dev/sda1               975112      9652    965460   1% /
Changed lines 86-87 from:
ipkg update && ipkg install cryptsetup nfs-utils
to:
 ipkg update && ipkg install cryptsetup nfs-utils 
Changed lines 95-96 from:
echo „dm-crypt“ > /etc/modutils/dm-crypt && update-modules
to:
 echo „dm-crypt“ > /etc/modutils/dm-crypt && update-modules
Changed lines 98-102 from:
root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh
Calculating module dependencies ...
Loading modules: dm-crypt
to:
 root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh
 Calculating module dependencies ...
 Loading modules: dm-crypt 
Changed lines 113-114 from:
cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1
to:
 cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1
Changed lines 120-121 from:
cryptsetup luksOpen /dev/sdb1 $SOMENAME
to:
 cryptsetup luksOpen /dev/sdb1 $SOMENAME
Changed lines 129-130 from:
mkfs.ext3 -m0 /dev/mapper/$SOMENAME
to:
 mkfs.ext3 -m0 /dev/mapper/$SOMENAME
Changed lines 133-134 from:
mount /dev/mapper/$SOMENAME /media/somewhere
to:
 mount /dev/mapper/$SOMENAME /media/somewhere 
November 27, 2007, at 12:51 AM by none --
Changed lines 109-110 from:

This process causes complete data loss on that HDD!

to:
This process causes complete data loss on that HDD!
Changed line 139 from:
via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command after every
to:
via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command after every
November 27, 2007, at 12:49 AM by none --
Changed lines 109-110 from:

This process causes complete data loss on that HDD!

to:

This process causes complete data loss on that HDD!

November 27, 2007, at 12:48 AM by none --
Changed lines 22-23 from:
And thus, Project CryptSlug? was born.
to:
And thus, ProjectCryptSlug was born.
Changed lines 109-110 from:

! This process involves complete data loss on that HDD ! !

to:

This process causes complete data loss on that HDD!

November 27, 2007, at 12:45 AM by none --
Changed lines 86-87 from:
ipkg update && ipkg install cryptsetup nfs-utils
to:
ipkg update && ipkg install cryptsetup nfs-utils
Changed lines 95-96 from:
echo „dm-crypt“ > /etc/modutils/dm-crypt ; update-modules
to:
echo „dm-crypt“ > /etc/modutils/dm-crypt && update-modules
Changed lines 99-102 from:
root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh
Calculating module dependencies ...
Loading modules: dm-crypt
to:
root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh
Calculating module dependencies ...
Loading modules: dm-crypt
Changed lines 113-114 from:
cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1
to:
cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1
Changed lines 120-121 from:
cryptsetup luksOpen /dev/sdb1 $SOMENAME
to:
cryptsetup luksOpen /dev/sdb1 $SOMENAME
Changed lines 129-130 from:
mkfs.ext3 -m0 /dev/mapper/$SOMENAME
to:
mkfs.ext3 -m0 /dev/mapper/$SOMENAME
Changed lines 133-134 from:
mount /dev/mapper/$SOMENAME /media/somewhere
to:
mount /dev/mapper/$SOMENAME /media/somewhere
November 27, 2007, at 12:43 AM by none --
Changed line 64 from:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
to:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
Changed lines 70-71 from:
turnup disk -i /dev/sda1 -t ext2
to:
turnup disk -i /dev/sda1 -t ext2
Changed lines 74-75 from:
reboot
to:
reboot
Changed lines 78-80 from:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 975112 9652 965460 1% /
to:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 975112 9652 965460 1% /
November 27, 2007, at 12:41 AM by none --
Changed line 64 from:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
to:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
Changed lines 70-71 from:
turnup disk -i /dev/sda1 -t ext2
to:
turnup disk -i /dev/sda1 -t ext2
Changed lines 74-80 from:
reboot
	The output of df  now shows our USB key as new rootfs:

	Filesystem           1k-blocks      Used Available Use% Mounted on
	/dev/sda1               975112      9652    965460   1% /
to:
reboot
The output of df now shows our USB key as new rootfs:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 975112 9652 965460 1% /
Changed lines 83-100 from:
	The following command installs all required packages for our
	little project:

 		ipkg update && ipkg install cryptsetup nfs-utils

	You may get one or more warning about missing modules.
	Usually these can be ignored.

	Cryptsetup depends on the dm-crypt module to function. For some 	reason the module does not auto-load so we need to force a 	modprobe on each boot:

 		echo „dm-crypt“ > /etc/modutils/dm-crypt ; update-modules

	 Running modutils.sh should now auto-modprobe dm-crypt:

		root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh 
		Calculating module dependencies ...
		Loading modules: dm-crypt 
to:
The following command installs all required packages for our
little project:
ipkg update && ipkg install cryptsetup nfs-utils
You may get one or more warning about missing modules.
Usually these can be ignored.
Cryptsetup depends on the dm-crypt module to function. For some
reason the module does not auto-load so we need to force a modprobe
on each boot:
echo „dm-crypt“ > /etc/modutils/dm-crypt ; update-modules
Running modutils.sh should now auto-modprobe dm-crypt:
root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh
Calculating module dependencies ...
Loading modules: dm-crypt
Changed lines 105-110 from:
	At this point out slug is ready to handle encrypted partitions via 	cryptsetup. Now I'll explain how to format and encrypt an entire
	partition of an HDD.

	! ! This process involves complete data loss on that HDD ! !

Encrypt the partition:

to:
At this point out slug is ready to handle encrypted partitions via
cryptsetup. Now I'll explain how to format and encrypt an entire
partition of an HDD.

! This process involves complete data loss on that HDD ! !

  • Encrypt the partition:
Changed lines 113-135 from:
		cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

	 You will be asked for a password, you should try really hard
	not to forget it! Lose the password, lose the encrypted data.

Make the encrypted partition readable to the OS:

		cryptsetup luksOpen /dev/sdb1 $SOMENAME

	$SOMENAME can be anything at all, it identifies the partition.
	The encrypted partition can now be accessed via  	/dev/mapper/$SOMENAME. You can work with it like with a normal 	partition, just remember to not use /dev/sd* but always 	/dev/mapper/$SOMENAME.

Create a filesystem on the partition:

 		mkfs.ext3 -m0 /dev/mapper/$SOMENAME

Mount the partition somewhere:

		mount /dev/mapper/$SOMENAME /media/somewhere

	Congratulations. You're now the proud owner of a fully encrypted 	partition mounted on your NSLU2. After a reboot (or a power loss, 	someone stealing the HDD) the disk is fully encrypted and 	useless 	to any attacker. You have to manually specify the password
 	via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command 	after every boot. As the NSLU2 usually is very stable, that shouldn't 	happen too often.
to:
cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1
You will be asked for a password, you should try really hard
not to forget it! Lose the password, lose the encrypted data.
  • Make the encrypted partition readable to the OS:
    cryptsetup luksOpen /dev/sdb1 $SOMENAME
$SOMENAME can be anything at all, it identifies the partition.
The encrypted partition can now be accessed via /dev/mapper/$SOMENAME.
You can work with it like with a normal partition, just remember to
not use /dev/sd* but always /dev/mapper/$SOMENAME.
  • Create a filesystem on the partition:
    mkfs.ext3 -m0 /dev/mapper/$SOMENAME
  • Mount the partition somewhere:
    mount /dev/mapper/$SOMENAME /media/somewhere
Congratulations. You're now the proud owner of a fully encrypted
partition mounted on your NSLU2. After a reboot (or a power loss,
someone stealing the HDD) the disk is fully encrypted and useless
to any attacker. You have to manually specify the password
via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command after every
boot. As the NSLU2 usually is very stable, that shouldn't happen too often.
November 27, 2007, at 12:37 AM by none --
Changed lines 61-62 from:
Format the target partition onto which we will copy the rootfs.
In my case, I used an USB key drive:
to:
  • Format the target partition onto which we will copy the rootfs.
    In my case, I used an USB key drive:
Changed line 64 from:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
to:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
Changed lines 66-68 from:
You should use ext3 instead of ext2 for HDDs?.
Copy the rootfs
to:
You should use ext3 instead of ext2 for HDDs?.
  • Copy the rootfs
Changed lines 70-75 from:
turnup disk -i /dev/sda1 -t ext2
Reboot the slug to switch to the new rootfs:
			reboot
to:
turnup disk -i /dev/sda1 -t ext2
  • Reboot the slug to switch to the new rootfs:
reboot
November 27, 2007, at 12:35 AM by none --
Changed line 45 from:
  • One or more HDDs? to be encrypted and used as shared drives \\
to:
  • One or more HDDs? to be encrypted and used as shared drives
Changed lines 50-56 from:
	As I mentioned before, the onboard flash of the NSLU2 is not
	large enough to hold all packages required, so we need to copy
	the rootfs to either an USB key or a small partition on an connected 	HDD. Many people prefer USB keys as they are cheap, fast and do 	not keep the HDDS spinning uselessly.

	The turnup script in SlugOS will do most of the grunt work for us.
	I assume that you know how to partition an HDD at this point.
to:
As I mentioned before, the onboard flash of the NSLU2 is not
large enough to hold all packages required, so we need to copy
the rootfs to either an USB key or a small partition on an connected
HDD. Many people prefer USB keys as they are cheap, fast and do
not keep the HDDS spinning uselessly.
The turnup script in SlugOS will do most of the grunt work for us.
I assume that you know how to partition an HDD at this point.
Changed lines 61-62 from:

Format the target partition onto which we will copy the rootfs. In my case, I used an USB key drive:

to:
Format the target partition onto which we will copy the rootfs.
In my case, I used an USB key drive:
Changed line 64 from:
 			mkfs.ext2 -m0 -L "Boot" /dev/sda1
to:
mkfs.ext2 -m0 -L "Boot" /dev/sda1
Changed lines 66-68 from:
		 You should use ext3 instead of ext2 for HDDs?.

Copy the rootfs

to:
You should use ext3 instead of ext2 for HDDs?.
Copy the rootfs
Changed lines 70-73 from:
 			turnup disk -i /dev/sda1 -t ext2

Reboot the slug to switch to the new rootfs:

to:
turnup disk -i /dev/sda1 -t ext2
Reboot the slug to switch to the new rootfs:
November 27, 2007, at 12:33 AM by none --
Changed lines 33-34 from:
  • Sharing one or more fully encrypted HDDs? via NFS (or other means) over NFS via an NSLU2
to:
  • Sharing one or more fully encrypted HDDs? via NFS (or other means)
    over NFS via an NSLU2
Changed line 40 from:
  • A cleanly flashed NSLU2 NAS box with a firmware not older than
to:
  • A cleanly flashed NSLU2 NAS box with a firmware not older than \\
Changed lines 42-43 from:
  • A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all
to:
  • A USB flash drive or a dedicated (unencrypted) small partition
    on an HDD to hold the rootfs. The flash is too small to handle all \\
Changed line 45 from:
  • One or more HDDs? to be encrypted and used as shared drives
to:
  • One or more HDDs? to be encrypted and used as shared drives \\
November 27, 2007, at 12:31 AM by none --
Changed lines 39-40 from:
  • A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta
  • A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages!
to:
  • A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta
  • A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages!
November 27, 2007, at 12:30 AM by none --
Changed lines 33-35 from:

Sharing one or more fully encrypted HDDs? via NFS (or other means) over NFS via an NSLU2 The encrypted drives can be connected to any Linux PC as well

to:
  • Sharing one or more fully encrypted HDDs? via NFS (or other means) over NFS via an NSLU2
  • The encrypted drives can be connected to any Linux PC as well
Changed lines 39-43 from:

A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages! One or more HDDs? to be encrypted and used as shared drives A bit of your time and some patience ;)

to:
  • A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta
  • A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages!
  • One or more HDDs? to be encrypted and used as shared drives
  • A bit of your time and some patience ;)
November 27, 2007, at 12:29 AM by none --
Changed line 5 from:
Imagine that you have a good amountof data on external drives
to:
Imagine that you have a good amount of data on external drives
Changed lines 13-21 from:

Storing this kind of stuff unencrypted is downright stupid. But that isn't too much of a problem if the number of external drives is small. If hooked up to a workstation, the external drives can be used with a wide range of encryption applications.

But what if these drives must be accessible to multiple client PCs? at all times? Normally one would use a cheap NAS box to share all drives with the network. Problem is, at the time of writing, none of the usual NAS boxes supported any kind of encryption. And thus, Project CryptSlug? was born.

	This HowTo will explain how to configure a freshly flashed NSLU2 	NAS box running SlugOS to securely encrypt attached drives and 	act as an NFS server. 

	Flashing your NSLU2 is not covered by this HowTo as it is already
	documented elsewhere.
to:
Storing this kind of stuff unencrypted is downright stupid.
But that isn't too much of a problem if the number of external
drives is small. If hooked up to a workstation, the external drives
can be used with a wide range of encryption applications.
But what if these drives must be accessible to multiple client PCs?
at all times? Normally one would use a cheap NAS box to share
all drives with the network. Problem is, at the time of writing,
none of the usual NAS boxes supported any kind of encryption.
And thus, Project CryptSlug? was born.
This HowTo will explain how to configure a freshly flashed NSLU2
NAS box running SlugOS to securely encrypt attached drives and
act as an NFS server.
Flashing your NSLU2 is not covered by this HowTo as it is already
documented elsewhere.
November 27, 2007, at 12:27 AM by none --
Changed lines 5-8 from:
Imagine that you have a good amountof data on external drives which you really would not want to be compromised in case of theft or curious relatives with too much time on their hands.

That data may be anything from company secrets, a dump of the HR database with SSNs? for debugging purposes or your not-so-legal BT movie collection.

to:
Imagine that you have a good amountof data on external drives
which you really would not want to be compromised in case of theft
or curious relatives with too much time on their hands.
That data may be anything from company secrets, a dump of the
HR database with SSNs? for debugging purposes or your not-so-legal
BT movie collection.
November 27, 2007, at 12:26 AM by none --
Changed lines 5-12 from:
	Imagine that you have a good amountof data on external drives 	which you really would not want to be compromised in case of theft 	or curious relatives with too much time on their hands.

	That data may be anything from company secrets, a dump of the 	HR database with SSNs? for debugging purposes or your not-so-	legal BT movie collection.

	Storing this kind of stuff unencrypted is downright stupid. But that 	isn't too much of a problem if the number of external drives is 	small. If hooked up to a workstation, the external drives can be 	used with a wide range of encryption applications.

	But what if these drives must be accessible to multiple client PCs? at 	all times? Normally one would use a cheap NAS box to share all 	drives with the network. Problem is, at the time of writing, none of 	the usual NAS boxes supported any kind of encryption. And thus, 	Project CryptSlug? was born.
to:
Imagine that you have a good amountof data on external drives which you really would not want to be compromised in case of theft or curious relatives with too much time on their hands.

That data may be anything from company secrets, a dump of the HR database with SSNs? for debugging purposes or your not-so-legal BT movie collection.

Storing this kind of stuff unencrypted is downright stupid. But that isn't too much of a problem if the number of external drives is small. If hooked up to a workstation, the external drives can be used with a wide range of encryption applications.

But what if these drives must be accessible to multiple client PCs? at all times? Normally one would use a cheap NAS box to share all drives with the network. Problem is, at the time of writing, none of the usual NAS boxes supported any kind of encryption. And thus, Project CryptSlug? was born.

November 27, 2007, at 12:22 AM by none --
Added lines 1-113:

Project CryptSlug?

Introduction

	Imagine that you have a good amountof data on external drives 	which you really would not want to be compromised in case of theft 	or curious relatives with too much time on their hands.

	That data may be anything from company secrets, a dump of the 	HR database with SSNs? for debugging purposes or your not-so-	legal BT movie collection.

	Storing this kind of stuff unencrypted is downright stupid. But that 	isn't too much of a problem if the number of external drives is 	small. If hooked up to a workstation, the external drives can be 	used with a wide range of encryption applications.

	But what if these drives must be accessible to multiple client PCs? at 	all times? Normally one would use a cheap NAS box to share all 	drives with the network. Problem is, at the time of writing, none of 	the usual NAS boxes supported any kind of encryption. And thus, 	Project CryptSlug? was born.

	This HowTo will explain how to configure a freshly flashed NSLU2 	NAS box running SlugOS to securely encrypt attached drives and 	act as an NFS server. 

	Flashing your NSLU2 is not covered by this HowTo as it is already
	documented elsewhere.

Goals of this HowTo

Sharing one or more fully encrypted HDDs? via NFS (or other means) over NFS via an NSLU2 The encrypted drives can be connected to any Linux PC as well

Recuirements

A cleanly flashed NSLU2 NAS box with a firmware not older than slugosbe-4.6-beta A USB flash drive or a dedicated (unencrypted) small partition on an HDD to hold the rootfs. The flash is too small to handle all packages! One or more HDDs? to be encrypted and used as shared drives A bit of your time and some patience ;)

Moving the rootfs

	As I mentioned before, the onboard flash of the NSLU2 is not
	large enough to hold all packages required, so we need to copy
	the rootfs to either an USB key or a small partition on an connected 	HDD. Many people prefer USB keys as they are cheap, fast and do 	not keep the HDDS spinning uselessly.

	The turnup script in SlugOS will do most of the grunt work for us.
	I assume that you know how to partition an HDD at this point.

Copy the rootfs

Format the target partition onto which we will copy the rootfs. In my case, I used an USB key drive:

 			mkfs.ext2 -m0 -L "Boot" /dev/sda1

		 You should use ext3 instead of ext2 for HDDs?.

Copy the rootfs

 			turnup disk -i /dev/sda1 -t ext2

Reboot the slug to switch to the new rootfs:

			reboot

	The output of df  now shows our USB key as new rootfs:

	Filesystem           1k-blocks      Used Available Use% Mounted on
	/dev/sda1               975112      9652    965460   1% /

Installing & configuring additional packages

	The following command installs all required packages for our
	little project:

 		ipkg update && ipkg install cryptsetup nfs-utils

	You may get one or more warning about missing modules.
	Usually these can be ignored.

	Cryptsetup depends on the dm-crypt module to function. For some 	reason the module does not auto-load so we need to force a 	modprobe on each boot:

 		echo „dm-crypt“ > /etc/modutils/dm-crypt ; update-modules

	 Running modutils.sh should now auto-modprobe dm-crypt:

		root@nslu2:/etc/modutils$ /etc/init.d/modutils.sh 
		Calculating module dependencies ...
		Loading modules: dm-crypt 

Setting up an encrypted partition

	At this point out slug is ready to handle encrypted partitions via 	cryptsetup. Now I'll explain how to format and encrypt an entire
	partition of an HDD.

	! ! This process involves complete data loss on that HDD ! !

Encrypt the partition:

		cryptsetup -c aes-cbc-essiv:sha256 -y luksFormat /dev/sdb1

	 You will be asked for a password, you should try really hard
	not to forget it! Lose the password, lose the encrypted data.

Make the encrypted partition readable to the OS:

		cryptsetup luksOpen /dev/sdb1 $SOMENAME

	$SOMENAME can be anything at all, it identifies the partition.
	The encrypted partition can now be accessed via  	/dev/mapper/$SOMENAME. You can work with it like with a normal 	partition, just remember to not use /dev/sd* but always 	/dev/mapper/$SOMENAME.

Create a filesystem on the partition:

 		mkfs.ext3 -m0 /dev/mapper/$SOMENAME

Mount the partition somewhere:

		mount /dev/mapper/$SOMENAME /media/somewhere

	Congratulations. You're now the proud owner of a fully encrypted 	partition mounted on your NSLU2. After a reboot (or a power loss, 	someone stealing the HDD) the disk is fully encrypted and 	useless 	to any attacker. You have to manually specify the password
 	via the cryptsetup luksOpen /dev/sdb1 $SOMENAME command 	after every boot. As the NSLU2 usually is very stable, that shouldn't 	happen too often.

	TODO: Use keys instead of passphrase
	TODO: configure the NFS server
view · edit · print · history · Last edited by none.
Based on work by fcarolo, ka6sox, and none.
Originally by none.
Page last modified on June 10, 2008, at 05:44 AM