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

-- 
No way to mount the encrypted private directory when logging in over ssh using 
public key auth
https://bugs.launchpad.net/bugs/268014
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to