Document recovery of Ubuntu-style encrypted home from external USB and get it to the top of Google
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| ecryptfs-utils (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bug Description
The documentation covering Ubuntu's out-of-the-box encrypted partitions, and the recovery there-of, is dire. The common case is that a user has salvaged the hard-disk out of another laptop, connected it using an external USB<->SATA/IDE converter and just wants to get to the encrypted data.
Ubuntu provides out-of-the-box single tickbox support for setting up encypted home directories, and even encourages the user to save a backup recovery key. When the user comes to needing to use it, they have no idea how to. The top result on Google is completely irrelevant and demonstrates the lack of public knowledge:
http://
Then there is tonnes of information on LUKS and/or device-mapper. Neither of which is relevant:
https:/
Eventually the user might happen upon:
https:/
which has little nuggets (mount -t encyptfs) in the right direction, but talks about the generic case, rather than being optimised for the use-case that Ubuntu ships *out-of-the-box*. The particular documentation tells the user to ignore scary error messages, even though ignoring scary error messages doesn't help. It confuses login passwords and recovery passwords and uses different terminology to the original Ubuntu installer/setup utility. It suggests that the user entered a recovery key, when actually the setup-utility provided one.
Ideally there would be something with heuristics, that asked for the "passphrase from the original machine" and failing that asked for the back up key "this is a long sequence of numbers and letters and is NN characters long". Even better would be some documentation to say (in three lines or so) how to mount a home directory that was created with the out-of-the-box setup onto a recovery machine in such a way as the user was guided through the defaults and these were sanity checked. If the default is to use encrypted filenames, then that should be the default in the mount tool too.
It would appear that the two magic lines necessary are something along the lines of:
1a. ecryptfs-
1b. enter login password from other machine
1c. note down 32-digit hex key
2a. sudo echo okay (to make sure your local sudo password is cached and reduce confusion)
2b. sudo mount -t ecryptfs /media/
2c. past 32-digit hex key at "Password:" prompt
2d. aes (default)
2e. 16 (default)
2f. no (default)
2g. yes (yes to encrypted filenames)
2h. [enter] (default, based on key entered in 2c(?) )
2i. yes (just get on with it)
2j. no (wouldn't help)
2k. you may now see "Mounted eCryptfs"
if you're unlucky and happen to be me, you now also get the kernel stracktrace below.
| description: | updated |
| Changed in ecryptfs-utils (Ubuntu): | |
| importance: | Undecided → High |
| description: | updated |
| Paul Sladen (sladen) wrote | #1 |
| description: | updated |
| Dustin Kirkland (kirkland) wrote | #2 |
| Dustin Kirkland (kirkland) wrote | #3 |
| Dustin Kirkland (kirkland) wrote | #4 |
| Launchpad Janitor (janitor) wrote | #5 |
| Changed in ecryptfs-utils (Ubuntu): | |
| status: | New → Fix Released |
| summary: |
- Document recovery of Ubuntu-style encypted home from external USB and + Document recovery of Ubuntu-style encrypted home from external USB and get it to the top of Google |
Then in a cunning last ditch poly to put the user off (if it looks like they're getting close), the system may hand them an OOPS:
[47397.716015] [<c02fbbdf>] ? ecryptfs_
[47397.716015] [<c02f9a9b>] ? ecryptfs_
[47397.716015] [<c02f3063>] ? ecryptfs_
[47397.716015] [<c02a7a96>] ? call_filldir+
[47397.716015] [<c02f3030>] ? ecryptfs_
[47397.716015] [<c02a7c3f>] ? ext4_dx_
[47397.716015] [<c01e682d>] ? filemap_
[47397.716015] [<c01ea72a>] ? __alloc_
[47397.716015] [<c02f3030>] ? ecryptfs_
[47397.716015] [<c02a8266>] ? ext4_readdir+
[47397.716015] [<c01e43a2>] ? unlock_
[47397.716015] [<c01ff768>] ? __do_fault+
[47397.716015] [<c01ee3aa>] ? lru_cache_
[47397.716015] [<c02f3030>] ? ecryptfs_
[47397.716015] [<c031a7a0>] ? security_
[47397.716015] [<c0235246>] ? vfs_readdir+
[47397.716015] [<c02f3030>] ? ecryptfs_
[47397.716015] [<c02f2fd9>] ? ecryptfs_
[47397.716015] [<c0234ef0>] ? filldir64+0x0/0xf0
[47397.716015] [<c0235246>] ? vfs_readdir+
[47397.716015] [<c0234ef0>] ? filldir64+0x0/0xf0
[47397.716015] [<c02353ea>] ? sys_getdents64+
[47397.716015] [<c05fb494>] ? syscall_