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