web-dev-qa-db-fra.com

SSSD + crypté / home, ne se monte plus automatiquement à la connexion

J'ai basculé quelques cases vers SSSD , donc elles s'authentifient désormais auprès d'un serveur LDAP central et mettent en cache les informations d'identification lorsque je suis hors ligne. Cela fonctionne correctement et les packages Ubuntu sont installés correctement.

Mais maintenant, lorsque je me connecte, mon répertoire personnel n'est plus décrypté/monté automatiquement. Si je quitte GDM et me connecte à la console, je reçois cette erreur:

keyctl_seach Required key not avaliable

Si j'exécute la commande suggérée ( ecryptfs-mount-private) et que je donne mon mot de passe, mon répertoire personnel est déverrouillé correctement.

J'essaie de comprendre comment le processus de connexion a changé, de sorte que mon mot de passe ne déverrouille plus automatiquement la clé de cryptage. Je pense que c'est un problème PAM, j'ai donc inclus mon fichier /etc/pam.d/common-auth ci-dessous.

Je suppose que le mot de passe est transmis à SSSD, puis je saute toute étape habituelle pour déverrouiller la clé. Quelqu'un peut-il expliquer comment cela se fait habituellement?

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

MISE À JOUR 1:

auth.log signale cette erreur lorsqu'un utilisateur se connecte:

login[14202]: NULL passphrase; aborting

Un google ne révèle cette erreur que dans la source de pam_ecryptfs.so, et est déclenché lorsque le PAM_AUTHTOK reçu est NULL:

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

Donc, au moins pam_ecryptfs.so est appelé (c'est-à-dire que ce n'est pas qu'il est ignoré parce que SSSD est en place). Mais pourquoi obtient-il une phrase secrète NULL?

MISE À JOUR 2:

Maintenant que j'en ai appris plus sur PAM, j'ai mis à jour le message avec une copie de mon fichier common-auth, puisque c'est celui utilisé lors de la connexion (pas common- mot de passe)

ecryptfspam
5
Coops

Il s'avère que la réponse était dans la documentation! Je devais juste comprendre d'abord quel était le problème, puis revenir en arrière en vérifiant chaque élément de la configuration:

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

L'ajout de l'option " forward_pass " à pam_sss.so indique au module SSSD de mettre la phrase secrète entrée sur la pile, de sorte que les autres modules (par exemple pam_ecryptfs.so ) peut utiliser les informations.

Donc mon fichier ecryptfs + SSSD activé /etc/pam.d/common-auth ressemble à ceci:

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

Remarque: avoir le mot "debug" à la fin de la ligne pam_ecryptfs.so a également cassé les choses!

J'ai certainement beaucoup appris sur PAM, ecryptfs et gnome-keyring aujourd'hui! J'espère que cela aidera les gens à l'avenir - et je peux même soumettre une demande de fonctionnalité pour l'ajouter comme paramètre par défaut.

4
Coops