ecryptfs and sshd, again

In January I described an issue with ecryptfs and sshd. Now I wanted to get X11 forwarding to work with it, but the problem essentially remains the same. All I got this time was:

/usr/bin/X11/xauth: timeout in locking authority file /home/oliver/.Xauthority

Well, the problem is that with ecryptfs set up, the permissions are somewhat messy in the folder that will later be overlaid by the (encrypted) home folder contents once logged in. Creating the .Xauthority file and fixing permissions didn’t do the job either, and I refrained from changing the parent folder permissions. Until I noticed, well there got to be some way of mounting the encrypted home folder from the console again. And there is: ecryptfs-mount-private. Well, if that’s what happens if I log on via the terminal, why doesn’t it work via SSH? Simple, my sshd was configured to:

#UseLogin no

So once I changed that to yes, the .Xauthority file could be created and updated without problem. A look into the PAM settings reveals why:

# (cd /etc/pam.d && grep ecryptfs *|sed 's/[ \t]/ /g')
common-auth:auth optional pam_ecryptfs.so unwrap
common-password:password optional pam_ecryptfs.so
common-session:session optional pam_ecryptfs.so unwrap
common-session-noninteractive:session optional pam_ecryptfs.so unwrap

Now the only question was, would it work with UseLogin yes in sshd_config but without the ~/.ssh/authorized_keys inside the “unmounted” home folder? Unsurprisingly the answer is nope. One still has to go through hoops in order to update the authorized_keys file. And a web search tells you that apparently the majority of people still uses passwords for their SSH connections, no one seemed to have the same problem so far. So my hope is that this post is going to help someone else 😉

To sum it up – all one has to do is:

  • Use login(1) in order to log into your account via SSH
  • Make sure that the “raw” home folder before mounting the ecryptfs‘d part contains your .ssh/authorized_keys file.

It seems like the home folder gets unmounted as soon as one logs off and no other sessions are still running. Fair enough … once we know the rules, we can play by them … :mrgreen:

// Oliver

PS: A symptom of not auto-mounting the private home folder is seeing this during logon:

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

Running ecryptfs-mount-private && cd $HOME fixed that for me.

This entry was posted in EN, IT Security, Linux, Software, Unix and unixoid and tagged , , , , , . Bookmark the permalink.

4 Responses to ecryptfs and sshd, again

  1. Jurij says:

    You can also put your authorized_keys file somewhere else, not in your home folder. E.g. in /etc/ssh/keys/. You can set the path in the sshd config file.

  2. Oliver says:

    Hi, you are right. I knew that, but didn’t even consider the possibility. Thanks for the hint 😉

    // Oliver

  3. X says:

    A cleaner solution to store your authorized_keys:

    # login to the user on the remote machine
    # create /home/.ecryptfs/$USER/.ssh and put your authorized_keys there
    # symlink your encrypted version there:
    $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_keys ~/.ssh/authorized_keys

    $ ecryptf-umount-private
    $ mkdir ~/.ssh
    $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_keys ~/.ssh/authorized_keys
    $ ecryptfs-mount-private

    (exchange authorized_keys with authorized_hosts if that’s what you want)

    source: https://rohieb.wordpress.com/2010/10/09/84/

  4. Oliver says:

    Wow, nice method. Thanks a lot for taking the time to post it.

Leave a Reply

Your email address will not be published. Required fields are marked *