eCryptfs

Public key ssh auth doesn't work in Jaunty

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

Question information

Language:
English Edit question
Status:
Solved
For:
eCryptfs Edit question
Assignee:
No assignee Edit question
Solved by:
sasha
Solved:
Last query:
Last reply:

This question was originally filed as bug #362427.

Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#1
Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#2
Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#3

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

Revision history for this message
Andreas Olsson (andol) said : 		#4

Do you use encrypted home directories on the server?

Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#5

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

Revision history for this message
Andreas Olsson (andol) said : 		#6

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.

Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#7

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?

Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#8

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

Revision history for this message
Dustin Kirkland  (kirkland) said : 		#9

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

Revision history for this message
Pollywog (pollywog) said : 		#10

I am having the same problem on Jaunty, but only one one Jaunty system and not on the other.
I have checked the configurations and do not see the problem. The odd thing is that the system that will not accept a passphrase and only accepts a password will after a few sessions all of a sudden begin accepting the passphrase. If I reboot this system, it goes back to not accepting the ssh passphrase.

Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#11

Actually I have solved this issue, but I have found a new one:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427

Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#12

Sorry, I meant this bug:

https://bugs.launchpad.net/ubuntu/+bug/364015

Revision history for this message
Pollywog (pollywog) said : 		#13

I see that Alexander Kraev provides a solution, that of setting
AuthorizedKeysFile /etc/.ssh/%u/authorized_keys

Are there any security implications from doing this?

Revision history for this message
sasha (sasha123-deactivatedaccount) said : 		#14

Actually I do not use /etc/.ssh/%u/authorized_keys anymore. I use workaround provided by Dustin:

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

Revision history for this message
Florian Rathgeber (florian-rathgeber) said : 		#15

I don't see how this workaround is practically useful unless you want to disallow password-based logins. The password is needed anyway to unwrap 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.