Public key ssh auth doesn't work with my Encrypted Home Directory

[sasha]

Spent all night to understand why public key ssh auth doesn't work. It seems to me that issue only affects Jaunty. Please have a look at the details below.

So, the configuration is:

1. Client
- lsb_release: Ubuntu 8.10 intrepid
- ssh-client: OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007

2. Server A
- lsb_release: Ubuntu 8.04.2 hardy
- sshd: OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007

3. Server B
- lsb_release: Ubuntu 9.04 jaunty
- sshd: OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007

Server A and Server B have the same /etc/ssh/sshd_config:
RSAAuthentication yes
PubkeyAuthentication yes
StrictModes no

I turned StrictModes to "no", but every server has the same permissions on user's .ssh folder and .ssh/authorized_keys file. authorized_keys is the same on Server A and Server B.

So, I am able to connect with public key from Client machine to Server A, but I can't connect to Server B.

I run ssh client and sshd on Server B in debug mode, please find logs attached.

Most important strings from auth.log:

...
Apr 16 20:58:47 ubuntu sshd[21728]: debug3: mm_request_receive entering
Apr 16 20:58:47 ubuntu sshd[21728]: debug3: monitor_read: checking request 21
Apr 16 20:58:47 ubuntu sshd[21728]: debug3: mm_answer_keyallowed entering
Apr 16 20:58:47 ubuntu sshd[21728]: debug3: mm_answer_keyallowed: key_from_blob: 0xb9084978
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: trying public key file /home/sasha/.ssh/authorized_keys
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: restore_uid: 0/0
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: trying public key file /home/sasha/.ssh/authorized_keys2
Apr 16 20:58:47 ubuntu sshd[21728]: debug1: restore_uid: 0/0
Apr 16 20:58:47 ubuntu sshd[21728]: Failed publickey for sasha from 10.0.0.11 port 51194 ssh2
Apr 16 20:58:47 ubuntu sshd[21728]: debug3: mm_answer_keyallowed: key 0xb9084978 is not allowed
...

[sasha (sasha123-deactivatedaccount)]

Please try public key ssh auth with Jaunty server and confirm. It seems to me this is an important issue.

[Andreas Olsson (andol)]

Do you use encrypted home directories on the server?

[sasha (sasha123-deactivatedaccount)]

Yes, I do. You can find some information related to encryptfs in sshd log.

[Andreas Olsson (andol)]

Okej, sorry, I guess I didn't read the logs as carefully as I should have.

Anyhow, I'm rather sure your encrypted home directory is the reason why you can't use public key ssh auth. Considering that encryptfs decrypts your home directory, using your login password, at login time. Hence, when you'r trying to auth using your ssh key there really isn't any ~/.ssh/authorized_keys available for sshd to check against.

That said, I'm sure we can agree that it isn't a bug in openssh?

Marking this bug report as invalid.

[sasha (sasha123-deactivatedaccount)]

Hmm.. Well, sound like it's not a bug. Thank you for explanation!

But are there any solution or workaround to use public key auth with encrypted home dir?

[sasha (sasha123-deactivatedaccount)]

I think it's a bug, but not related to openssh.

I fixed the issue by adding this to sshd_config:
AuthorizedKeysFile /etc/.ssh/%u/authorized_keys

[Dustin Kirkland  (kirkland)]

Okay, so your public key is locked away in encryption, if you're not
already logged into the system.

You can work around this by accessing your un-mounted (ie,
not-encrypted) home directory, and putting your public key there.

 $ /sbin/ecryptfs.umount_private && cd && /sbin/ecryptfs.mount_private
 $ mkdir .ssh
 $ echo $PUBKEY > .ssh/authorized_keys

:-Dustin

[sasha (sasha123-deactivatedaccount)]

Thanks, Dustin.

Just tried your workaround. But it doesn't work. I steel get the same error.

Just for note, there is /sbin/ecryptfs.umount_private, there is /sbin/umount.ecryptfs_private

[sasha (sasha123-deactivatedaccount)]

Thanks, Dustin.

Just tried your workaround. But it doesn't work. I steel get the same error.

Just for note, there is no /sbin/ecryptfs.umount_private, there is /sbin/umount.ecryptfs_private

[Dustin Kirkland  (kirkland)]

Right, sorry, typed the wrong commands.

Here is an exact cut-and-paste. I left out a few details in the last
one, as it was merely pseudo code.

 $ /sbin/umount.ecryptfs_private
 $ cd $HOME
 $ chmod 700 .
 $ mkdir -m 700 .ssh
 $ chmod 500 .
 $ echo $YOUR_REAL_PUBLIC_KEY > .ssh/authorized_keys
 $ /sbin/mount.ecryptfs_private

Note that you should not have *any* other programs running between
those umount and mount commands, as all of your home directory will be
unreadable by those programs. If you're on a graphical desktop, log
out of all sessions and either ssh in, or login on the tty terminal.

I just tested the above commands and they work perfectly.

:-Dustin

[sasha (sasha123-deactivatedaccount)]

Hi, Dustin!

The workaround works. Could you please give me a link to good description of private directory's encryption in Ubuntu, internals and so on.

Many thanks,
Alex

[sasha (sasha123-deactivatedaccount)]

Strange but auto mount of encrypted private directory has stopped to work. There is only "Mount of private directory return code [256]" error in auth.log. But I am able to mount manually the private dir after ssh login.

[Dustin Kirkland  (kirkland)]

On Sun, Apr 19, 2009 at 2:34 PM, Alexander Kraev
<email address hidden> wrote:
> The workaround works. Could you please give me a link to good
> description of private directory's encryption in Ubuntu, internals and
> so on.

http://blog.dustinkirkland.com/2009/02/how-encrypted-home-ecryptfs-works.html

:-Dustin

[Brendan Long (korin43)]

I had this same problem, but I'm not using encrypted home directories. I did set my home directories permissions to 770 though. Moving the authorized keys to /etc/ssh/%u/authorized_keys worked.

Client: Ubuntu 9.04
Server: Ubuntu 9.04

[Helder (he7d3r)]

Isn't this the same as
https://bugs.launchpad.net/ubuntu/+source/encfs/+bug/319909
?

[Andre (oul3h2n6n)]

In reply to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12

on /sbin/mount.ecryptfs_private I got the following message:

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

This comment is linked to from https://help.ubuntu.com/community/EncryptedHome

ecryptfs-mount-private worked fine for me, so I'd like to recommend it as a future inclusion to the "howto" for this page.

I also have my keys in the /etc/ssh/%u/authorized_keys folder and used the above method to allow for
ln -d to as ~/.ssh/authorized_keys2

[Florian Rathgeber (florian-rathgeber)]

I don't think the workaround in #12 is practically useful unless you want to disallow password-based logins. The password is needed anyway to unlock the ecryptfs key, so imho typing it in once on first login is way easier than authenticating via public key and then manually unlocking the encrypted home. Especially since key based authentication works fine on subsequent sessions i.e. if the user is already logged in at least once and the home directory is therefore unlocked.

[Pieter (diepes)]

The password you log in with, is used to decrypt/unwrap the key used to decrypt the ecryptfs.

Would there not be a way of using the ssh secret key, used for login with ssh to also unlock/unwrap the ecryptfs ?
Probably something that would have to be added to sshd.

[Seth Arnold (seth-arnold)]

Pieter, the private key is never made available in any form to the sshd server. The server only has access to the public portion of the key in ~/.ssh/authorized_keys. You would probably not want a file on the filesystem to serve as the secret key for your encrypted directory, as that defeats the point of encrypting the directory in the first place.

Thanks

[bulldozer2003 (bulldozer2003)]

If you've implementing Dustin's workaround, you may run into a delay when logging in, and an Xauthority error. This is caused by xauth being unable to write to your home directory before the encrypted directory is mounted.

Here is my workaround. Using the ~/.ssh/rc file, the xauth parameters are written to a temp file, then read into a variable before your encrypted $HOME is mounted, then passed to xauth.

 put the following files in your UN-encrypted home directory.

~$ cat .ssh/rc
#!/bin/bash
if read proto cookie && [ -n "$DISPLAY" ]; then
  if [ $(echo $DISPLAY | cut -c1-10) = 'localhost:' ]; then
    # X11UseLocalhost=yes
    echo add unix:$(echo $DISPLAY | cut -c11-) $proto $cookie > ~/.ssh/xauth_temp
  else
    # X11UseLocalhost=no
    echo add $DISPLAY $proto $cookie > ~/.ssh/xauth_temp
  fi
fi

~$ cat .bash_login
#!/bin/bash
if test -e $HOME/.ecryptfs/auto-mount; then
  XAUTH=$(cat ~/.ssh/xauth_temp)
  mount | grep "$HOME type ecryptfs"
  if test $? != 0; then
    ecryptfs-mount-private
    cd $HOME
    source ~/.bashrc
  fi
  echo $XAUTH | xauth -q -
fi

Hope this helps someone!

The original .bash_login script comes from: http://ubuntuforums.org/showthread.php?t=1332820&s=2551a0a94ce3b24ad3e3c60601319bc3&p=8452729#post8452729

[remyvrs (remyvrs)]

Hi guys,
I am not really an experienced user and haven't actually applied the solution proposed in comment #12 , but

as I understand the authorized public key is added in .ssh/authorized_keys,
so, wouldn't it be possible to put another public key using a live cd and then login using the corresponding private key ?

Best Regards,

[Kip Warner (kip)]

This looks like this is a problem that affects many but that there doesn't appear to be any viable solution to. It seems as though the best we can hope for is to configure sshd to look for the authorized_keys outside the home directory while it is still unmounted, but all that does is login to the machine but still leave the home directory unmounted.

I think likely the only way to solve this was if upstream patched ecryptfs to some how allow SSH key authentication. I don't know how difficult that would be to do.