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 …
// 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.
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.
Hi, you are right. I knew that, but didn’t even consider the possibility. Thanks for the hint 😉
// Oliver
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/
Wow, nice method. Thanks a lot for taking the time to post it.