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

[jhock]

Hi All,

Sorry for bothering you all but you may be interested that I have solved
the problem.

Ubuntu uses Seahorse for managing the 'Password and encryption keys'. On
the old eeePC I looked up the Luks passphrase settings for the 1Tb
external disk. I copied the details into a file on an unecrypted USB
memory stick.

I then opened Seahorse on the new eeePC and created a new passphase. I
copied the details from the file on the USB memory stick into the GUI
and saved the passphrase.

I then plugged in the 1Tb drive, entered the passphrase and it worked.

I don't know why but I suspect that Ian may have been right in that the
passphrase got mangled somehow.

Anyway, I am now recovering my directories from the 1Tb backups.

Thanks to everyone who helped and tried to help. I still don't know what
went wrong but now that I can migrate my data I'm happy.

Thanks again. Great list.

John 

On Mon, 2012-06-18 at 14:43 +1000, Ian Munsie wrote:
> 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.
>