How to recover an encrypted home directory on ubuntu

Chris Hoffman is Editor-in-Chief of How-To Geek. He’s written about technology for over a decade and was a PCWorld columnist for two years. Chris has written for The New York Times and Reader’s Digest, been interviewed as a technology expert on TV stations like Miami’s NBC 6, and had his work covered by news outlets like the BBC. Since 2011, Chris has written over 2,000 articles that have been read nearly one billion times—and that’s just here at How-To Geek. Read more.

Access an encrypted home directory when you’re not logged in – say, from a live CD – and all you’ll see is a README file. You’ll need a terminal command to recover your encrypted files.

You should also back up your mount passphrase ahead of time – you may need this in the future. While eCryptfs normally decrypts your files with your login passphrase, the mount passphrase may be necessary if eCryptfs’s files become lost.

Back Up Encryption Passphrase

If you use an encrypted Ubuntu home directory, you should keep a backup copy of your mount passphrase. You’ll see a dialog prompting you to do so after encrypting your home directory. Write down this passphrase and keep it somewhere safe – you may need it to recover your files in the future.

If you want to acquire this mount passphrase at a later date, just run the ecryptfs-unwrap-passphrase command while logged in.

You can still recover your encrypted files without this mount passphrase, assuming the ecryptfs wrapped passphrase is still available on your hard drive. However, if you lose this data or it becomes corrupted, you’ll need the mount passphrase to recover your files.

Recovering From a Live CD

You can recover your files by booting from a Ubuntu live CD or USB drive. If you still have the disc or USB drive you installed Ubuntu from, you can use that. Otherwise, you can download an ISO from Ubuntu’s website and place it on a CD, DVD, or USB drive.

Log in to the live Ubuntu environment and ensure the partition containing your encrypted home directory is mounted. You can easily mount it by clicking It in the file manager – you’ll see an eject (unmount) icon, indicating the partition is mounted.

Next, fire up a terminal and run the following command to search your mounted file systems for encrypted private directories

The command will offer to recover an encrypted directory if it locates one.

Assuming the command found a wrapped passphrase file on your system, it will prompt you for your login passphrase. If it doesn’t find this file, you’ll need the mount passphrase from the ecryptfs-unwrap-passphrase command – hopefully you have a copy of this. If you don’t, you can’t recover your files.

The command will mount the encrypted directory in your /tmp directory.

You can access this directory to view the decrypted versions of your files. However, you may not have read access to this directory as the live CD user.

To access the directory with a graphical file browser, run Nautilus as root. Press Alt+F2, type gksu nautilus, and press Enter.

You’ll be able to access your files from the Nautilus window running as root. From here, you can easily copy the files to an external hard drive or another location.

Chris Hoffman is Editor-in-Chief of How-To Geek. He’s written about technology for over a decade and was a PCWorld columnist for two years. Chris has written for The New York Times and Reader’s Digest, been interviewed as a technology expert on TV stations like Miami’s NBC 6, and had his work covered by news outlets like the BBC. Since 2011, Chris has written over 2,000 articles that have been read nearly one billion times—and that’s just here at How-To Geek. Read more.

Access an encrypted home directory when you’re not logged in – say, from a live CD – and all you’ll see is a README file. You’ll need a terminal command to recover your encrypted files.

You should also back up your mount passphrase ahead of time – you may need this in the future. While eCryptfs normally decrypts your files with your login passphrase, the mount passphrase may be necessary if eCryptfs’s files become lost.

Back Up Encryption Passphrase

If you use an encrypted Ubuntu home directory, you should keep a backup copy of your mount passphrase. You’ll see a dialog prompting you to do so after encrypting your home directory. Write down this passphrase and keep it somewhere safe – you may need it to recover your files in the future.

If you want to acquire this mount passphrase at a later date, just run the ecryptfs-unwrap-passphrase command while logged in.

You can still recover your encrypted files without this mount passphrase, assuming the ecryptfs wrapped passphrase is still available on your hard drive. However, if you lose this data or it becomes corrupted, you’ll need the mount passphrase to recover your files.

Recovering From a Live CD

You can recover your files by booting from a Ubuntu live CD or USB drive. If you still have the disc or USB drive you installed Ubuntu from, you can use that. Otherwise, you can download an ISO from Ubuntu’s website and place it on a CD, DVD, or USB drive.

Log in to the live Ubuntu environment and ensure the partition containing your encrypted home directory is mounted. You can easily mount it by clicking It in the file manager – you’ll see an eject (unmount) icon, indicating the partition is mounted.

Next, fire up a terminal and run the following command to search your mounted file systems for encrypted private directories

The command will offer to recover an encrypted directory if it locates one.

Assuming the command found a wrapped passphrase file on your system, it will prompt you for your login passphrase. If it doesn’t find this file, you’ll need the mount passphrase from the ecryptfs-unwrap-passphrase command – hopefully you have a copy of this. If you don’t, you can’t recover your files.

The command will mount the encrypted directory in your /tmp directory.

You can access this directory to view the decrypted versions of your files. However, you may not have read access to this directory as the live CD user.

To access the directory with a graphical file browser, run Nautilus as root. Press Alt+F2, type gksu nautilus, and press Enter.

You’ll be able to access your files from the Nautilus window running as root. From here, you can easily copy the files to an external hard drive or another location.

An embarrassing thing happened to me lately: I forgot the password to my PC. The connection between my neurons responsible for keeping it suddenly disappeared. And no matter how hard I tried, I couldn’t bring it back.

Of course I make backups, but this time I skipped one and I had some important files that were not copied to my external drive. Normally I would just use a Live USB stick to access the hard drive, recover my data and install a fresh Xubuntu on my PC.

The problem was that I encrypted my home directory. To decrypt it, I needed a password (which, as I mentioned, was gone). Hopefully I recalled that during the encryption process a mount passphrase was generated, and I was informed that I should keep it in case I forget the password. So I could just use this passphrase to get my precious data and the problem was solved.

Well, not exactly. The process of decrypting my home directory was a bit more complicated than I expected and I ran into some problems. Here is how I overcame them.

Approach #1: ecryptfs-recover-private (not brilliant)

The solution recommended by most people on the Internet was to use ecryptfs-recover-private . I did that (running from a Live USB stick), and I discovered my first problem:

Apparently, I had to run this command from my PC’s root directory, not from my Live USB. Nothing a small chroot couldn’t fix:

The encrypted home directory was found without a problem. Without my password, I had to use my mount passphrase, and the files were successfully decrypted!

Or so I thought. The content of the mounted directory looked like this:

The files might have been available now, but they were rather useless without their original names. So I had to find something better.

Approach #2: mount -t ecryptfs (good enough)

Another solution was to mount the encrypted directory. To do this, I first had to add the filename encryption key (fnek) to the keyring (using the mount passphrase):

The important key signature here is the second one ( d06fa6176f780bdb ).

Next I could mount my home directory:

In the first step I provided the mount passphrase. I kept the default values of most of the other options, except for Enable filename encryption. I then entered the key signature generated by ecryptfs-add-passphrase . My files were finally decrypted and they kept their original names! Now I could copy them and install Xubuntu on my PC.

Summary

The decryption process using the mount passphrase turned out to be possible, but not as straigtforward as I expected. I investigated one more approach, one I think would be perfect for this situation: changing the login password for the encrypted home directory. Unfortunately, I couldn’t find a way to do this without knowing the old password.

I hope that this post will help you with decrypting your data. If you find a better solution or spot a mistake in this post, please let me know.

I recently found myself needing to restore data from a backup of an ecryptfs-encrypted Ubuntu home partition. This didn’t go as smoothly as when testing backup restoration (in part because ecryptfs has since fallen out of favor, replaced by LUKS), I thought I’d document the pertinent steps here.

I used a live Ubuntu system from a USB thumb drive, which I booted from to perform the following operations. Once within the live system, I first had to install the ecryptfs tools, as they’re no longer part of the standard distribution, and in fact aren’t even part of the standard software accessible by apt by default.

We start by installing ecryptfs (make sure you’re connected to the web!). From a terminal, execute

Next make sure your USB drive (or whatever you’re accessing) is mounted, and navigate to the .ecryptfs folder it contains. Typically, this is a sibling of the encrypted Private folder. Note that the .ecryptfs node in a user’s home folder could be a link to a different location. If you can’t `cd` into it, use ls -al to see what it was pointing to on the original system and navigate there manually: often the /home/john/.ecryptfs will actually be a link to /home/.ecryptfs/john/.ecryptfs which was broken when performing the backup.

This will prompt you for the login password of the user whose home directory you’re trying to decrypt. After entering it, you’ll see a 32-character passphrase in the terminal.

Many of the following steps are executed as the superuser when they could also be executed as a normal user. However the recovery command must be executed as root, and the steps to add the passphrase to the keyring must also be executed as root or the passphrase won’t be found when the time comes…

Open a new terminal (this is for convenience, you could also just continue in this one) and execute:

And select the first option (Add passphrase key to keyring). Follow the instructions, and you should see

You can copy/paste by selecting the passphrase then middle-clicking (or clicking with both mouse buttons simultaneously if you have no middle button) to paste it: note that the terminal will not provide any feedback that you’ve entered text. Just trust in the system 😉

You may also be told “Passphrase mismatch. Aborting mount” (e.g. if you copy/paste twice or have a typo): repeat the steps until you see one of the success messages above.

(It appears that some users, e.g. on Debian had to execute sudo keyctl link @a @u also.)

Finally, navigate to the encrypted backup again and recover it:

Follow the prompts, and you should be greeted by the following message:

To access your files graphically, open a new terminal (once again for convenience, you could also continue in the same one) and

You can stop reading here, as I just want to chronicle a few missteps and error messages so that poor souls trying to access their encrypted data after a hardware failure can find this when searching for various error messages.

Normally, the recovery process would consist of simply executing ecryptfs-recover-private and following the prompts. This did indeed work flawlessly when testing my backup system. Unfortunately, when things went sideways it didn’t go as planned. The first problem is that the command may not find your encrypted data when scanning the system for it. Then, even if you point it in the right direction (by providing the argument as we did above), it will typically be unable to mount the decrypted data due to permissions snafu. The error message you’ll see will be something like:

It also happened that I was able to successfully mount the decrypted data, but all of the filenames were still encrypted. This was resolved by running

and entering the passphrase we obtained above (the 32 char string). You should see output similar to

Repeating the sudo ecryptfs-recover-private .Private step should then mount the files with decrypted filenames.

Something happened to my laptop recently and whenever I booted it up, it freezes and my cap locks button blinks. I did a little googling on this and it appears that it is caused due to a kernel panic. This might have been caused by me removing my SD card while it was formatting.

My question is this: I have downloaded a new Ubuntu image and booted to my USB and I am trying to save some of the files on my laptop before I reformat it since I can’t seem to fix the kernel panic. When I boot in the USB and go to “Try It”, I am able to load up my HD. (I have encrypted the HD and encrypted my Home Folder). I enter the password to mount the HD but I am unable to access the home folder. Is this because of when I encrypted the home folder as well? If so, I do not get a prompt to enter the password. How would I be able to access the home folder? Thanks!

1 Answer 1

It sounds like you’re using dm-crypt/cryptsetup/LUKS on your whole partition, and also eCryptFS for your old home folder. Since you can already decrypt the whole partition ok, you just need to decrypt your home folder now.

Easiest is probably using the ecryptfs-recover-private script, just run it (optionally telling it where your encrypted private directory is) and it should take care of the rest.

See these for more info:

• man ecryptfs-recover-private
• eCryptfs author Dustin Kirkland’s blog post
• Dustin’s answer to a similar Q – Trying to mount old encrypted home

I had my home folder encrypted during installation by checking “Encrypt my home folder”.

Now, I’d like to reinstall the system, but reuse this home folder.
(I have 2 separate partitions for / and /home . The former is formatted during the reinstall, the later – unformatted and reused. Been using this method without encryption for years – no issues.)

Removing encryption and encrypting everything once more sounds incredibly workaroundish. Depending on how you perform it, it could also leave out temporary unencrypted data ready to be recovered with recovery tools. Even when discarded after the migration process.

[Meta] Possible duplicate:

To all of folks that suggest that this is a duplicate of Why can I not deselect “encrypt my home folder”?:
Well, yes. That thread resolved my problem.
However, I did some research prior to posting this (which I always do) and the answer was nowhere to be found.
That’s because I never saw the bloody form with encryption options disabled.
That’s because I did some thinking on ‘How will I migrate my encrypted $HOME ?’ before I actually got down to reinstalling and potentially carelessly loosing my data. 1
I sincerely hope there’s more like-minded, precautious folk out there (if not, humanity is doomed).

IMO they will find this doubt reworded as “Reusing encrypted home …” helpful.
That’s my opinion, however, it’s up to you what you do with this thread.
After all, the reputation score is the ultimate measure of one’s right.
Isn’t it?

1: Yes, I do have a backup. Still, why resorting to backup when you can easily preserve your original data?

The ROI of InfoSec is the absence of chaos

OK if you are reading this you probably can’t boot your encrypted HDD AND encrypted home directory Ubuntu OS install and you didn’t backup the data you wanted off it regularly enough to be happy. So you are currently experiencing a bunch of frustrating dead ends trying to fix it as you search forums and Ubuntu KB for solutions because none of the other people’s experiences\errors exactly match yours. I can’t judge because I found myself in that very same situation last week but was eventually able to get my data. And figured I’d just throw up the steps I documented in case it would help someone else sometime. The below is kinda the quick and dirty brain dump I had after getting the data and reinstalling, so use at your own risk.

sudo fdisk -l
# find the biggest partition or the one suiting your missing home drive location. For me it was Disk /dev/mapper/ubuntu–vg-root: 461 GiB xxxxxxxx bytes, xxxxxxxxx sectors

#So first you have to mount the encrypted disk with the full disk encrypted passphrase (not the passphrase for you home folder encryption)
cryptsetup luksOpen /dev/mapper/ubuntu–vg-root /mnt/here
Enter Passphrase
# this is different then the “unlock” phrase used in the first link description, but worked for me.

sudo ecryptfs-recover-private /mnt/here

#gives you successful message and a temp folder location of your data. Example: /tmp/
#if you try to get there from the LIVE CD user you get permission denied, do “sudo -i nautilus” and use that GUI filemanager to look at the folder as root.
#. I got a bunch of GTK-CRITICAL errors in the terminal that launches nautlius but it seemed to work anyway

cd /mnt/here
# in your mount you see 2 files “Access your Private Data” and a “Readme” You need to show hidden files so you see the .ecryptfs and .private files. took me too long to realize these seemingly simple steps.

Now goto Link 2. and follow those steps under “Recovering your data manually”

Hi Spice people,

Encryption is not really my thing and i had to test it. I installed Ubuntu 16.04 LTS on an Asus K53E laptop and started enjoying it. I went ahead and encrypted the /home directory and I did some work on it which i forgot to save a copy out of the system. Recently, the hard drive’s SMART reports that the HDD is getting bad, and from that time the system does not boot into desktop. How do i recover the recent important files that are on this encrypted /home directory?

I rad a live ubuntu session, mounted this HDD on this live session and I tried the command

Enter to win a a “Don’t Panic” inspired embroidered hand towel

2 Replies

Sorry i forgot to add that, a hard drive scan showed that 23 sectors on the first sections of the HDD were bad, and the software did recovered them. Could this be the problem? if yes, how do i repair the OS installation so that it can allow me recover files?

I have the passphrass for decryption.

I will suggest courses of action and there are options. First of all don’t risk running that drive any more than you can. Don’t write to it until you have a backup. Just as I finished writing this I see that you have done some recovery actions. However, here are the actions you can try..

It is normal to create a copy of it with the dd command. You will need a spare PC for this because it needs 2 hard drives. An example of this is;
dd if=/dev/sdX of=/dev/sdY bs=64K conv=noerror,sync status=progress

In the above X is you failing disk and Y is the disk that will be the copy of your failing hard drive. Get this wrong and you will destroy all. You can’t do this on a laptop because you need to connect 2 hard drives and will need a PC for the task. The new hard drive needs to be as big or bigger than the original.

Another way is to get an image of that hard drive using Clonezilla. This can be done on the laptop to a usb drive.

Another way is to use a Puppy Linux Distro which has GUI tools under Utility to back up a directory (Pmirror) or a partition or drive (Pudd). Again you can use the laptop and usb storage.

2. It may be possible to rebuild that original install and get it working on a new hard drive and then you will have access to your encrypted Home directory.

3. If a rebuild is not possible the I would reinstall Ubuntu with the same encryption and passwords and then use Puppy Linux to swap the Home directories. I have never tried this but it could work.

Others may have better ideas.

This topic has been locked by an administrator and is no longer open for commenting.

To continue this discussion, please ask a new question.

Snap! Azure AD security, Broadcom’s plans for VMware, GhostTouch, & more

Your daily dose of tech news, in brief. The weekend is almost here, but we have time to squeeze in the latest edition of the Snap. Before we jump in, let’s have a little fun. This image shows software that had two versions that were released on thi.

Upgrading Conference Room

Hey All,I am looking into upgrading a Conference Room at my job. Its been a long time in the making, and they’re finally giving the green light to do so. Here’s its current setup Flat Screen TV mounted onto the wall 2 Front Speakers also mounted onto th.

Who are all these recruiters?

I recently started looking for work because my contract is almost up, and something started happening I have never experienced. Three days ago my phone started ringing off the hook accompanied by tons of email from “recruiters.” Most of them send an email.

Spark! Pro Series – May 27, 2022

Walter P. Chrysler, most people will recognize the last name at least, as the car company he founded bears his name. But on this day, the Chrysler name was attached to some decidedly not an automobile. The year is .

Rough start and poor training at new job.

Started new Job 2 months ago Kept hearing how long are you going to stay? or the last guy did not make it past week 2, I ignored and LOL . Very little training and feel like I’m Being ridiculed when I ask a question? I like being busy, but I don’t like.

I am using a cloned hard drive in attempts to restore some old files.

The cloned drive has 2 users, one with an encrypted home drive, one without. Both are administrators. When I couldn’t get into the main user (with the encrypted home directory), I logged in as the 2nd user and changed the password.

It seems that I somehow broke the relationship between the encryption passphrase and the user. I’m pretty sure I have the passphrase. Is there a way to get to the data?

1 Answer 1

The encrypted home directory (and encrypted private folder) features make use of a random mount passphrase. This mount passphrase is then stored encrypted with the user’s login password. On login, the user’s password is used to decrypt the mount passphrase and the key is used to mount the home directory.

When you perform a normal password change where the old password is requested before entering the new one, the mount passphrase can be re-encrypted with the new login password. When you perform an administrative password change, this can’t be done since the key used to decrypt the mount passphrase is not provided.

In order to get in to the encrypted home directory now, you will need one of the following:

• the old login password for the account.
• the mount passphrase used when you set up the encrypted home directory (you would have been told to write this down somewhere).

If you have either of these, you should be able to access the data by running the following command and following the prompts:

If you don not have either of these pieces of information, then the information is lost. This is by design, since if you could access the data under these circumstances then so could an attacker.

You can use ecryptfs-recover-private .

It will promt for the mount password, unlock the wrapped-passphrase and mount the directory in read only mode under /tmp/ with just single command. Use the flag –rw to mount the encrypted filesystem as read and write.

You can check the man page for more information.

NB: This answer is correct, but another – newer and faster – way exists requiring only a single step with ecryptfs-recover-private . Make sure to check all answers below.

To get access to the data on your stick and to copy files onto it you need to mount the eCryptfs. This involves several steps:

First you should insert your stick. If Ubuntu doesn’t mount it automatically (It usually does.), you should mount it.

Now you should find a directory called .Private . If you did a default installation, this directory should sit in /media/DISK/home/.ecryptfs/USERNAME/.Private . In this example DISK is the directory where your stick is mounted and USERNAME is the name of the user you entered at installation. If you can’t find it yourself open a terminal and enter

I assume in the following steps that the directory is in /media/DISK/home/.ecryptfs/USERNAME/.Private .

You need the mount password. This is different from your login pasword. Enter the following command into a terminal:

You have to enter the login password from the installation of your USB-Ubuntu (not your usual password). The command outputs a passphrase. Write this down or copy it into a file.

The password enables you to unlock the directory. You need to do it in two steps:

The first command adds your passphrase to the kernel keyring and the second tries to mount your .Private to the directory /media/myUSB . If the latte doesn’t exist, you have to create it first:

The mount command will ask again for the login password. Next it will ask for a bunch of stuff.

• Accept the default cipher and key size values ( aes and 16 ).
• Type n for plaintext passthrough.
• Type y for filename encryption.
• The last thing is the FileName Encryption Key (FNEK). Look at the output of the ecryptfs-add-passphrase –fnek command you just typed. There are two lines starting with Inserted auth tok … . Insert the value in square brackets of the second output ( 123456789abcdef0 ).

Now you can access the files in /media/myUSB and can copy from and to the directory or subdirectories.

A large part of my description is from “Live CD method of opening a encrypted home directory”.

I had similar problem and ended here. I was migrating my system to another hard drive and have the same user with encrypted home on both old and new system.

but that directory was in fact symbolic link to

The target directory existed, but pointed to .Private on my new disk.

Correct command should be:

maybe ecryptfs-recover-private should display warning if it detects this pattern. It looks like common mistake.

Welcome to the Linux Mint forums!

• Unanswered topics
• Active topics
• Search

How to recover encrypted /home folder?

How to recover encrypted /home folder?

Post by norm8 » Tue Oct 20, 2020 7:48 am

I’ve encountered a problem when recovering my user folder on linux mint 20 x64 and am not able to view anything I had in there which was very valuable personally, photos, kids schoolwork, mine too,etc, etc…
It strikes me how linux mint, and other linux distros too, so happily nail a checkbox right at the end of the installation process to opt to encrypt the personal filesystem, just like that, when it turns out to be a holy nightmare to succeed in recovering your files after, as in my case and in many others you’ll find on the web.
The best help I have seen is a post here (where I also posted an answer):

And this person solved it being an advanced Linux user, by the look of i; otherwise, I haven’t seen any other single success story concerning this issue, yet.

I wonder why there’s such a neat and “innocent” checkbox to encrypt your personal filesystem when installing linux (Mint 20 x64 in my case) and then when you go back to recover your data, in confidence, it turns out to be a very dark nightmare. (First thing we see in that encrypted folder is justa double click away and your files are back, wrong (grunt). I have not yet seen a single post on the web with a success story with this issue-procedure. I mean, has it ever worked for everyone? must that magic double click go preceded with a pinch of flu powder? Or what are the previous conditions needed in order for that “magic wizard” double-click to just work?
I’ve spent 2 days now trying to get my data back with no success whatsoever. I’ve managed to successfully decrypt to only find that the resulting “decrypted” folder in /tmp/. was still encrypted. Also found it stunning how it basically decryped a 75 GB encrypted /home/user(folder) from another partition to the /tmp/(folder in the active partition in less than 5 or 10 seconds. When checking the (properties of both (still encrypted) folders they where using the same 75 GB EACH!! I believe this tool has to be much improved before just “dumping” a checkbox on the installation process UI to give you the option to encrypt, when after my bet is that many people have suffered this data severance in silence. I’m going to keep on trying with little hope and with the feeling that at the end of this road, all effort won’t yield further outcome. Fingers crossed and would appreciate some help from a kind soul, I (stupidly) had important personal data in there, so yes, I’ve been stupid to use that function before putting it through a test drive myself.

I decided to figure out how to recover data on a disk if the system does not start. It’s better to do it before it happens;)

Since there is no definitive correct answer for Linux Mint 18.3 KDE anywhere, I had to find a solution myself.

1 Answer 1

1. Boot PC from Live CD (Linux mint 18.3 KDE)
2. Run in console: sudo ecryptfs-manager and exit (select 4 => Enter) (see bug 455709 mount: mount(2) failed: No such file or directory )

1. Find your encrypted /home/UserName directory by checking every device in Dolphin. In my case, it is located on a separate volume (But in your case, most likely this path will be inside the home folder like: /media/mint/1234567-1233-1233-32423-1a95b2c5dc68/home/UserName )

1. Open dolphin in home directory “as root”

1. Press Alt + . for show hidden files

Go to .ecryptfs folder inside and try to find .Private folder (in every new Folder you have to “Show hidden files” by pressing Alt + . . )

As final your .Private folder:

1. Press F4 for opening console here
2. Run in console: ecryptfs-recover-private ./.Private (Passphrase is your login PC Password . )

I decided to de-crypt my home folder yesterday. I copied all of my home folder to an external hard drive with

sudo cp -rp /home/brad /media/brad/WD_4TB/brad.backup

I removed the .ecryptfs directory on the external hard drive. I then rm -rf /home/brad . This left what I thought was the empty /home/brad directory, because it said it was being used. This is probably one place I made my mistake. I logged out and logged in as tempuser. Due to temporary insanity I used mv instead of copying.

sudo mv /media/tempuser/WD_4TB/brad.backup /home/brad

As you can guess this created a subdirectory in /home/brad and I next moved the files from the subdirectory back into /home/brad.

I was able to re-login as brad and all of my data was present where it was before (i thought now unencrypted). When looking at my files I got a message the cache needed updating and it required authentication. I initiated the cache update. Later I rebooted the machine. When I login as brad it returns to the login screen. When I look at the files from another account I see

ERROR: Encrypted private directory is not setup properly

INFO: Searching for encrypted private directories (this might take a while).

find: ‘/run/user/1001/gvfs’: Permission denied

when I run from the GUI

Sorry, but you cannot execute commands from a remote site. This is disabled due to security considerations.

when I run from the command line I get this.

my data seems to be encrypted in .Private

I have logged into user brad from the command line and the same commands give pretty much the same answer. I’m pretty sure startx doesn’t work because my home directory files are missing.

If I can decrypt my data I will copy it back off to the external hard drive. At that point I can find a way to replace or fix my brad user account.

by ruchi · Published April 27, 2011 · Updated April 27, 2011

Sponsored Link

The program can take a target encrypted directory on the command line.If unspecified, the utility will search the entire system looking for encrypted private directories, as configured by ecryptfs-setup-private.

If an encrypted directory and a wrapped-passphrase file are found, the user is prompted for the login (wrapping) passphrase, the keys are inserted into the keyring, and the data is decrypted and mounted.

If no wrapped-passphrase file is found, the user will be prompted for their mount passphrase. This passphrase is typically 32 characters of [0-9a-f]. All users are prompted to urgently record this randomly generated passphrase when they first setup their encrypted private directory.

The destination mount of the decrypted data is a temporary directory,in the form of /tmp/ecryptfs.XXXXXXXX.

Procedure to follow

If you find yourself in a situation where you need to recover your Encrypted Home or Encrypted Private directory, simply:

1)boot the target system using an Ubuntu 11.04 Desktop LiveCD

2)make sure that your target system’s hard drive is mounted

3)open a terminal and run ‘sudo ecryptfs-recover-private’follow the prompts

access your decrypted data and save somewhere else

The utility will do a deep find of the system’s hard disk, looking for folders named “.Private”, and will interactively ask you if it’s the folder you’d like to recover. If you answer “yes”, you will then be prompted for the login passphrase that’s used to decrypt your wrapped, mount passphrase. Assuming you have the correct credentials, it will mount your Encrypted Home or Private directory in read-only mode, and point you at the temporary directory where it’s mounted.

Audio Preview

• Graphic Violence
• Explicit Sexual Content
• Hate Speech
• Misinformation/Disinformation

Recovery of an (en)crypted home directory in a ‘buntu based system

This is going to be the archetypal “How I Did It” episode because if fulfills the criterion of dealing with an issue most listeners will most likely never have to resolve, but might be invaluable to those few who some day encounter the same problem, how to recover an encrypted home folder on an Ubuntu system.

I enabled home folder encryption on installation of a Linux Mint 8 system some years back and it never gave me trouble until the day that it did. Suddenly, my login would be accepted, but then I would come right back to GDM. Finally I dropped into a text console to try to recover the contents of my home folder, and instead found two files, Access-Your-Private-Data.desktop and README.txt . README.txt explained that I had arrived in my current predicament because my user login and password for some reason were no longer decrypting my home folder (Ubuntu home folder encryption is tied to your login, no additional password is required). Honestly, until I lost access to my files, I ‘d forgotten that I’d opted for encryption. I found two articles that described similar methods of recovery. I’d tried that following their instructions and failed, probably because I was mixing and matching what seemed to be the easiest steps to implement from the two articles. When I took another look at the material weeks later, I discovered I missed a link in the comments that led me to an improved method added at Ubuntu 11.04 that saves several steps:

Boot to an Ubuntu distribution CD (11.04 or later)

Create a mount point and mount the hard drive. Of course, if you configured you drive(s) with multiple data partitions (root, /home, etc) you would have to mount each separately to recover all the contents of your drive, but you only have to worry about decrypting your home directory. If you use LVM, and your home directory spans several physical drives or logical partitions, I suspect things could get interesting.

$sudo mkdir /media/myhd

/media is owned by root, so modifying it requires elevation

You need to confirm how your hardrive is registered with the OS. I just ran Disk Utility and confirmed that my hard drive was parked at /dev/sda, that meant that my single data partition would be at /dev/sda1

$sudo mount /dev/sda1 /media/myhd

Do a list on /media/myhd to confirm the drive is mounted

The new recovery command eliminates the need to re-create your old user

$sudo ecryptfs-recover-private (yes, ecrypt not encrypt)

You will have to wait a few minutes while the OS searches your hard drive for encrypted folders

When a folder is found, you will see

INFO: Found [/media/myhd/home/.ecryptfs/username/.Private].

Try to recover this directory? [Y/n]

You will be prompted for you old password

You should see a message saying your data was mounted read only at

I missed the mount point at first, I was look for my files in /media/myhd/home/myusername

If you try to list the files in /tmp/ecryptfs., you will get a “Permission Denied” error. This because your old user owns these files, not your distribution CD login

[You will probably want to copy “/tmp/ecryptfs.” into your terminal buffer as you will need to reference it in commands. You can select if with your mouse in the “Success” message and copy it with c, paste it later with v

I tried to take ownership of /tmp/ecryptfs., I should have thought that would have worked.

From my command prompt, I can see my user name is “ubuntu”

$ sudo chown -R ubuntu /tmp/ecryptfs.

-R takes ownership of subdirectories recursively

It’s a good time to get a cup of coffee

Next, we need to copy the files in our home directory to another location, I used an external USB drive (it was automounted under /media when I plugged it in). If you had space on the original hard drive, I suppose you could create a new user and copy the files to the new home folder. I decided to take the opportunity to upgrade my distro. Some of the recovered files will wind up on my server and some on my newer laptop.

One could run Ubuntu’s default file manager as root by issuing “sudo nautilus &” from the command line (the “&” sends the process to the background so you can get your terminal prompt back)

Before copying, be sure to enable “View Hidden Files” so the configuration files and directories in you home directory will be recovered as well. As I said, there are select configuration files and scripts in /etc I will want to grab as well.

I had trouble with Nautilus stopping on a file it couldn’t copy, so I used cp from the terminal so the process wouldn’t stop every time it needed additional input.

$ cp -Rv /tmp/ecryptfs. /media/USBDrive/Recovered

Of course the destination will depend on what you’ve named your USB drive and what folder (if any) you created to hold your recovered files

-Rv copies subdirectories recursively and verbosely, otherwise the drive activity light may be your only indication of progress. The cp command automatically copies hidden files as well.

Because of the file ownership difficulties, I could only copy the decrypted home folder in its entirety,

I still had trouble with access do to to ownership once I detached the external drive and remounted it on my Fedora laptop, but I took care of that with:

$ su -c ‘chown -R mylogin/media/USBDrive/Recovered’

Welcome to the Linux Mint forums!

• Unanswered topics
• Active topics
• Search

[SOLVED] recovering encrypted /home

[SOLVED] recovering encrypted /home

Post by fabien85 » Fri Apr 07, 2017 4:17 pm

Hi,
so I am testing installation with an encrypted home. One drawback of encryption is that it’s harder to recover your files in case of a system crash. So before venturing further, I wanted to test and find the methodology to be able to read my encrypted home with a live USB. That turned out much harder than I thought.
I will describe the things I have tried, maybe someone will be able to point out mistakes.
In the install I did, not only is the home encrypted, it’s also on a separate partition, maybe that can explain some of my difficulties.

So I booted my live USB (LM18.1 Cinnamon, I checked the ISO and the integrity of the medium). Then I first followed instructions from howtogeek which tell to mount the partition, open a terminal and issue

It’s quite possible I didnt give the good arguments to “mount-t ecryptfs”, I dont really understand what I should give here so I gave up that route.

Next I adapted instructions from . om-livecd/, mixed with chroot instructions from sdb2 was the / and sdb3 the /home of the installed system (the computer has another internal hard drive sda that I’m not using at the moment), so I did

$ , and whoami returned “fabien”.
Full of hope I issued the final command

so that didnt work.
I also tried sudo mount -a to mount the fstab, still there is only Access-Your-Private-Data.desktop README.txt in my home.

Only thing that worked is that, still being chrooted, I issued

Now that’s quite a long and complicated route. Did I go wrong somewhere ?

Edit:fixed typos, added references I used

Re: recovering encrypted /home

Post by fabien85 » Sat Apr 08, 2017 7:52 am

you will asked whether you want to recover this directory (Yes! why on earth would you do this command to say No . ), then it says it found your wrapped-passphrase and asks if you know your login passphrase, if so you enter it and the decrypted directory gets mounted at /tmp/ecryptfs.something
By default it gets mounted read-only (but you can change that by adding the option –rw to ecryptfs-recover-private). And it has owner the uid of username (e.g. the default 1000 if the user was the first to be created on the installed system), which I guess makes sense, but on a live USB your user is “mint” with uid 999 so you need to use sudo to be able to read the /tmp/ecryptfs.something, cd into it etc. A small complication (but that would be the same with a normal unencrypted directory I’m guessing).

I didnt get yet the method to mount the private data at /home/username as it should, through the chroot method of . om-livecd/.
I see this could be useful in some cases, as you preserve the whole structure of the filesystem.
But I will persist, I found many more detailed instructions on . eDirectory. Will report if I succeed.

Re: recovering encrypted /home

Post by fabien85 » Wed Apr 12, 2017 11:57 am

I retried and the mount through chroot worked this time. I think the only difference is that I issued sudo -s from the start.
Since last time I even made the situation more complicated by having another partition on another hard drive encrypted and mounted at /home/fabien/data (i.e. after the encrypted home is mounted. Two levels where things can go wrong)

My partitions : / = sdb2 ; /home = sdb3 ; /data = sda2 (later decrypted and mounted at /home/fabien/data)
What I did :

and bingo the /data partition is now decrypted and mounted at /home/fabien/data
So I’m now basically chrooted into my full system with all partitions mounted as they should on a running system. I can copy files and everything via the chrooted terminal, or graphically using nemo as root (right click on a folder > Open as root).

Welcome to the Linux Mint forums!

• Unanswered topics
• Active topics
• Search

Recover files from encrypted Home folder

Recover files from encrypted Home folder

Post by smssms » Sat May 18, 2013 11:00 am

I want to get some files off of my natively encrypted Home folder but I can no longer get Mint to boot – how can I get the files?

BACKGROUND:
Had dual boot with Windows & Mint and all was well.
One day the HDD would not boot at all.
Tried a few things, and Boot-repair run from a Live USB of Ubuntu was the only one that did anything.
Now the HDD will boot into Windows, but there is no sign of Grub or then Mint at startup any more.

I DO have the passphrase for the encrypted partition.

I’m not actually that bothered about saving the Mint install, but I do want the files out of my Home folder.

Appreciate any tips on how to get my files back – Thanks

Re: Recover files from encrypted Home folder

Post by xenopeek » Sat May 18, 2013 11:10 am

Re: Recover files from encrypted Home folder

Post by smssms » Sat May 18, 2013 11:15 am

Thanks for the quick reply Xenopeek.

I’ll have a stab with that and see how it goes. Only problem at the minute is that I do not have a Mint Live USB/CD, so have to sort that first.

Re: Recover files from encrypted Home folder

Post by smssms » Sat May 18, 2013 11:41 am

I can mount the Windows partitions (in terminal and Disk Utility), but not the Linux partitons.

In Disk Utility they just do not have an option to mount and when I try

Re: Recover files from encrypted Home folder

Post by xenopeek » Sat May 18, 2013 12:24 pm

Re: Recover files from encrypted Home folder

Post by smssms » Sat May 18, 2013 12:31 pm

Re: Recover files from encrypted Home folder

Post by smssms » Sat May 18, 2013 1:10 pm

Thanks for all your help.

With a bit more work on e2fsck to sort out the superblock I got most of the way through your instructions.

Then I had the opposite of a eureka moment when I realised I had the passphrase for the wrong HDD.

So I’m going to have to hunt down the right passphrase (if I stored it!) or work out how to get in with the system password.

Re: Recover files from encrypted Home folder

Post by cryptotheslow » Sat Aug 03, 2013 10:32 am

I know this is an old thread, but I thought I would add a useful tidbit of information for those who may look at it in the future.

For a while now ecryptfs provides a utility “ecryptfs-recover-private” that automates the recovery process without having to go through the palaver of chroot etc.

Re: Recover files from encrypted Home folder

Post by smssms » Sun Aug 04, 2013 1:00 pm

cryptotheslow wrote: I know this is an old thread, but I thought I would add a useful tidbit of information for those who may look at it in the future.

For a while now ecryptfs provides a utility “ecryptfs-recover-private” that automates the recovery process without having to go through the palaver of chroot etc.

• Important Notices
• ↳ Rules & Notices
• ↳ Releases & Announcements
• ↳ Main Edition Support
• ↳ Beginner Questions
• ↳ Installation & Boot
• ↳ Software & Applications
• ↳ Hardware Support
• ↳ Graphics Cards & Monitors
• ↳ Printers & Scanners
• ↳ Storage
• ↳ Sound
• ↳ Networking
• ↳ Virtual Machines
• ↳ Desktop & Window Managers
• ↳ Cinnamon
• ↳ MATE
• ↳ Xfce
• ↳ Other topics
• ↳ Non-technical Questions
• ↳ Tutorials
• Debian Edition Support
• ↳ LMDE Forums
• ↳ Beginner Questions
• ↳ Installation & Boot
• ↳ Software & Applications
• ↳ Hardware Support
• ↳ Networking
• ↳ Tutorials
• ↳ Other Topics & Open Discussion
• ↳ LMDE Archive
• Interests
• ↳ Gaming
• ↳ Scripts & Bash
• ↳ Programming & Development
• Customization
• ↳ Themes, Icons & Wallpaper
• ↳ Compiz, Conky, Docks & Widgets
• ↳ Screenshots
• ↳ Your Artwork
• Chat
• ↳ Introduce Yourself
• ↳ Chat about Linux Mint
• ↳ Chat about Linux
• ↳ Open Chat
• ↳ Suggestions & Feedback
• International
• ↳ Translations
• ↳ Deutsch – German
• ↳ Español – Spanish
• ↳ Français – French
• ↳ Italiano – Italian
• ↳ Nederlands – Dutch
• ↳ Português – Portuguese
• ↳ Русский – Russian
• ↳ Suomi – Finnish
• ↳ Other Languages
• ↳ Čeština-Slovenčina – Czech-Slovak
• ↳ Magyar – Hungarian
• ↳ 日本語 – Japanese
• ↳ Polski – Polish
• ↳ Svenska – Swedish
• ↳ Українська – Ukrainian

• Board index
• All times are UTC-04:00
• Delete cookies
• Contact us

Powered by phpBB® Forum Software © phpBB Limited

This question does not appear to be about Unix or Linux within the scope defined in the help center.

Closed 4 years ago .

Years ago I installed Ubuntu and encrypted my home directory.

I can still log in as normal, I know my password and I have access to my files.

Just now, installing Lubuntu on another machine, I saw this:

I don’t remember writing down my passphrase for recovering my encrypted home directory when I set it up years ago.

So hypothetically I guess the disaster scenario is my root partition gets corrupted but not my home partition, or something like that, and I want to be able to recover my /home data.

I can log in and read my encrypted /home as normal right now. How do I find the recovery passphrase?

1 Answer 1

_{[On the off-chance that there’s not something funny about this question, maybe there’s a legitimate language barrier or some other issue, might as well make it an “official answer”]}

You might want to make a backup of eCryptfs’s important files too, in /home/.ecryptfs/ /.ecryptfs/ especially the wrapped-passphrase file – if it gets damaged your home’s really inaccessible even if you remember the passphrase.

The ecryptfs-unwrap-passphrase tool takes that file and your passphrase, and reveals the actual “random” encryption key.

Your actual encrypted files are stored in /home/.ecryptfs/ /.Private/ , but alone they’re useless without the wrapped-passphrase file + passphrase.

You should have a backup of any important files in your encrypted home, it’s a lot easier than trying to recover from failing drives or overwritten encryption.

I want my home folder to be encrypted so that when my pc is stolen people will not be able to simply read out everything on my home folder (using a live cd). So I clicked the option “require my password to log in and to decrypt my home folder” in the installation process.

When I first logged in it said something about a passphrase or something. I was busy doing some other stuff and clicked it away. But now I don’t know if my home folder is actually encrypted, and whether I still need to set a passphrase (in case my system crashes..).

Could somebody give me some tips on how to make sure its properly encrypted and how I would be able to recover things in case it goes wrong?

@ Ubunturooster
I started my pc with the Ubuntu live cd and went into the terminal (which I am not so good at, so I might need some help). I typed “cd /media/bed300d6-etcetc” (the HDD). I then typed “cd kramer” but it says permission denied. I then tried “sudo cd kramer and it says command not found.
Does this mean my home folder is encrypted?

@ CharlesA
But I never wrote the passphrase down. Am I still able to get it from somewhere? (I can still log into the system)

Is that the only way of checking whether my home folder is encrypted? (since it takes some time to download and burn 700 mb..)

Also, do you know of any way to get the passphrase if I didn’t write it down the first time.

how I would be able to recover things in case it goes wrong?
At the moment, it’s really difficult (and impossible for a layperson) to recover an encrypted folder — even when you do have your 32-character unlock code. I did manage when a friend’s computer crashed, but only after a tremendous amount of searching and experimentation.

There are moves afoot to make it easier to handle encrypted folders, but probably that will be a while coming.

The best thing to do is to make proper backups. That way, when something goes wrong, you have access to all your data. If necessary, you can reinstall and restore your data.

@ Pappy
Thanks for the explanation. I indeed already make backups, but I would still like to have my home folder encrypted (in case my pc gets stolen) and while I’m at it, why don’t I try to also get this 32-character passphrase?

So does anybody know whether it is still possible to get this passphrase from somewhere?

So does anybody know whether it is still possible to get this passphrase from somewhere?
Yes, it’s possible, but I found it so hard to discover how, that I’m afraid I don’t have the answer for you.

Is your folder encrypted? Have a look at the file /etc/fstab. If you see something called “ecryptfs” on the same line as “/home” then, I believe — someone tell me if I’m wrong — your folder is encrypted.

Sorry to be so vague, but I find encrypted folders really hard to unravel.

Thanks for the info. You don’t happen to have a link or anything to find out how to find my passphrase?

I had a look in the file you mention, but I don’t see anything with “crypt” in it.

When I start up my pc however, it shortly shows some line which displays my home partition name and something like “init ecrypt”. At least I saw the word “crypt” in it. Doesn’t that mean that it is encrypted?
Also I am pretty sure I chose the “require my password to log in and to decrypt my home folder”, so that would make the home folder encrypted right?

Well, the main thing is that I am after the passphrase actually.. Any help on that possible? 😀

sounds encrypted. Of course w/ backups, if someone steals them when they are not encrypted.

Sorry, can’t help w/ passphrase

I mentioned knoppix because ubuntu liveCD does not give any root privileges (required for mounting other OS partitions)

er, yes it does. any live cd will give you full root access.

if you go into an ubuntu live cd and simply open your hard disk containing your home folder, it should show your folders. if it doesn’t show them as you see them when you log in then it’s encrypted.

i haven’t played much with it but you need the password that you forgot to note down if you ever have to reinstall and want to keep your files

just run ecryptfs-unwrap-passphrase and voila; it’s there.. 🙂

/.ecryptfs/wrapped-passphrase
it prompts you for “Pasphrase:” but it really just wants your normal login password. after entering it it will print the passphrase that you would need for the long arduous process of recovering your data (I think). Save that passphrase somewhere apart from your laptop.

I already saved it in a file and I just put it on a memory stick which I will hide away somewhere else.

Here are some links that I have. Watch out: The procedures in the first two links are incomplete, but they do give you some important background.

eCryptfs official Ubuntu Community documentation ()
Ubuntu’s encrypted home directory () (three pages)
eCryptfs “read me” document ()
Recovering Files from eCryptfs Encrypted Home ()

And here is something for you to vote on:

Encrypted home directory GUI tool is needed ()

Does this mean that all They have to do is. Steal (break in Hack?) someones PC laptop. then post on these forums and viola They have stolen all your private encrypted data. The thought police will love this one.

no, because to recover the encryption passphrase you need to log in to the user account that has the encrypted files, by which stage the information is decrypted anyway.

no, because to recover the encryption passphrase you need to log in to the user account that has the encrypted files, by which stage the information is decrypted anyway.
Which leads me to remind you that your data is only as safe as your password. If your password is a simple word, hackers with physical access to your hard drive can probably break into it in a few minutes.

The issue: I changed my password earlier today, but I must’ve made a typo, because I couldn’t log in afterwards. I booted into the Grub menu and started a passwordless root shell to reset my password. This was successful, as I could now enter the new new password and get past the login screen. However, as soon as I do that, I get an error that says:

I have the option to hit ‘OK’ which will take me back to the login screen. If I try to login again, I get the exact same message.

Note: where it says [username] in the above text, the actual error displayed my actual username. I am, however, paranoid when it comes to my online identity, hence I censored it in the error printed above.

I have tried:

Log out and log back in as your original user account. Do not reboot your system before logging back in!

After you log in, click the Run this action now button to create a recovery passphrase. Keep this passphrase somewhere safe – you’ll need it if you have to manually recover your files in the future.

You can run the ecryptfs-unwrap-passphrase command to view this passphrase at any time.

When you set up an encrypted home directory while installing Ubuntu, your swap partition is also encrypted. After setting up home directory encryption, you’ll also want to set up swap encryption. To do so, run the following command in a terminal:

Note that an encrypted swap won’t work properly with Ubuntu’s hibernate feature – which is disabled by default, anyway.

After restarting your system once or twice and verifying everything works properly, you can clean everything up. You can remove the backup home folder located in your system’s /home directory. Run Nautilus as gksu nautilus to do so.

If you’re on Linux, you already have the idea of the security level of this awesome operating system. This has set up all the systems in such a manner that until you give the permission, there’s hardly any malware to run into your system. However, despite the security, your data isn’t completely secured. Those who have physical access to your system can easily extract your sensitive data.

For solving this issue, you can set up encryption for your “home” folder. This way, no one can extract sensitive information out of your system and even if they do so, it’ll be nothing more than garbage & unreadable data. Let’s get started with encrypting your “home” folder on your Linux distro.

Note that I’m using Linux Mint. But the system procedure is the same for all the other Linux distros. We’ll be using a tool named “EcryptFS”.

Downloading & Installing the tool

According to your Linux distro, install the tool first.

Ubuntu + Ubuntu-based

If you’re running Ubuntu or Ubuntu-based distro, run this command:

Debian

Run this command:

Fedora

For Fedora users, this is the required command line:

OpenSUSE

Arch Linux

If your Linux distro or distro-base isn’t listed here, then you have to build it from source. You can also check out the official EcryptFS download page. For any issue with the building, you may need to take help from EcrypFS documentation.

Encrypting the “home” folder

During the encryption process, we have to make a temporary user for performing the encryption tasks. After completing the process, we’ll delete it. This second user is needed as you can’t directly encrypt your “home” folder while logged into the account.

• Add a user account with the name “encrypt-admin”.

• Now, it’s time to start encrypting. Run this command:

• Note that if you want to encrypt multiple accounts, you have to run this process multiple times.

Now, exit the temporary account and login to your main account.

Adding encryption password

After logging in to your original account, run this command:

This will give you the option of entering a password for the encrypted “home” folder.

For fully enjoying the feature, restart your Linux system.

Recently, Ubuntu has released their latest edition – v18.04 LTS. Check out every new feature of Ubuntu 18.04 LTS.

Recover encrypted Ubuntu home directory (ecryptfs) from a live CD

So, my Ubuntu 9.10/Karmic installation died. Again. Probably some software update that screwed up my fairly complicated install.

I have a raid1 (mirrored disks). On top of that I run LVM with one volume group, vg0, that has two logical volumes, one for home and one for root (everything else). Additionaly /boot is NOT on LVM but lies besides everything, still raided though.

Booting stopped. My home directory is encrypted so I can’t just copy everything out and reinstall. Bugger. Of course I can copy the encrypted data and hope to get it running in the new install, but that doesn’t feel safe.

Install tools necessary for RAID and LVM:
sudo apt-get install lvm2
sudo apt-get install mdadm

Bring up the RAID array as I always do:
sudo mdadm –assemble –scan
sudo less /proc/mdstat

Check if the volume group and the logical volumes are active.
sudo vgdisplay
sudo lvdisplay

If necessary one could make the volume group active with
sudo vgchange -a y

Create somewhere to mount the logical volumes
sudo mkdir /mnt/homevol
sudo mkdir /mnt/rootvol

Do not stand in any of the newly created directories, or you will not see the mounting getting done:
sudo mount -t auto /dev/vg0/homevol /mnt/homevol/
sudo mount -t auto /dev/vg0/rootvol /mnt/rootvol

Hmm, maybe /dev/mapper/vg0-rootvol and /dev/mapper/vg0-homevol was used here instead, I don’t remember.

Next, we’re about to prepare for chrooting in order to make the file system look like the file system on the machine when it was running without the live CD.

We need to mount some stuff started on the live CD into the directory we’re about to chroot into. These things must be available after chroot.

sudo mount –bind /dev /mnt/rootvol/dev/
sudo mount –bind /dev/shm /mnt/rootvol/dev/shm
sudo mount –bind /proc /mnt/rootvol/proc
sudo mount –bind /sys/ /mnt/rootvol/sys

Also make the home volume available under the to be root.
sudo mount –bind /mnt/homevol/ /mnt/rootvol/home/

Now it is time to change the root.
sudo chroot /mnt/rootvol/

Now the file system looks almost like it did when the machine was up and running. Specifically the user database is in the correct position, which is necessary because ecryptfs will only do its magic on home directories owned by the user.

Let’s become the user that owns the home directory.
su – klas

Time bring the files back:
ecryptfs-mount-private
cd /home/klas
ls

The password that the system asks for is the users (klas’) password.

So I wanted to clean a directory and subdirectories from non .doc|.docx files and I ran the following command:

and I just deleted my home directory (hundreds of thousands of files. ). My last save is not so recent. It’s not the end of the world but it would help a lot if I could recover it. So my questions are:

1) why did it go wrong?

2) can I recover the deleted directories and files? Obviously they’re not in the Trash. Would testdisk or photorec help?

Thanks for the help!

2 Answers 2

1. The problem in your command is the !(*.doc|.docx) construct. The * expands to every file and directory.
2. You have to cease any further writes to the file system because when files are removed and unlinked (no remaining hard links to them), the file system free the blocks previously allocated for the deleted file, these blocks are allocated to new files and their contents overwritten. So to recover your files, you can use the photorec command ( sudo apt-get install testdisk for debian). It will open a text based window so follow its instructions. The files will be recovered with different names generated by system.

See @Johan Myréens comment and @Dababi’s answer.

2) can I recover the deleted directories and files? Obviously they’re not in the Trash. Would testdisk or photorec help?

Maybe. In my humble (and hard earned) experience, the only foolproof way to recover files are via backups. Yes, there are tools claiming that they can recover deleted files. I have had mixed (to say the least) experiences with those. More often than not, the files that are recovered are also corrupted and thus useless.

Although this is not an answer you may like, my answer is still: make regular backups of important files. Because sooner or later, “something” will happen, and when it does you can simply restore your files from whatever media your backup is stored (physical drive, server, “cloud” etcetera).

• Page History
• Login to edit

There are two ways to encrypt files and directories within your home directory. You can either place files in an encrypted “Private” directory, or you can encrypt your entire Home directory.

Ubuntu allows you to encrypt a “Private” directory within your home directory. This provides strong cryptographic protection of your most sensitive data, such as your documents and keys. This directory is automatically mounted on login, and unmounted on logout. When the directory is unmounted, an attacker only has access to your encrypted data (AES256), and not the files or directories stored within.

The encrypted data is in $HOME/.Private, and when mounted, the decrypted data is in $HOME/Private. Some important configuration information is stored in $HOME/.ecryptfs.

During the installation process, there is a question in the installation for configuring the Encrypted Private directory. If you want to setup your Encrypted Private directory later, just run ecryptfs-setup-private.

Ubuntu makes it possible to set up Home directory encryption using the Desktop CD. On the User Setup screen, after choosing a username and a password, the user can choose one of:

• log in automatically
• require a password to log in
• require a password to log in and decrypt your home directory

Users wanting an Encrypted Home directory should choose the 3rd option.

If the administrator wants to add a new user with an encrypted home directory after the initial installation, use: sudo adduser --encrypt-home. This requires the ecryptfs-utils package.

If the user wants to migrate from a non-encrypted home directory to an Encrypted Home directory, follow the instructions here:

In the Ubuntu 9.04 setup, the user’s encrypted data is located in $HOME/.Private, but is only available when $HOME is not mounted. The user’s configuration data is in /var/lib/ecryptfs/$USER.

Note that this has been problematic for some users who remember to back up their /home partition, but neglect to back up their /var/lib/ecryptfs partition. This has been fixed in Ubuntu 9.10.

In the Ubuntu 9.10 setup, the user’s encrypted data is located in /home/.ecryptfs/$USER/.Private, and the user’s configuration data is located in /home/.ecryptfs/$USER/.ecryptfs. As such, all of the user’s pertinent data is self-contained in /home.

There are a few minor caveats that one must keep in mind about these encrypted configurations.

When you are not logged into your system, data in your home directory is not accessible in plain text. This, of course, is by design. This is what keeps an attacker from gaining access to your files. However, this means that:

Your cronjobs may not have access to your Home Directory

SSH public key authentication into your system also will not work, unless you put your public key somewhere outside of your home directory and symbolically link it to your unmounted $HOME/.ssh/authorized_keys.

You can put your authorized_keys directly in your unencrypted home directory by following these directions without the need for linking it anywhere else.

Also, it is strongly recommended that you encrypt your swap space. Users installing from Ubuntu 9.10 and selecting the Encrypted Home option will automatically have encrypted swap space. Other users can run sudo ecryptfs-setup-swap. This is critically important, because your home directory data will appear as cleartext in memory, as the kernel reads your encrypted data. If the kernel swaps this data to disk, it could potentially leak your decrypted data back to disk, totally defeating your Encrypted Home. Encrypted Swap solves this problem. However:

• Hibernation will not work. Actually, hibernation will work just fine. But you can’t resume. There are ways around this, but it involves choosing a password to use for your swap encryption, and entering that password every time you boot your system, and sharing that password with anyone else that might want to resume the system.
• This is a known, wishlist issue that we hope to solve for Ubuntu 10.04.
• You may be able to avoid these problems by running without a swapfile.

Beware of information from an encrypted directory leaking out (the linked article is Windows-centric but the same principle apply to Linux).

• It is unclear if and if so, how much, using an encrypted home impacts performance, especially on low-end machines
• What are the risks/chances of a breaking file system for recovering encrypted data?

EncryptedHome (последним исправлял пользователь imnichol 2014-11-24 01:11:48)

During Positive Hack Days V, I made a fast track presentation about eCryptfs and password cracking. The idea came to me after using one feature of Ubuntu which consists in encrypting the home folder directory. This option can be selected during installation or activated later.

If you select this option, nothing changes for the user except that data in his home folder is encrypted. I was interested to know how this process works since the passphrase for decryption is never requested. I discovered that eCryptfs is included in the GNU/Linux kernel and tools called ecryptfs-utils are used to setup the home folder encryption by the Ubuntu distribution.

After reading the code, I discovered how the encryption is performed. First a 16-byte random passphrase is generated. This passphrase will be used with AES-128 to encrypt and decrypt the data in the folder. This passphrase is stored encrypted in the file

The process of encrypting the passphrase is called key wrapping. To generate a wrapping key used to wrap the passphrase, an 8-byte salt and a password are concatenated and given as input to SHA-512. The result is hashed again 65535 times. As shown by the following figure:
The 16 first bytes of the result are the wrapping key. The intermediate result is hashed one more time and the 8 first bytes of this operation represent the signature of the wrapping key. The passphrase is encrypted with the wrapping key using AES-128 and stored with the signature in the wrapped-passphrase file as shown here:

To unwrap the key the process is similar, the salt and the password are hashed 65536 times.

The result is hashed one more time. If the 8-byte signature obtained matches the one stored in the file then eCryptfs detects that the correct wrapping key has been generated. Thus it can unwrap the passphrase for file decryption.

From an adversary’s point of view, to recover the passphrase, the naive approach would be to brute-force the passphrase with encrypted data. However since it is randomly generated over 16-bytes the brute-force approach is not practical. The adversary can also try to brute-force the password used during the key wrapping and thus he would be able to generate the wrapping key and recover the passphrase. He could use precomputed dictionaries or rainbow tables over the signature to recover the password but as a salt is used in the wrapping process this makes such attacks much more difficult.

At this point, I noticed that, for Ubuntu systems, the password used in the wrapping process is directly the login password. This explains why no further information is asked when performing home folder decryption. It means that an adversary who is able to crack the wrapping password will not only obtain the passphrase but also the user password. Next I looked how the salt is generated since it is not stored anywhere in the wrapped-passphrase file. I finally found in the code that ecryptfs-utils is looking for a salt in the configuration file

If the file does not exist, a default value of 0x0011223344556677 is used. This behavior had already been noted previously.

For a system using eCryptfs, as the configuration file is stored in the (now encrypted) home folder it cannot be found and so the default salt value is used to decrpyt the home folder.

In practical terms this means that, for a system to use this version of eCryptfs the salt value used must be the default value. If not, the initial encryption, using a salt from

/.ecryptfsrc would never be decrypted correctly as, now unable to find the config file, eCryptfs would apply the default salt at the moment of decryption.
Cleary a precomputed dictionary attack or a rainbow table attack can be mounted against such a system in order to crack the user passwords. To set-up such an attack, I looked at my favorite cracking tool: John the ripper (JTR) and I discovered that the algorithm was already implemented in the 1.8.0-jumbo version. The format is

where the pink value is obviously the salt and the green value is the signature corresponding to the password you want to crack.

I also noticed a Python script ecryptfs2john.py in JTR which directly read the wrapped-passphrase file and convert it to the correct format. The algorithm is also implemented in hashcat. As a proof of concept, I computed a dictionary of 14 million signatures based on the famous rock you dictionary. It took me about one month on my personal computer. But with this dictionary it is now possible to reverse a signature with a single look up assuming the password was in the rock you list of password. This dictionnary is available at

Of course we notified the ecryptfs-utils developers about the problem with Ubuntu distributions, a CVE was opened and quickly corrected. They issued a new file format for the wrapped-passphrase file. It now starts with 0x3a02 . The salt is generated from /dev/urandom/ and stored in the same file by default. The old version files are automatically converted after the update and a logoff. To ensure the correction was successfully applied to your system you should check the wrapped-passphrase file. The new file contents should look like this:

Even with the correction the user password is still exposed to bruteforce attack with a randomly generated salt. However the standard Linux password hashing is 5000 iterations of SHA-512 which is easier to crack compared to the 65536 iterations of eCryptfs. As such, and due to the dual use of this password the eCryptfs implementation is a less interesting target for a password cracker. In the future it could be interesting if Argon2, the winner of the Password Hashing Competition, could be used eCryptfs.

Recently I installed Ubuntu 12.10 to a new hard disk and wanted to copy over some configuration bits from the Ubuntu 12.04 installation on an older hard disk. After a bit of Googling I found many tutorials for mounting an encrypted home directory from the Ubuntu LiveCD, but none for mounting it from a secondary drive while running a full Ubuntu installation on a primary drive.

The instructions below are brief, but my initial attempt to get this working was met with failure. I will explain my naive approach along with the (surprising) results at the bottom of the post.

Finally, some terminology:

• primary disk – refers to the new disk currently running Ubuntu
  • I want to transfer files from the secondary disk to this disk
  • In my example this disk contains an Ubuntu 12.10 installation
• secondary disk – refers to the old disk containing valueable files
  • I want to transfer files from this disk to the primary disk
  • In my example this disk contains an Ubuntu 12.04 installation

from the command line

from the GUI

Note that this is not the path to the old home directory (e.g. /home/$USER/.ecryptfs) but instead the parent directory. This is important and will be explained at the end.

Your old home directory is mounted as ready-only in /tmp. If you need write access to that data then run ecryptfs-recover-private with the –rw option.

When you are done copying the data from the secondary disk to the primary disk be sure to unmount it and unlink the keys from the keyring. The following bash snippet was stolen from the ecryptfs-umount-private script and reworked a bit to handle this specific scenario:

Initially I tried to use ecryptfs-recover-private on the path to my old home directory. This does not yield expected results.

However this simply re-mounted the home directory of my primary disk. This was definitely not what I expected. I did not care to dig into why this happens and used a brute force approach: I used ecryptfs-recover-private on any .Private directory I could find on the secondary disk. Luckily my second attempt was the right one 😉

If you know why my naive approach was wrong please enlighten me in the comments!

Shoutout to Dustin Kirkland for authoring the ecryptfs scripts as well as the man pages and other documentation that aided me in stumbling through this one.

Working on a python scraper/spider and encountered a URL that exceeds the char limit with the titled IOError. Using httplib2 and when I attempt to retrieve the URL I receive a file name too long error. I prefer to have all of my projects within the home directory since I am using Dropbox. Anyway around this issue or should I just setup my working directory outside of home?

3 Answers 3

You are probably hitting limitation of the encrypted file system, which allows up to 143 chars in file name.

The solution for now is to use any other directory outside your encrypted home directory. To double check this:

and see if your home dir is listed. If that’s the case either use some other dir above home, or create a new home directory without using encryption.

The fact that the filename that’s too long starts with ‘.cache/ explains the problem.

httplib2 optionally caches requests that you make. You’ve enabled caching, and you’ve given it .cache as the cache directory.

The easy solution is to put the cache directory somewhere else.

Without seeing your code, it’s impossible to tell you how to fix it. But it should be trivial. The documentation for FileCache shows that it takes a dir_name as the first parameter.

Or, alternatively, you can pass a safe function that lets you generate a filename from the URI, overriding the default. That would allow you to generate filenames that fit within the 144-character limit for Ubuntu encrypted fs.

Or, alternatively, you can create your own object with the same interface as FileCache and pass that to the Http object to use as a cache. For example, you could use tempfile to create random filenames, and store a mapping of URLs to filenames in an anydbm or sqlite3 database.

A final alternative is to just turn off caching, of course.

I’ve installed a XUnbuntu a few months ago, and did the stupid mistake of not checking “Encrypt Home”.

I’m now looking for a way to encrypt my user’s home directory (I have only one user using this computer).

I’ve read a lot of tutorials about encrypting a /home after installation, like: but they all use the same method, via ecryptfs-migrate-home which is clearly announced in the docs to use 2.5x times the current size of the user’s dir.

Unfortunately, I have a 150GB SSD, and my /home/user already uses 100GB. So I cannot use this method. Also, I would prefer not having to buy an external drive and waste (a lot of) time copying all that data back and forth, through my USB2 port.

So, I’m trying to find a solution to work around this problem.

While reading: , I discovered the command: sudo adduser –encrypt-home .

This gave me the idea to create a new user user with an encrypted home dir using this command, then to copy/move all my original-user files to this encrypted directory, then destroy the original-user account and rename the user account to original-user .

I tried this idea, by first trying to create the new user with an encrypted dir. This seems to work (apart for the passwd: Permission denied that I couldn’t find where it comes from, but does not seems to prevent the user to login with the provided passwd):

After that I can see:

So all the directories and user entries seems to be correctly created.

But when I try mount this directory, using the command provided in the README.txt listed above, it fails with: ERROR: Encrypted private directory is not setup properly

When a try a manual solution I already used to recover a crashed encrypted system (), I can see the skeleton files ( .bashrc , . ) copied by adduser (if I say yes to “encrypted filenames”), but the access rights, etc are all . , so I understand that the decryption itself did not work.

Also, when I run the recommended command to backup passphrase: ecryptfs-unwrap-passphrase

/.ecryptfs/wrapped-passphrase , I get an error saying that the file does not exists, which is indeed the case.

I’ve tried to create it using ecryptfs-setup-private -u user [-w] , but to no success until now.

So my questions are: – Is this approach valid? (I don’t think so, otherwise people would not propose a method that takes 2.5x the space needed). – Particularly, is it possible to create a encrypted /home/user directory with cryptsetup on a /home partition that was not configured for encryption, or is that the partition itself that should be encrypted (which would explain the problem in decryption with mount and absence of passphrase when trying to backup)? – If my idea is fine, is there a way to generate a passphrase to finish my setup?

Account Information

Share with Your Friends

2 ways to better secure your Linux home directory

2 ways to better secure your Linux home directory

If you want to further secure your Linux machines, there’s no place like home. Here’s how to manage permissions and encrypt each user’s home directory.

Linux. That’s right, the platform of reliability, flexibility, and security. Even though you do gain significant amounts of security with the open source operating system, no computer is one hundred percent safe. Period. End of story. However, there are things you can do, even with Linux, to make your experience considerably more secure.

Must-read security coverage

• Best encryption software 2022
• The 10 best antivirus products you should consider for your business
• 8 enterprise password managers and the companies that will love them
• Security incident response: Critical steps for cyberattack recovery (TechRepublic Premium)

One often-forgotten area of Linux security is the home directory–otherwise known as

/. Something to keep in mind, is that particular directory houses user data. In other words, this is the default directory where documents are stored. If this machine is used in a business environment, there could be sensitive information stored within.

Let’s see what we can do to that home directory to make it more secure. We’ll start with the easy tip first. I’ll be demonstrating on a freshly installed Ubuntu 17.10 desktop.

Permissions

One thing you must know is that, out of the box, users can read each other’s files in their home directory. That’s right, if you have a Linux machine with multiple users, those users can read one another’s files (so long as they are housed within their home directory or child folders within the home directory). So if user jack has a file /home/jack/jacksfile, user olivia could read the contents of that file (although not write to it).

How do we prevent this? Actually it is quite simple. What we must do is change the permission of each user’s home directory. For each user directory, execute the following command:

sudo chmod -R 700 /home/USER

Where USER is the actual username.

When a user attempts to either list the contents of a directory in that user’s account (or read a file in that same directory), they will receive a permission denied error.

That’s the easy way. Now let’s take a look at a more complicated method of better security your user’s home directory.

SEE: Securing Linux policy (Tech Pro Research)

Encryption

During the installation of the platform, you will be asked if you want to encrypt each user’s home directory. If you skip that during installation, worry not, you can do it post-install. Here’s how.

The first thing you must do is install a couple of extra tools. Back at the terminal window, issue the following command:

sudo apt-get install ecryptfs-utils cryptsetup

The next step is to create a temporary account with admin privileges. To do this, open up the Settings app and search for Users. In the new window (Figure A), click the Unlock button and type your sudo password.

Figure A

Next, click the Add User button and fill out the information for the new user (Figure B). Remember, this will be a temporary user, used only for the encryption of another user’s home directory.

Figure B

Once you’ve created the new user, close out the Settings window and log out of your current user. You’ll then log into the temporary user account. From that new user, open up a terminal window and issue the following command to encrypt the user’s home directory:

sudo ecryptfs-migrate-home -u USER

Where USER is the username whose home directory you want to encrypt. You will first be prompted for the temporary user’s sudo password, followed by the password for the user whose home directory is being encrypted. The above command will not only encrypt the user’s directory, it will also create a backup of the contents of that directory (in case of a problem).

This next step is vital. Before you reboot the system, you must do the following:

1. Login as the user whose directory was just encrypted.
2. Issue the command ecryptfs-unwrap-passphrase and record the randomly generated passphrase (you will be prompted for your user login password, in order for this to work).
3. If swap space is being used on the system, you should also encrypt it with the command sudo ecryptfs-setup-swap

The backup, created by the ecryptfs-migrate-home command is found in /home and will be in the form of USER.XXX (where USER is the username and XXX is a random string of characters). Leave that in place, until you’ve rebooted a couple of time and verified the user can access all of their files. Once you’ve taken care of the above, reboot the system and then attempt to log in as the user whose home directory was just encrypted

Cleaning up

And that’s it. Your home directory is encrypted. Repeat this process for all users who require encrypted home directories. Once you’re finished, and have verified everyone can access their files and folders, you can delete the backups as well as the temporary user. Your encrypted home folders are good to go.

Chris Hoffman is Editor-in-Chief of How-To Geek. He’s written about technology for over a decade and was a PCWorld columnist for two years. Chris has written for The New York Times and Reader’s Digest, been interviewed as a technology expert on TV stations like Miami’s NBC 6, and had his work covered by news outlets like the BBC. Since 2011, Chris has written over 2,000 articles that have been read nearly one billion times—and that’s just here at How-To Geek. Read more.

Ubuntu offers to encrypt your home directory during installation. The encryption has some drawbacks – there’s a performance penalty and recovering your files is more difficult. If you change your mind later, you can remove the encryption without reinstalling Ubuntu.

The process of removing the encryption involves creating a backup copy of your home directory without encryption, deleting the existing home directory, removing the encryption utilities, and moving the unencrypted copy back into place.

Back Up Your Home Directory

Your home directory is available to you in unencrypted form while you’re logged in, so you can easily create an unencrypted backup copy.

To create the backup copy, launch a terminal while you’re logged in and run the following command, replacing user with your username:

sudo cp -rp /home/user /home/user.backup

(The -rp options here tell cp to copy the directory recursively – that is, copy everything inside it – and to preserve the file ownership and permission information.)

Open the /home/user.backup directory on your system and verify that the backup was created successfully. All your files should be there. It’s always a good idea to have an additional backup, too – just in case.

Switch User Accounts

You can’t remove the encryption while you’re logged in, so you’ll have to switch to a different user account first. The simplest way to do this is by creating another user account with administrator (sudo) privileges. To create another user account, click your name on the panel and select User Accounts.

Create a new user account with the Administrator account type.

Set a password for the user account. You won’t be able to log in as the other user account until you set a password.

Log out from the panel after creating the other user account.

Select your temporary user account on the login screen and log in.

Remove Encryption

Once you’re logged in as the other user account, fire up a terminal and run the following command to delete your current, encrypted home directory. Be sure you have a backup before deleting the home directory! And be careful when running sudo rm -rf commands – these can quickly delete important files if you’re not careful.

(Remember to replace user with your username.)

Delete the .ecryptfs folder in your backup folder. The encryption utilities won’t uninstall until you delete this folder.:

Next, remove the encryption utilities from your system:

sudo apt-get remove ecryptfs-utils libecryptfs0

Finally, restore the unencrypted backup of your home directory to its original location:

Your home directory is now unencrypted. You can log out (or restart your system) and log in normally. You may want to delete the temporary user account from the User Accounts window.

EncryptedHomeDirectory

Created: 2008-12-02

Contributors: DustinKirkland

Packages affected: adduser, ecryptfs-utils, gnome-system-tools, Graphical Installer(s), Alternate Installer

Summary

Based on the delivery of EncryptedPrivateDirectory in Ubuntu Intrepid, this specification describes the next steps to extend that work to provide a seamless mechanism for encrypting a user’s entire home directory, mounting it on login, and un-mounting it on the last logout.

Release Note

The Ubuntu Jaunty Jackalope (9.04) release will enable per-user home directory encryption, automatically mounting it on login, and un-mounting it on the last logout of the user.

Rationale

The EncryptedPrivateDirectory work proved the usefulness and stability of the Linux kernel’s ecryptfs cryptographic filesystem. Encrypting only

/Private directory, however, requires Ubuntu users to consciously store sensitive data in that location, and manually linking that data to traditionally locations.

Use Cases

See the use cases for:

Encrypted home directories will provide a more complete solution to encrypting all of the user’s unique data, while not requiring the performance penalty of encrypting all of the data on the entire system and not requiring a passphrase to boot an unattended system.

Assumptions

Users of encrypted home directories are willing to pay the minor performance penalty incurred by encrypting/decrypting their data in the home directory in exchange for data security on the disk.

• We should get some formal filesystem benchmarks against an encrypted home directory.

Users will record their mount passphrase in a safe location, such that they can retrieve their data manually if necessary.

• We need to state this clearly on user creation, and provide a graphical utility for retrieving said mount passphrase and allowing the user to print/record it.

Swap space will be encrypted.

Design

The eCryptfs Linux kernel cryptographic filesystem was chosen as the implementation mechanism for several reasons:

This is the same technology developed and proven in the Intrepid release in the EncryptedPrivateDirectory specification.

Implementation

ecryptfs-utils

The functionality for bootstrapping a user’s home directory for encryption has been released in the upstream ecryptfs-utils-67 release. This needs to be merged into Ubuntu Jaunty.

adduser

Following the merge of ecryptfs-utils-67+ into Jaunty, the adduser utility should be patched to support a –encrypt-home option. A patch is attached to 302870.

gnome-system-tools

Similar to the patch for adduser, the graphical user adding tools need to be enhanced to support the adduser –encrypt-home option.

The Installers

The Ubuntu alternate/server installer already supports creating an encrypted

/Private directory on install. This debconf text should be modified to prompt for an encrypted home directory (encrypted

/Private will still be available post-install). And the adduser call should be enhanced to use –encrypt-home (and not call ecryptfs-setup-private).

Ubiquity should be modified to add a check-box to the user creation page, reflecting the –encrypt-home option. Note that this option will need to be mutually exclusive of the Auto-Login option.

UI Changes

Most of the UI changes involved should be handled by a separate, but related blueprint:

Migration

Migration of data from a non-encrypted home directory to an encrypted home directory is a dangerous operation. As such, I will carefully document the procedure for doing so, but I do not believe it safe to provide a script to do so automatically.

This will be discussed at UDS San Francisco.

Test/Demo Plan

As of 2008-12-02, you can test this by:

Install the adduser and ecryptfs-utils packages in the following PPA:

kirkland/+archive

Add a user with an encrypted home directory as root, with:

# adduser --encrypt-home testuser

Login as testuser on the console, through the GUI, and via ssh. Ensure that all programs work as expected. Log out of the console/GUI/ssh. Ensure that the home directory is not mounted and that the data stored in /home/testuser/.Private is encrypted.

Unresolved issues

There are two other specifications, solving related issues:

Encrypting Swap Space

Discussion

Please post questions to:

ThierryCarrez – The obvious objection to this will be the potential performance drop on disk-intensive operations in /home that don’t require privacy (think unpacking and compiling sources). The addition of a pass-through system that allows to designate unencrypted directories (that won’t suffer from any encryption performance penalty) would be nice to counter that objection. We would go from a setup in Intrepid where nothing is encrypted except the directories that you link in Private (opt-in encryption) to a setup in Jaunty where everything is encrypted except the directories you specify (opt-out encryption). That’s a much better “secure by default” approach.

JackWasey – “Even though you may notice some slowdowns, we would still recommend at least encrypting the user’s home directory (if not the entire file-system) on mobile devices whether it be notebooks or netbooks. We will be delivering some benchmarks soon that do look at the home encryption feature when running on an Atom-powered netbook. Those with desktops should be able to get by with this feature enabled while not significantly sacrificing performance unless you deal heavily with encrpyting, compressing, or otherwise manipulating very large files constantly.

If you would like to see how your computer performs with these tests, after installing the Phoronix Test Suite, run phoronix-test-suite benchmark phorocrypt-16497-10491-19665.”

EncryptedHomeDirectory (последним исправлял пользователь nat-stumcr 2009-04-07 21:12:29)

Contents

• 1 Introduction
• 2 eCryptfs setup
• 3 Locating the Files
• 4 Decryption Passphrase
• 5 Filename Encryption
• 6 Decrypt and Mount
• 7 Troubleshooting

Introduction

Ubuntu allows users to encrypt their home directories upon installation. In case of hardware failure it is easy to decrypt and access these files with Gentoo so they can be recovered. The encrypted home directory and either the login password, or the decryption passphrase are all that’s required.

eCryptfs setup

The files and filenames are individually encrypted and decrypted on the fly using eCryptfs. eCryptfs needs to be enabled in the kernel:

The wiki has an excellent set of instructions: Ecryptfs

The short version:

Install the ecrypt file system utilitys:

Locating the Files

Locate the Ubuntu encrypted home directory for decryption. If the home directory is on an external hard drive Gentoo may have automagically mounted it at:

As an example we will use:

/run/media/anon/27a70809-cb85-43eb-908f-ecb759dd4c99/

The decryption target would then be the users home directory:

/run/media/anon/27a70809-cb85-43eb-908f-ecb759dd4c99/home/user

That folder is, however, empty; except for some symbolic links. Ubuntu puts the encrypted home directory files in a different directory; which is then decrypted and mounted on the fly to the users home directory by ecryptfs. All of the encrypted files for our example are located here:

/run/media/anon/27a70809-cb85-43eb-908f-ecb759dd4c99/home/.ecryptfs/user/.Private

Decryption Passphrase

The passphrase is a 16-byte hexadecimal number that Ubuntu asks the user to record after installation is complete. As an example: 7069ca27397aa8ac9163fe7a703257f7

If the decryption passphrase is known move on to the next step.

If the decryption passphrase is unknown it can be discovered by using the logon password to decrypt the wrapped-passphrase file:

/run/media/anon/27a70809-cb85-43eb-908f-ecb759dd4c99/home/.ecryptfs/user/.ecryptfs/wrapped-passphrase

Unwrap the Passphrase:

Filename Encryption

The filename encryption key is needed before the files can be accessed. Also the decryption passphrase needs to be added to the user session keyring. Accomplish both of these things with the following command:

The filename encryption key is output as a hexadecimal number in the second set of brackets. The example filename encryption key is cd7b5893b93c0920

Decrypt and Mount

Give the mount command with type ecryptfs followed by the location of the encrypted files, followed by a location to mount the decrypted files at:

At the interactive prompt make the following eight entries/choices:

• Passphrase
• Cipher: AES
• Key bytes: 16
• plaintext passthrough: n
• filename encryption: n
• Filename Encryption Key
• proceed?: yes
• append sig?: no

The decrypted files are now available for recovery or backup. In the example they are at: /run/media/anon/27a70809-cb85-43eb-908f-ecb759dd4c99/home/user

The files are not permanently decrypted at this point.

They are simply available for copying or modification.

Posted on Saturday March 28, 2015

Here’s the situation I recently found myself in:

• Ubuntu Linux 14.10
• Unknown password for user account
• Unknown (but set) root password (Ubuntu’s philosophy is to use sudo for everything)
• LUKS encrypted filesystem (known passphrase)
• Physical access to the computer

I needed to reset my account password. Normally, with physical access to a machine, all bets are off when it comes to security. I tried booting up the machine into recovery mode by holding down shift as soon as the BIOS had finished loading. But when I selected the “Drop to root shell” option, I was prompted to enter the unknown root password.

My second approach was to boot into single user mode by editing the GRUB command script.

By going down to the recovery mode option and hitting e , you can edit the GRUB commands. By adding init=/bin/bash at the end of the line beginning with linux that specifies the boot image, you can specify an initial shell to use. Then I hit F10 to boot.

After waiting for about 30 seconds or a minute, I saw a message that waiting for the root device (the locked disk) had timed out. I was then dumped into an initramfs shell. From there, I was able to unlock the disk by running cryptsetup luksOpen /dev/sda3 sda3_crypt .

Next, I mounted the freshly-unlocked disk with mount -o rw /dev/sda3 /root , taking advantage of the pre-existing empty directory. From there, I used chroot to run passwd in the OS.

By running these commands, I successfully reset both the root password as well as the password for my account. From there, I was able to restart the machine and boot normally.