[clug] Can't mount an encrupted backup file system

[Ian Munsie]

Hi John,

>> Have I missed something? Why are you trying to add a new key to an
>> existing partition (what luksAddKey does) on the new system? Can you
>> decrypt it with luksOpen and the old passphrase?
>
> I'm trying to add a passphrase to the new eeePC so that I can connect to
> the 1Tb drive. I'm using the same passphrase that I used to encrypt the
> 1Tb drive.

I'm not sure we are on the same page here - you definitely should not
be trying to "add a passphrase to the new eeePC". That may not be what
you meant to say, but it sounds like you are thinking of decrypting
the drive like managing a key agent (like Gnome's key manager or
ssh-agent), where you need to add the decryption key to the agent
before you can decrypt the drive. That is not how decrypting a drive
works in Linux*, and you shouldn't be thinking about it that way.

That said, it wouldn't surprise me if Gnome's key manager has added
some extra layer of indirection over the top of this process, which
might make it behave more like a key agent when using those tools (I'm
not very familiar with Gnome's key manager, so this is speculation).
Whenever using cryptsetup directly this will not be the case.


> Note that the box that pops up (box B) is different to that on the old
> eeePC. However, if on the old eeePC I select the "cancel" button on the
> the first pop up box (box A) the same box as on the new eeePC (box B)
> pops up. If I enter the passphrase into this box I get a similar error.

I don't generally use the GUI tools (or Gnome for that matter), so I'm
not very familiar with them, but I am intrigued by why you could get
two different dialog boxes and that you could reproduce the same
failure on the old eeePC with the second dialog.

I am starting to get suspicious that some GUI tool on the old eeePC
may have caused the device to be encrypted with a different key to
what you expected.

Can you let me know which program each of the two dialog boxes belongs
to? If it isn't immediately obvious you can find out by running these
commands in an X terminal while the dialog is displayed (sorry, I'm
not aware of an easier way to do this):

$ xprop | grep CLIENT_LEADER

The mouse cursor will change to a target cross - click on the dialog
box. You will probably see output similar to this:

WM_CLIENT_LEADER(WINDOW): window id # 0x1e00001

a) If you DO see this, run (replace 0x1e00001 with the window id of
the client leader found in the previous command):
$ xprop -id 0x1e00001 | grep COMMAND

b) If you DID NOT find a client leader, instead run this and click on
the dialog again:
$ xprop | grep COMMAND

Hopefully you will end up with the program that created the dialog, like:

WM_COMMAND(STRING) = { "firefox-bin" }


> Previously, before I did the modprobe sha256, trying to cryptsetup
> luksAddkey did *not* prompt me for a passphrase. Now that I have
> added the modprobe sha256 the cryptsetup luksAddKey command *does* ask
> me for a passphrase. I thought that this was an advancement.

ok, that certainly is interesting.


>> If you still are unable to decrypt the device, this is how you would
>> try David's suggestion of luksAddKey:
...
>> ON THE OLD EEEPC (i.e where you can mount the device):
...
>> # cryptsetup luksAddKey /dev/<device> my_new_key_file
...
> I still get the error "No key available with this passphrase.".

I didn't expect this to fail in that way. Can you confirm:

1) You are running this command on the old eeePC, where you are able
to decrypt the drive through the GUI.

2) You are still able to decrypt the drive through the GUI using the
same passphrase you entered when running this command.

3) You are able to decrypt the drive without using the GUI, with (be
sure to remove/unmount/eject/whatever/it/calls/it through the GUI
first):

cryptsetup luksOpen /dev/<device> some_arbitrary_device_name

Cheers,
-Ian




* At least as far as the user is concerned. To be fair, under the hood it does
work that way, but that is hidden to the user behind LUKS and you don't ever
interface with that directly. The key management that LUKS exposes to the user
is something else entirely, which I explained in some detail in my previous
email.

-- 
http://sites.google.com/site/DarkStarJunkSpace
--
http://darkstarshout.blogspot.com/
--
On the day *I* go to work for Microsoft, faint oinking sounds will be
heard from far overhead, the moon will not merely turn blue but
develop polkadots, and hell will freeze over so solid the brimstone
will go superconductive.
     -- Eric S. Raymond, 2005
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html