blag/post/ssh-key-authentication-with-encrypted-home-directories.mdwn

   1 [[!meta title="SSH key authentication with encrypted home directories"]]
   2 [[!meta date="2010-10-09"]]
   3 [[!meta author="rohieb"]]
   4 [[!meta license="CC-BY-SA 3.0"]]
   5
   6 Yesterday, I ran into an interesting problem: I tried to set up [SSH
   7 public key authentication][0] between two of my machines, `c3po` and
   8 `r2d2`, so I could log in from `rohieb@r2d2` to `rohieb@c3po` without a
   9 passphrase. However, everytime I tried to login to `c3po`, I was
  10 prompted to enter the passwort for `rohieb@c3po`, and the debug output
  11 mentioned something that the key could not be verified.  More
  12 astonishing, when I established a second SSH connection while the first
  13 was still running, I was *not* prompted for a password, and debug output
  14 said that key authentication had been sucessful. I googled a bit, and
  15 after a while got to [this comment][1] on Launchpad, mentioning problems
  16 when the user on the remote machine had its home directory encrypted
  17 through ecryptfs – which was the case for me. Of course, since ecryptfs
  18 only encrypts the user’s home *after* he has been authenticated, the SSH
  19 daemon cannot read his `~/.ssh/authorized_keys` at the first time, and
  20 falls back to password authentication.
  21
  22 [0]: http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1#AUTHENTICATION
  23 [1]: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12
  24
  25 The Launchpad comment proposes to first unmount the ecryptfs filesystem,
  26 then store `~/.ssh/authorized_keys` unencrypted, and then mount the
  27 encrypted home again (**note** that no program should be running that
  28 could try to access your home directory):
  29
  30     $ ecryptfs-umount-private
  31     $ cd $HOME
  32     $ chmod 700 .
  33     $ mkdir -m 700 .ssh
  34     $ chmod 500 .
  35     $ echo $YOUR_REAL_PUBLIC_KEY > .ssh/authorized_keys
  36     $ ecryptfs-mount-private
  37
  38 This works indeed, but has the drawback that key authentication only
  39 works for the *first* login, because ecryptfs hides the unencrypted
  40 files when it mounts the encrypted directory on login; and you had to
  41 synchronize the encrypted and the unencrypted version of
  42 `authorized_keys` everytime you add a new key. To circumvent that, I
  43 simply moved the file to `/etc/ssh/authorized_keys/rohieb` (with the
  44 file only readable and writable by me, and `/etc/ssh/authorized_keys`
  45 writeable for all users) and adjusting `/etc/ssh/sshd_config`
  46 appropriately:
  47
  48     $ sudo vi /etc/ssh/sshd_config  # or use your favorite editor instead of vi
  49     [... some lines ...]
  50     AuthorizedKeysFile /etc/ssh/authorized_keys/%u
  51     [... some more lines ...]
  52     $ sudo /etc/init.d/ssh restart
  53
  54 ## Update
  55
  56 There is yet a better approach instead, which doesn’t need the SSHd
  57 config to be edited at all:
  58
  59 1.  login to the user on the remote machine
  60 2.  create `/home/.ecryptfs/$USER/.ssh` and put your `authorized_hosts` there
  61 3.  symlink your encrypted version there:
  62
  63         $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
  64
  65 4.  symlink your unencrypted version there (as above, **make sure** no
  66     process wants to write to your home directory in the meantime):
  67
  68         $ ecryptf-umount-private
  69         $ mkdir ~/.ssh
  70         $ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
  71         $ ecryptfs-mount-private
  72
  73 The paths are for Ubuntu 9.10 (Karmic Koala) and later. On other
  74 systems, you might want to replace `/home/.ecryptfs` with
  75 `/var/lib/ecryptfs`.
  76
  77 [[!tag Debian howto Ubuntu workaround eCryptfs encrypted_home Linux
  78     OpenSSH]]