Support a wrapped-passphrase.ssh, wrapped with an ssh private key

Bug #364015 reported by sasha on 2009-04-20
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
eCryptfs
Wishlist
Unassigned
ecryptfs-utils (Ubuntu)
Wishlist
Unassigned

Bug Description

I had a problem with ssh public key auth and encrypted home directory in Jaunty. I fixed the issue by workaround provided by Dustin Kirkland:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427

But after reboot auto mount of encrypted home directory has stopped to work. There is only one error string in auth.log:

Mount of private directory return code [256]

At the same time I am able to mount home directory manually through ecryptfs-mount-private command. But /sbin/mount.ecryptfs_private shows me the following:

keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'

... looks like pam_ecryptfs is not able to read ~/.ecryptfs/wrapped-passphrase

description: updated
tags: added: ecryptfs pam

Strange, but It has started to work after sshd restart.

summary: - Auto mount of encrypted home directory has stopped to work
+ Auto mount of encrypted home directory RANDOMLY stops to work

Today it has stoped to work again. I did sshd restart then it has started to work on next ssh login. It really looks like a bug.

miraculix125 (miraculix125) wrote :

same issue for me on jaunty 2.6.28.11 using libpam-ssh 1.91.0-9.3 and ecryptfs-utils/libecryptfs 73-0ubuntu6.

i dont have the whole homedir encrypted, only the ~/Private folder, nevertheless i get a "gdm[3587]: Mount of private directory return code [256]" or a "keyctl_search required key not available" when logging on via gdm/console after entering my ssh passphrase.
i sourced the pam-ssh-auth and pam-ssh-session files in login, gdm and gdm-autologin as instructed in pam_ssh manual. the pam_ecryptfs module is loaded with common-auth and common-session, both as optional.

while disabling pam_ssh and using pam_ecryptfs works as intended...

Dustin Kirkland  (kirkland) wrote :

Hmm, okay, I'm unfamiliar with pam_ssh.

Please help me understand...

What are you trying to accomplish with this pam-ssh package?

Your home (or private) directory is encrypted with a mount passphrase. This mount passphrase is symmetrically encrypted (wrapped) with your system login passphrase.

In order to automatically mount your home (or private) directory, you must enter your system login passphrase, such that pam_ecryptfs can unwrap ~/.ecryptfs/wrapped-passphrase, obtain your mount passphrase, add that to your kernel keyring, and then perform the mount.

It's possible that this pam-ssh feature is incompatible with encrypted-home/encrypted-private. If so, we should document this as such.

Can you please provide more information?

:-Dustin

Changed in ecryptfs:
importance: Undecided → Low
status: New → Incomplete
affects: ubuntu → ecryptfs-utils (Ubuntu)
Changed in ecryptfs-utils (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
Dustin Kirkland  (kirkland) wrote :

Another question ... is your ssh passphrase the same as your system login passphrase?

If not, perhaps you might try re-wrapping your ~/.ecryptfs/wrapped-passphrase with your ssh passphrase (instead of your system passphrase)?

See:
 $ ecryptfs-rewrap-passphrase ~/.ecryptfs/wrapped-passphrase

:-Dustin

Hi Dustin, I am creator of this bug ;)

As for me I do not use libpam-ssh. I just have a fresh installation of 9.04 and I use workaround provided by you to have ssh public key auth working. It works randomly, sometime I need to restart ssh and log in again to have encrypted home dir mounted. I am also able to mount home dir through ecryptfs-mount-private.

Alexander-

Do you have your authorized_keys file available in plaintext in both
your encrypted and unencrypted mountpoints?

For a hint, take a look at how your ~/.ecryptfs works. It's a symlink
in both places--mounted and unmounted home dir. Both symlink point to
/var/lib/ecryptfs/$USER. You should, perhaps, put all or some of your
.ssh configuration in there, and establish symlinks back.

Can you try that and let us know how it works?

Others-

If you're having trouble with pam_ecryptfs + pam_ssh, please open a
new bug, as this is NOT the same issue that Alexander reported.

Thanks.

:-Dustin

Hi Dustin,

Just checked - there is only one authorized_keys, it is in unencrypted mountpoint. I am not sure that I understood you well, but just checked the symlink to ~/.ecryptfs, it exists in both encrypted and unencrypted mountpoints, but it doesn't contain authorized_keys in both cases.

Okay, I don't think you understood me very well...

Do this ...

Put a single, unencrypted copy of authorized_keys in /var/lib/ecryptfs/$USER

Now, symlink to that file from two locations...

When your $HOME is created, do:

 $ ln -s /var/lib/ecryptfs/$USER/authorized_keys $HOME/.ssh

And the do the same when it's not mounted.

:-Dustin

Ok, I did that. The situation is the same.

On the next login, the system accepted my public key but didn't mount home dir. The error is the same:

sshd[11368]: Mount of private directory return code [256]

It's strange, but I made a restart of apache2, logged off from the system, then logged on and the system did mount the private directory. It looks like I do not need to restart sshd, I just need to type sudo command to have home directory mounted on the next login.

Hope you are able to understand me and my efforts helps you.

Thanks,
Alex

Just tried with "sudo echo hello", it allows me to log in on the next time with mounted home directory. I don't know does it matter or not, but I use screen. Just for note.

Dustin Kirkland  (kirkland) wrote :

Okay, I finally have my head wrapped around this bug.

So here's the deal...

To mount your home directory, you *must* provide your login passphrase at some point, because this passphrase is used "unwrap" your wrapped-passphrase file. This is what you're doing when you run "sudo". Sudo prompts you for your passphrase, which walks the pam stack and mounts your home directory.

I'm going to update the title of this bug. What you're really asking for, is to have a second wrapped-passphrase file, perhaps called ~/.ecryptfs/wrapped-passphrase.ssh, which is wrapped with your ssh private key instead of your system login passphrase.

I am going to need to study the implementation of pam_ssh and authorized_keys...

Thanks for the report and research.

:-Dustin

summary: - Auto mount of encrypted home directory RANDOMLY stops to work
+ Support a wrapped-passphrase.ssh, wrapped with an ssh private key
Changed in ecryptfs:
importance: Low → Wishlist
status: Incomplete → Confirmed
Changed in ecryptfs-utils (Ubuntu):
importance: Medium → Wishlist
status: Incomplete → Confirmed
Dustin Kirkland  (kirkland) wrote :

Having talked to Colin Watson, this is actually quite a complicated request. When doing ssh authentication, your private ssh key is not actually sent to the host system. Instead, the client signs a message with the private key, and sends this to the server, which authenticates the message using the public key.

As such, this might require some ssh protocol extension to solve.

:-Dustin

Hi Dustin,

Thanks a lot for explanation. Unfortunately such kind of home directory encryption doesn't suit my needs. So, I have encrypted home directory and I able to mount it only with login passphrase our mount it manually in case of public key auth. In the last case I have to mount directory every time after ssh login.

Is there any way to mount encrypted home directory manually only once(on server restart)?

On Tue, May 12, 2009 at 1:28 PM, Alexander Kraev
<email address hidden> wrote:
> Is there any way to mount encrypted home directory manually only once(on
> server restart)?

Yes. Remove your $HOME/.ecryptfs/auto-umount file. This will tell
PAM not to unmount on logout.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Hello-

I've spent quite a bit of time on this, and I really don't think this can be solved properly.

If you can engineer a design that works, I'm all ears. Thanks.

:-Dustin

Changed in ecryptfs-utils (Ubuntu):
status: Confirmed → Won't Fix
Changed in ecryptfs:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers