No way to mount the encrypted private directory when logging in over ssh using public key auth

[Tommaso R. Donnarumma]

Binary package hint: ecryptfs-utils

Observed with ecryptfs-untils 53-1ubuntu8.

Steps to reproduce:
1) Set up your box so that you can login via ssh using public key authentication
2) Set up an encrypted private folder for yourself
3) Logout locally so that the encrypted private folder is unmounted
4) Login remotely using your ssh key

What happens:
The encrypted private directory is not mounted automatically and can't be mounted manually using ecryptfs-mount-private because the key has not been unwrapped.

What should happen:
I understand why the above happens, and I appreciate that the ideal solution (automount of the encrypted private folder in this case) may well not be feasible because of security considerations, but I think that ecryptfs-mount-private should really ask for your password instead of erroring out if the key for the private folder has not been unwrapped at login time for whatever reason.
I wouldn't even mind if I have to write something like ecryptfs-mount-private --ask-password to have it happen, if that must be...

[Dustin Kirkland  (kirkland)]

Thanks for the report.

I'm intrigued, because I've been struggling with this mightily, what the best solution might be here.

I really think the best option is to *ONLY* put your private key in the encrypted private directory (or at the very least, keep authorized_keys in the public).

I suggest a structure like the following:
~$ tree -a
|-- .ssh
| |-- config
| |-- id_rsa -> Private/.ssh/id_rsa
| |-- id_rsa.keystore
| |-- id_rsa.pub
| `-- known_hosts
`-- Private
    `-- .ssh
        `-- id_rsa
3 directories, 6 files

Here, only your private key is in ~/Private, and linked into its proper place. The only time you should need access to your private key, you'd presumably be logged into your system and have your ~/Private directory mounted.

What do you think?

To answer your question about a hypothetical "ecryptfs-mount-private --ask-password", let me explain how it would flow...
 * user requests a mount of encrypted ~/Private
 * if it's already mounted, exit
 * try to mount with the key(s) currently in the user's keyring (see: keyctl show), exit on success
 * key is not in the keyring, so ask the user if they know the mount passphrase
 * prompt for mount passphrase and add to keyring (see: ecryptfs-add-passphrase)
 * retry the mount

I think this is a reasonable feature request, and I'll open a new bug upstream about it (and link here). But specifically for the ssh issue, I think that would be better handled by intelligently selecting what belongs in an encrypted ~/Private, and what does not (or cannot).

Thanks,
:-Dustin

[Dustin Kirkland  (kirkland)]

I opened the feature request upstream as Bug#277706.

I'm going to mark the ssh-specific bits to this bug as Invalid. You're welcome to reopen if you have more information and strong disagree with the particular suggestion for ssh, and the new bug upstream.

Thanks!
:-Dustin

[Tommaso R. Donnarumma (tawmas)]

@Dustin: Thanks a lot. I subscribed to Bug#277706 and agree to this bug being resolved invalid.

As for your .ssh scheme, it's interesting indeed. Personally, I went the lazy way and just symlinked everything but authorized_keys, but never felt satisfied about that. I think I'm going to adopt your solution, and I also think it should be promoted to new users of the ~/Private feature (last time I checked, the setup instructions suggested to move the whole .ssh directory).

Again, thanks!

tawmas

[Dustin Kirkland  (kirkland)]

That's a great point. I'm going to update my blog and the wiki page
accordingly. Thanks for your careful eye to detail ;-)

:-Dustin