Full disclosure: I am one of the authors and the current maintainer of the eCryptfs userspace utilities.
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 ...
This happens if the file system is encrypted; the FS needs to store extra metadata for the file, even if it is empty.
As I happen to have a machine handy with a vanilla ecryptfs mount (Ubuntu 12.04-LTS), I can confirm that an empty file will get 8 blocks:
$ touch test
$ ls -ls test
8 -rw-rw-r-- 1 admin admin 0 feb 27 16:45 test
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 ...
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 live ...
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 ...
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 ...
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.
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:
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 ...
The Linux kernel never stores anything on a disk of its own behalf. It stores the files that applications tell it to store through the filesystem interface, or data on block devices accessed directly, or metadata of mounted filesystems and disk volumes.
Besides it wouldn't make any sense to store the encryption key on the same media.
The encryption key is ...
You can get a zero-size file with blocks if you have extended attributes on the file, more than what can fit inside the inode itself:
$ touch abc
$ setfattr -n user.test -v xyz abc # this doesn't do it
$ ls -s abc # since the data fits in the inode
$ setfattr -n user.test -v "$(printf %100s " ")" abc
$ ls -s abc
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 ...
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 ...
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 ...
Okay I figured this out. Thanks for your help Xen2050, I don't have enough reputation here to give you an upvote (yet).
Here's the bash script that works for me:
#Set this variable to your mount passphrase. Ideally you'd get this from $1 input so that the actual value isn't stored in bash script. That would defeat the purpose.
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 in ...
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:
All symlinks have lrwxrwxrwx. This doesn't matter as the access ...
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 ...
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!
You could first use ecryptfs-add-passphrase to get your passphrase into the kernel keyring, as in pipe-ing your passphrase to it (keeping the passphrase secure, without leaving it in a plaintext file is a concern):
printf "%s" "passphrase" | ecryptfs-add-passphrase [--fnek] -
Then used mount.ecryptfs_private:
mount.ecryptfs_private is a mount helper ...
It is a common misunderstanding to worry about the sizes reported by fstrim.
It really doesn't mean anything. Just ignore it.
fstrim just issues the appropriate ioctl, everything else is the decision of the filesystem, and filesystems behave very differently. For example, ext4 tries to avoid trimming the same things over and over, so you will see 0 bytes ...
You can see encrypted & padded filenames, but you should be unable to read file contents. So trying to copy the files unencrypted will result in errors such as:
cp: cannot open 'vault/YgI8PdDi8wY33ksRNQJSvB' for reading: Required key not available
So you are pretty much not supposed to do this. The practical answer is to decrypt it, then copy it. The ...
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 ...
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 ...
If you fiddled with your home directory, you needed root to get at the /home directory that contains it. Possibly your home now contains some stuff owned by something other than you, that the sudo obviates.
An aggressive approach might be sudo chown -R myname:users ~myname
A more cautious person might do find ~myname \! -user myname to look for such ...
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 ...
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 ...
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 later,...