Mailinglist Archive: opensuse (3831 mails)

< Previous Next >
Re: [opensuse] encrypted usb drives - fixed mount points
  • From: "Dennis E. Slice" <dslice@xxxxxxxxxxxxxxxxx>
  • Date: Fri, 19 Jan 2007 02:54:14 -0500
  • Message-id: <45B07926.3030107@xxxxxxxxxxxxxxxxx>


Carlos E. R. wrote:
>
> The Wednesday 2007-01-17 at 21:54 -0500, Dennis E. Slice wrote:
>
>> [Sorry for the formatting. I wanted to reorder the comments.]
>
> No problem, I do that sometimes.
>
>> My system works fine, but I was very interested in Carlos' suggestions.
>> Here are my observations:
>
>>> They would mount if available at boot time, if the service is enabled:
>>>
>>> nimrodel:~ # chkconfig boot.crypto
>>> boot.crypto on
>>>
>>> and the device is available at that time. It prompts for a password during
>>> boot up.
>> boot.crypto tries, but fails to find the partitions at boot time. In
>> fact, it fails without delay.
>
> Not very surprising in your case, as it is an USB device, so it is not
> available.
>

I suppose it might have been better to just mount a regular partition
and use encrypted files. But, what's done is done and works. Curiously,
though, USB comes up and the drive lights are on before the attempt to
mount.

>
>
>>> As I mentioned previously, you can also use fstab for encrypted
>>> partitions. For instance, one of mine:
>>>
>>> /device_or_file /mnt/crypto xfs noauto,loop=/dev/loop4,encryption=twofish256 0 0
>>>
>>>
>>> I doubt labels could be used here, but I assume dev-ids would - I never
>>> thought of that till reading this thread ;-)
>> Right, there is no way to label an encrypted partition as far as I can
>> tell. I moved the specs to fstab, but no go. At boot, the system doesn't
>> seem to know about encryption and just says:
>
>> mount: going to use the loop device /dev/loop0
>> /dev/disk/by-id/usb-WD_<snip>-part1: No such file or directory
>> mount: failed setting up loop device
>
> Maybe because usb is not setup yet.

Yup. The lights are off.

>
>> for each drive. Here, the drive lights are not yet on.
>
>> Subsequently, trying to manually mount the partitions as root gives:
>
>> ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key
>> length (256 bits) not supported by kernel
>
> Mmm, that's funny!
>
>
>> I am curious as to why the initial boot.crypto fails,
>
> I believe because usb is not fully up, or if not, the partitions IDs have
> not appeared yet. I can not test it.
>
>> why booting with
>> the specs in fstab doesn't invoke boot.crypto,
>
> No, that's by design. The fstab way is a different way: choose one or the
> other for each device (I have one method of one device, and the other for
> another).
>
>> and why my kernel doesn't
>> support 256 bit encryptions.
>
> Well, that's "funny", and I don't understand it. If your encrypted
> partition can be mounted manually using boot.crypto, it must work via
> fstab as well.
>
>> Actually, I guess I just didn't specify
>> something about the latter when I installed, but I'm not going to
>> reinstall the kernel at this time - everything does work as originally
>> described.
>
> I don't think so. The twofish256 method is the one used by Yast, so SuSE
> kernels support it by default. It has to be something else.
>
> Hold on, you are using 10.0 and I am on 10.1... no, it shouldn't be that.
> I know there were big changes in 9.x, but not in 10.0
>
> I'm not sure...
>
> Anyway, if you are using the encryption method that Yast uses when
> creating encrypted partitions, you should have no problems.
>

All part of life's mysteries, I guess.

>
> Maybe your fstab line is incorrect. Let me see, in cryptotab you have
> (from a previous post):
>
> /dev/loop0 /dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_0 reiserfs twofish256 acl,user_xattr
> /dev/loop1 /dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_1 reiserfs twofish256 acl,user_xattr
>
>
> Then your fstab lines would be:
>
>
> /dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_0 reiserfs noauto,loop=/dev/loop0,encryption=twofish256,acl,user_xattr 0 0
> /dev/disk/by-id/usb-WD_<snip>-part1 /media/USB320_1 reiserfs noauto,loop=/dev/loop1,encryption=twofish256,acl,user_xattr 0 0
>
>
> You see, the lines are very similar to the cryptotab file, but in a
> different order. They have the "noauto" option so that boot doesn't try to
> mount them. Also, the fsck digit is "0" so that it doesn't try to run fsck
> on them; even "thinking" about it and not finding the disk will make the
> boot.localfs stop while booting and request you run a manual fsck. Quite
> confusing.
>

Yes, I modified the fstab lines according to your example. Typos were
duly reported as "bad lines", but when correct it tried, but gave the
256 error. Auto mounting failure wasn't too surprising since the drives
weren't up an running when it tried to mount.

>
>
>>> sync/nosync?
>>>
>> Not sure the relevance here for encrypted partitions. I am running with
>> whatever the default is and previous discussions seemed tp focus on
>> FAT32 files systems and such.
>
> It does have relevance for other partition types, but I'm not sure about
> encrypted ones.
>
>
> By the way, when an encrypted partition fails to mount, the messages it
> gives are confusing. Looking at the output of dmesg may help.

Thanks. The following instructions should be useful.

>
> I'll write here my procedure for testing. I use xfs partitions, so don't
> take the commands literally. Also, I'm using a file instead of a
> partition, so there are some differences.
>
>
>
> * Creation procedure (equivalent to what yast does):
>
>
> For files, first you need to create an empty file:
>
> dd if=/dev/zero of=crypta.bck bs=1MB count=4700
>
> (note: 1MB = 1e6 bytes; 1MiB = 2^20 bytes)
>
> The peculiar size is for later burning dvds. For partitions, you simply
> create the partition (fdisk). Then, you activate the loop device on it,
> choosing the encryption type:
>
> losetup -T -e twofish256 /dev/loop1 crypta.bck
>
> The "-T" is to make it ask for the password twice (crucial when creating!
> ;-) ). There are many encryption methods, and I don't fully understand
> them, but "twofish256" is what Yast is using in SuSE 10.1.
>
> Then, you format or create a filesystem:
>
> mkfs -V -t xfs -L CryptoBackup /dev/loop1
>
> or
>
> mkfs -t ext3 /dev/loop1
>
> as you wish. Or reiserfs, or whatever.
>
>
> Finally, "losetup -d /dev/loop1" will detach the loop device. The "-a"
> will show what is attached.
>
>
>
> * manual mount - easier to see where the problem is:
>
>
> losetup -e twofish256 /dev/loop1 crypta.bck
> mount -t xfs /dev/loop1 /mnt/tmp
>
>
>
> umount:
>
> umount /dev/loop1
> losetup -d /dev/loop1
> losetup -a
>
>
>
> * running a fsck:
>
> losetup -T -e twofish256 /dev/loop1 crypta.bck
> fsck /dev/loop1
>
> because fsck is run before mounting a device.
>
>
> * backup to dvd:
>
> Burn the umounted crypta.bck file to dvd as an image (not iso!), via
> the preferred method. I use:
>
> growisofs -dvd-compat -Z /dev/hdc=crypta.bck
>
> Actually, I have a little script that checks the file is not mounted,
> burns, and finally compares the result.
>
>
>
>
>
> Those are my notes... I hope not to have mistyped things. O:-)

Again, thanks. -ds

>
>
>
>
>
>

--
Dennis E. Slice
Department of Anthropology
University of Vienna
========================================================
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >