☰

SSSD + Verschlüsseltes /home, wird beim Anmelden nicht mehr automatisch gemountet

tag-icon • tag-icon ecryptfs pam
SSSD + Verschlüsseltes /home, wird beim Anmelden nicht mehr automatisch gemountet

Ich habe ein paar Boxen umgestellt aufSSSD, sodass sie sich jetzt gegenüber einem zentralen LDAP-Server authentifizieren und die Anmeldeinformationen zwischenspeichern, wenn ich offline bin. Das funktioniert einwandfrei und die Ubuntu-Pakete wurden problemlos installiert.

Aber wenn ich mich jetzt anmelde, wird mein Home-Verzeichnis nicht mehr automatisch entschlüsselt/gemountet. Wenn ich GDM verlasse und mich an der Konsole anmelde, wird mir dieser Fehler angezeigt:

keyctl_seach Required key not avaliable

Wenn ich den vorgeschlagenen Befehl ausführe (ecryptfs-mount-privat) und gebe mein Passwort ein. Dann ist mein Home-Verzeichnis problemlos entsperrt.

Ich versuche zu verstehen, wie sich der Anmeldevorgang geändert hat, sodass mein Passwort den Verschlüsselungsschlüssel nicht mehr automatisch entsperrt. Ich gehe davon aus, dass es sich um ein PAM-Problem handelt, also habe ich meine/etc/pam.d/common-authDatei unten.

Ich gehe davon aus, dass das Passwort an SSSD weitergegeben wird und dann der übliche Schritt zum Entsperren des Schlüssels übersprungen wird. Kann jemand erklären, wie das normalerweise gemacht wird?

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 meldet diesen Fehler, wenn sich ein Benutzer anmeldet:

login[14202]: NULL passphrase; aborting

Bei einer Google-Suche wird dieser Fehler nur in der Quelle von pam_ecryptfs.so angezeigt. Er wird ausgelöst, wenn das empfangene PAM_AUTHTOK NULL ist:

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

Daher wird zumindest pam_ecryptfs.so aufgerufen (d. h. es wird nicht übersprungen, weil SSSD vorhanden ist).Warum wird jedoch eine NULL-Passphrase erhalten?

UPDATE 2:

Nachdem ich nun mehr über PAM erfahren habe, habe ich den Beitrag mit einer Kopie meinergemeinsame AuthentifizierungDatei, da diese beim Login verwendet wird (nichtgemeinsames Passwort)

Antwort1

Es stellte sich heraus, dass die Antwort in der Dokumentation stand! Ich musste nur zuerst herausfinden, wo das Problem lag, und dann zurückgehen und jedes Element des Setups überprüfen:

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

Durch Hinzufügen der Option „Weiterleitungspass" an pam_sss.so weist das SSSD-Modul an, die eingegebene Passphrase auf den Stapel zu legen, damit andere Module (z. B. pam_ecryptfs.so) die Informationen verwenden können.

Meine Datei /etc/pam.d/common-auth mit aktiviertem ecryptfs und SSSD sieht also folgendermaßen aus:

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

Notiz:Das Wort „debug“ am Ende der Zeile pam_ecryptfs.so hat auch einiges kaputt gemacht!

Ich habe heute definitiv viel über PAM, ecryptfs und Gnome-Keyring gelernt! Ich hoffe, das hilft den Leuten in Zukunft – und vielleicht reiche ich sogar eine Funktionsanforderung ein, um es als Standardeinstellung hinzuzufügen.

verwandte Informationen