Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I've switched a few boxes over to SSSD, so they now authenticate against a central LDAP server, and cache the credentials when I'm offline. This works fine, and the Ubuntu packages installed fine.

But now when I login, my home directory is no longer auto-decrypted/mounted. If I drop out of GDM and login at the console, I'm presented with this error:

keyctl_seach Required key not avaliable

If I run the suggested command (ecryptfs-mount-private) and give that my password, my home directory is unlocked fine.

I'm trying to understand how the login process has changed, such that my password is no longer unlocking the encryption key automatically. I figure it's a PAM issue, so I've included my /etc/pam.d/common-auth file below.

I presume the password is being passed to SSSD, then skipping whatever step is usual done to unlock the key. Can someone explain how that's usual done?

auth    [success=3 default=ignore]  pam_sss.so
auth    [success=2 default=ignore]  pam_unix.so nullok_secure try_first_pass
auth    [success=1 default=ignore]  pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass

auth    requisite           pam_deny.so
auth    required            pam_permit.so
auth    optional            pam_ecryptfs.so unwrap

UPDATE 1:

auth.log is reporting this error when a user logs in:

login[14202]: NULL passphrase; aborting

A google only turns up this error in the source of pam_ecryptfs.so, and is triggered when the recieved PAM_AUTHTOK is NULL:

rc = pam_get_item(pamh, PAM_AUTHTOK, (const void **)&passphrase);
[...]
if (passphrase == NULL) {
    [...]
    syslog(LOG_ERR, "NULL passphrase; aborting\n");
    [...]
}

So as least pam_ecryptfs.so is being called (i.e. it's not that it's being skipped because SSSD is in place). However why is it getting a NULL passphrase?


UPDATE 2:

Now I've learnt more about PAM, I've updated the post with a copy of my common-auth file, since that's the one being used at login (not common-password)

share|improve this question

1 Answer 1

up vote 3 down vote accepted

Turns out the answer was in the documentation! I just needed to first figure out what the problem was, and then go back checking each element of the setup:

http://manpages.ubuntu.com/manpages/natty/man8/pam_sss.8.html

Adding the option "forward_pass" to pam_sss.so tells the SSSD module to put the entered passphrase on the stack, so that other modules (i.e. pam_ecryptfs.so) can use the information.

So my ecryptfs + SSSD enabled /etc/pam.d/common-auth file looks like this:

auth    [success=3 default=ignore]  pam_sss.so forward_pass
auth    [success=2 default=ignore]  pam_unix.so nullok_secure try_first_pass
auth    [success=1 default=ignore]  pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass

auth    requisite   pam_deny.so
auth    required    pam_permit.so
auth    optional    pam_ecryptfs.so unwrap

Note: having the word "debug" at the end of the pam_ecryptfs.so line also broke things!

I've certainly learnt a lot about PAM, ecryptfs and gnome-keyring today! Hope this helps people in future - and I may even submit a feature request to get it added as a default setting.

share|improve this answer
    
Big +1 for answering the question after you've solved the problem. Excellent :) (don't forget to accept it in two days) –  Stefano Palazzo Aug 14 '11 at 8:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.