SSSD + Зашифрованный / домой, больше не автомонтируется при входе в систему

Я переключил несколько полей на SSSD, таким образом, они теперь проходят проверку подлинности против центрального сервера LDAP и кэшируют учетные данные, когда я в режиме офлайн. Это хорошо работает, и пакеты Ubuntu установленный штраф.

Но теперь когда я вхожу в систему, мой корневой каталог больше не автодешифруется/монтируется. Если я выпадаю из GDM и входа в систему в консоли, мне дарят эту ошибку:

keyctl_seach Required key not avaliable

Если я выполняю предложенную команду (ecryptfs-mount-private) и даю тот мой пароль, мой корневой каталог разблокирован прекрасный.

Я пытаюсь понять, как процесс входа в систему изменился, такой, что мой пароль больше не разблокировал ключ шифрования автоматически. Я полагаю, что это - проблема PAM, таким образом, я включал мой/etc/pam.d/common-auth файл ниже.

Я предполагаю, что пароль передается SSSD, затем пропущение любого шага обычно сделанный для разблокирования ключа. Кто-то может объяснить, как это обычно сделанный?

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

ОБНОВЛЕНИЕ 1:

auth.log сообщает об этой ошибке, когда пользователь входит в систему:

login[14202]: NULL passphrase; aborting

Google только поднимает эту ошибку в источнике pam_ecryptfs.so и инициирован, когда полученный PAM_AUTHTOK ПУСТОЙ:

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

Таким образом, как наименьшее количество pam_ecryptfs.so называют (т.е. не то, чтобы он пропускается, потому что SSSD существует). Однако, почему это получает ПУСТОЙ пароль?


ОБНОВЛЕНИЕ 2:

Теперь я узнал больше о PAM, я обновил сообщение с копией моего общего подлинного файла, так как это - то, используемое при входе в систему (не общий пароль)

5
задан 13 August 2011 в 12:54

1 ответ

Оказывается, что ответ был в документации! Я просто должен был сначала выяснить то, чем была проблема, и затем возвратитесь, проверив каждый элемент установки:

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

Добавление опции "forward_pass" к pam_sss.so говорит модулю SSSD помещать вводимый пароль на стек, так, чтобы другие модули (т.е. pam_ecryptfs.so) могли использовать информацию.

Так мой ecryptfs + SSSD, включенный/etc/pam.d/common-auth, файл похож на это:

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

Примечание: наличие слова "отладка" в конце pam_ecryptfs.so строки также повредило вещи!

Я, конечно, узнал много о PAM, ecryptfs и брелоке для ключей гнома сегодня! Надежда это помогает людям в будущем - и я могу даже отправить запрос новых функций для получения добавленного как настройка по умолчанию.

5
ответ дан 23 November 2019 в 09:28

Другие вопросы по тегам:

Похожие вопросы: