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