blag: convert (and slightly improve) blogposts from rohieb.wordpress.org

[www-rohieb-name.git] / blag / post / ssh-key-authentication-with-encrypted-home-directories.mdwn

diff --git a/blag/post/ssh-key-authentication-with-encrypted-home-directories.mdwn b/blag/post/ssh-key-authentication-with-encrypted-home-directories.mdwn
new file mode 100644 (file)
index 0000000..1b4a2da
--- /dev/null
+++ b/blag/post/ssh-key-authentication-with-encrypted-home-directories.mdwn
@@ -0,0 +1,79 @@
+[[!meta title="SSH key authentication with encrypted home directories"]]
+[[!meta date="2010-10-09"]]
+[[!meta author="rohieb"]]
+[[!meta license="CC-BY-SA 3.0"]]
+[[!flattrthing id=80700]]
+
+Yesterday, I ran into an interesting problem: I tried to set up [SSH
+public key authentication][0] between two of my machines, `c3po` and
+`r2d2`, so I could log in from `rohieb@r2d2` to `rohieb@c3po` without a
+passphrase. However, everytime I tried to login to `c3po`, I was
+prompted to enter the passwort for `rohieb@c3po`, and the debug output
+mentioned something that the key could not be verified.  More
+astonishing, when I established a second SSH connection while the first
+was still running, I was *not* prompted for a password, and debug output
+said that key authentication had been sucessful. I googled a bit, and
+after a while got to [this comment][1] on Launchpad, mentioning problems
+when the user on the remote machine had its home directory encrypted
+through ecryptfs – which was the case for me. Of course, since ecryptfs
+only encrypts the user’s home *after* he has been authenticated, the SSH
+daemon cannot read his `~/.ssh/authorized_keys` at the first time, and
+falls back to password authentication.
+
+[0]: http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1#AUTHENTICATION
+[1]: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12
+
+The Launchpad comment proposes to first unmount the ecryptfs filesystem,
+then store `~/.ssh/authorized_keys` unencrypted, and then mount the
+encrypted home again (**note** that no program should be running that
+could try to access your home directory):
+
+    $ ecryptfs-umount-private
+    $ cd $HOME
+    $ chmod 700 .
+    $ mkdir -m 700 .ssh
+    $ chmod 500 .
+    $ echo $YOUR_REAL_PUBLIC_KEY > .ssh/authorized_keys
+    $ ecryptfs-mount-private
+
+This works indeed, but has the drawback that key authentication only
+works for the *first* login, because ecryptfs hides the unencrypted
+files when it mounts the encrypted directory on login; and you had to
+synchronize the encrypted and the unencrypted version of
+`authorized_keys` everytime you add a new key. To circumvent that, I
+simply moved the file to `/etc/ssh/authorized_keys/rohieb` (with the
+file only readable and writable by me, and `/etc/ssh/authorized_keys`
+writeable for all users) and adjusting `/etc/ssh/sshd_config`
+appropriately:
+
+    $ sudo vi /etc/ssh/sshd_config  # or use your favorite editor instead of vi
+    [... some lines ...]
+    AuthorizedKeysFile /etc/ssh/authorized_keys/%u
+    [... some more lines ...]
+    $ sudo /etc/init.d/ssh restart
+
+## Update
+
+There is yet a better approach instead, which doesn’t need the SSHd
+config to be edited at all:
+
+1. login to the user on the remote machine
+2. create `/home/.ecryptfs/$USER/.ssh` and put your `authorized_hosts` there
+3. symlink your encrypted version there:
+
+       $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
+
+4. symlink your unencrypted version there (as above, **make sure** no
+   process wants to write to your home directory in the meantime):
+
+       $ ecryptf-umount-private
+       $ mkdir ~/.ssh
+       $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
+       $ ecryptfs-mount-private
+
+The paths are for Ubuntu 9.10 (Karmic Koala) and later. On other
+systems, you might want to replace `/home/.ecryptfs` with
+`/var/lib/ecryptfs`.
+
+[[!tag Debian howto Ubuntu workaround eCryptfs encrypted_home Linux
+    OpenSSH]]