Hot answers tagged

24

Full disclosure: I am one of the authors and the current maintainer of the eCryptfs userspace utilities. Great question! Linux has a maximum filename length of 255 characters for most filesystems (including EXT4), and a maximum path of 4096 characters. eCryptfs is a layered filesystem. It stacks on top of another filesystem such as EXT4, which is ...


7

As of ecryptfs-utils version 96, ecryptfs-find is the best way to go from an encrypted path to a non-encrypted path. It meets the needs of most users that need to map between filenames, but there are some things to note about the tool: It doesn't decrypt filenames. It maps the filenames based on the inode number corresponding to a file. You must have a ...


6

Situation: you have an encrypted home directory. Step 1: you log in over SSH. Your encrypted data is not mounted, so what you see is your “real” home directory on the (unencrypted) main filesystem. This home directory doesn't contain much that's directly usable: ~/.ecryptfs/ contains control data for your encrypted data ~/.Private/ contains your encrypted ...


6

This thread is very interesting because I was wondering the exact same thing. I can live with having to rename 20 files out of 50 000 if the filenames need to be 140 characters or less, but 45 or less isn't feasible (in my situation) because it would require me to rename too many files. I asked the exact same question directly to Synology (even pointing ...


5

Ecryptfs stores each encrypted file in one file (the lower file, in ecryptfs terminology). The directory structure of the lower files mirrors that of the payload files, although the file names are encrypted. The metadata (modification times, in particular) of the lower files also reveals that of the payload files. The size of the lower file is slightly ...


5

Deep down, mounting is performed by root anyway: only root can call the mount system call. Programs such as mount, pmount and fusermount are setuid root and restrict what non-root callers are allowed to mount. If you're mounting a filesystem that doesn't implement file ownership (e.g. FAT), the user calling mount will end up owning the files (unless ...


5

Don't encrypt the whole hard drive (as in /dev/sda, do it per partition (or more precisely per file system - see below). Have separate file systems mounted at homes for the two users. I'm intentionally avoiding writing separate partitions, since while that is the usual way of doing things, it is constraining in some aspects. It might be more convenient to ...


4

If your home directory is encrypted, the ssh daemon can't get in it to check if your private key matches your public one. Your .ssh folder is encrypted after all. A workaround for this might be to have your .ssh folder with your authorized_keys in plaintext in your unencrypted home directory. But if your encryption techinque uses your password as a key to ...


4

In the ssh_config file, you can can change the location of where it looks for your private key. You could probably do something like make a new folder at /etc/ssh/keys/ and put your id_rsa private key file in there and then change the IdentityFile option in ssh_config to look in the new location. In doing so you'll want to take certain measures to secure ...


4

As for the tutorial, search engines seem to work, e.g. this one on howtoforge.com seems to give reasonable hints. Generally you might want to reconsider what exactly you are trying to achieve in the end. While eCryptfs will (to some degree) guarantee confidentiality you should be aware of several things: to hide the contents of home directory from other ...


4

Mounting does not change your current working directory. I guess that the mountpoint is the directory you are in. You either have to do the mount from elsewhere or to get out of that directory: ls -al ecryptfs-mount-private ls -al cd .. cd - ls -al or cd .. ecryptfs-mount-private cd - ls -al All symlinks have lrwxrwxrwx. This doesn't matter as the ...


4

Here is the solution from the link I posted in my comment. This comes from here, which references this superuser post. Create .ssh folder in /home for the keys to be stored sudo mkdir /home/.ssh Move existing authorized_keys file into .ssh dir as username sudo mv ~/.ssh/authorized_keys /home/.ssh/username Create symbolic link to authorized_keys file ...


4

This is a bug but it isn't related to the one that Aaron linked to. I'm unable to reproduce it at the moment, so can you please file a new bug here: https://bugs.launchpad.net/ecryptfs/+filebug You can copy and paste from the description above, but I also need to know more about the Linux distribution and kernel version that you're using. Thanks!


3

Yes, this is definitely doable! You'll just want to run rsync from a remote machine. To back up my encrypted data, I use an hourly cronjob, like this: 00 * * * * rsync -aP username@remotehost:/home/.ecryptfs/username /path/to/local/backup Note that this directory, /home/.ecryptfs/username, has two subdirectories: /home/.ecryptfs/username/.ecryptfs ...


3

Not possible. Someone, or something has to supply the password for decryption. Obviously it can't be on your home directory (as that is encrypted). It should not be on your hard disk at all, as that would be pointless: An attacker could extract it from there. So I don't see a way to make this automated (i.e, not requiring you) while preserving that only ...


2

Install the ecryptfs package. Run the command ecryptfs-mount-private. It will prompt you for a password, enter the password for your account on Mint. Installing the package also adds pam_ecryptfs to the PAM configuration, so from now on, if you use the same password for your account and for your ecryptfs passphrase, your encrypted home directory will be ...


2

Solution is to use luks/dm-crypt and then modify /etc/crypttab file to do what I need.


2

Encryption is a red herring here. It only protects against a very small set of threats. The administrator of the cluster can read all your files as soon as you enter the key to decrypt them. Encryption would only protect you against the administrator if you never decrypted the files on the cluster, in which case you could use some offline form of encrypted ...


2

It is absolutely essential that you record your randomly generated mount passphrase, without which it's impossible to recover your data. I can't stress that more strongly :-) You should write this down, or print it out and store it somewhere safe. Alternatively, you might consider using the zEscrow service from Gazzang. In Ubuntu (or Mint) 12.04 or ...


2

First of all, it's extremely doubtful that you'll see a noticeable performance improvement using xattrs for eCryptfs metadata. As for specifying particular mount options, you can sort of do this using the "ALIAS" feature, which I've documented in the mount.ecryptfs_private manpage. Here, you can add some fstab-style mount options, which can work for other ...


2

I would like to clarify, that linux has a 255 bytes limit per filename, not 255 characters. This is a significant difference and if you use e.g. UTF-8 encoding, you may end up with filenames of 100 characters max.


2

While eCryptFS is actively maintained by Canonical/Ubuntu engineers and the design is cryptographically sound, eCryptFS has never been formally evaluated for FIPS 140-2 certification or compliance, and it's unlikely that it ever will be. Full disclosure: I am one of the authors and maintainers of eCryptFS.


2

I can think of two valuable ways to achieve such a system w/o encrypting you home twice. separate home partition: create a separate partition that gets mounted to /home. Each user then encrypts its home via encfs. separate home partition for each user: every user gets a separate partition for his home which is itself encrypted using dm-crypt. This ...


1

Since you're talking about Ubuntu, I'm going to assume you use that. To fix, do the following: first, ensure you're working on the installed system, not the live system. A live image usually has its own root filesystem that makes reinstalling grub harder than it could be. Assuming you mount your installed root filesystem on /mnt, you can do this by ...


1

As @Lucas mentioned, LUKS would be preferable to eCryptfs for this, but yes, you can rather easily resize an ext4 image file. You can use truncate -s xxx file to change the size of the file, then losetup -c /dev/loopX to refresh the loop driver's idea of its size ( or unmount and remount it ), then resize2fs to grow it. To shrink, it must be unmounted and ...


1

In ecryptfs-utils 96-1 the file pam_ecryptfs.so is installed in /lib/security (click) which was changed in ecryptfs-utils 96-2 to /usr/lib/security (click). You might just need to update your system.


1

Like people said in the comments, if you don't recall your old password or ecryptfs passphrase, there's nothing which can be done. So I made a "dictionary attack", helped by the fact that I remembered a fair big part of the old password, and could log in again and update the ecryptfs password so that it uses the new one. The moral of the story: the password ...


1

I think the behaviour you see is just because the Vim backup process is slow. On my plain Ext4 system, this problem manifests as a "file is empty" error from the compiler. To check the timings, I used this Bash sequence: strace -tt -o /dev/stdout gvim --nofork main.cxx | grep 'main.cxx\|close' With backups turned on, I see a 200 ms gap between the file ...


1

How can I debug this? Try to strace the command. That should show the syscalls the program is making, which could help you narrow it down.



Only top voted, non community-wiki answers of a minimum length are eligible