[lug] stupid encrypted hard disk question

[Maxwell Spangler]

> On Sat, May 19, 2012 at 2:22 PM, Stephen Queen <svqueen at gmail.com>
> wrote:
> 
>         On 5/18/12, Bear Giles <bgiles at coyotesong.com> wrote:
>         > I have a really stupid encrypted hard disk question.

Really important question, actually :)

>         > I have a system with two drives, each with three
>         partitions.  There's a
>         > small RAID-1 partition for /boot, a small non-RAID partition
>         for swap
>         > (giving two swap partitions in total - there's no point in
>         using RAID with
>         > swap), and the third partition is a fairly standard stack:
>         >
>         >  - LVM
>         >  - encryption
>         >  - RAID
>         >
>         > The issue is that when I boot the system it brings me to the
>         login screen.
>         > Shouldn't it take me to a screen to enter a decryption
>         password for the big
>         > partition? If it's reading the password from somewhere in
>         the /boot
>         > partition doesn't that defeat the whole purpose for the
>         encryption?
>         >

Linux distributions have different ways of setting up this stack.

Fedora encrypts it in such a way that the kernel will boot, you will be
asked for the LUKS (encryption) key and then it will be able to use the
disk. 

When I encrypted my personal home directory with Ubuntu, I believe it
used my login password as the LUKS password.  So when I login with
user/pass, it then used the same pass to access the encrypted home
directory.  This provides a cleaner presentation to the user but seemed
to me to be a little more complicated behind the scenes.

-- 
Maxwell Spangler
========================================================================
Linux System Administration / Computing Services
Photography / Graphics Design / Writing
Fort Collins, Colorado
http://www.maxwellspangler.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20120521/b5ed6c1a/attachment.html>