Ubuntu

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

Reported by sasha on 2009-04-16

This bug report was converted into a question: question #67703: Public key ssh auth doesn't work in Jaunty.

42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
eCryptfs
Medium
Dustin Kirkland 
ecryptfs-utils (Ubuntu)
Medium
Dustin Kirkland 
openssh (Ubuntu)
Medium
Dustin Kirkland 

Bug Description

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
...

description: updated
tags: added: jaunty key public ssh
description: updated
tags: added: issue

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

Andreas Olsson (andol) wrote :

Do you use encrypted home directories on the server?

Changed in openssh (Ubuntu):
status: New → Incomplete

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

summary: - Public key ssh auth doesn't work in Jauny
+ Public key ssh auth doesn't work in Jaunty

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.

Changed in openssh (Ubuntu):
status: Incomplete → Invalid

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?

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

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

Changed in ecryptfs-utils (Ubuntu):
assignee: nobody → Dustin Kirkland (kirkland)
importance: Undecided → Medium
status: New → In Progress
Changed in ecryptfs:
assignee: nobody → Dustin Kirkland (kirkland)
importance: Undecided → Medium
status: New → In Progress
Changed in openssh (Ubuntu):
assignee: nobody → Dustin Kirkland (kirkland)
importance: Undecided → Medium
status: Invalid → In Progress
Changed in ecryptfs-utils (Ubuntu):
status: In Progress → Invalid
Changed in openssh (Ubuntu):
status: In Progress → Invalid
Changed in ecryptfs:
status: In Progress → Invalid
summary: - Public key ssh auth doesn't work in Jaunty
+ Public key ssh auth doesn't work with my Encrypted Home Directory

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

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

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

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

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) wrote :

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) wrote :

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

Andre (oul3h2n6n) wrote :

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

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) wrote :

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) wrote :

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions