☰

SSSD + Criptografado /home, não é mais montado automaticamente no login

tag-icon • tag-icon ecryptfs pam
SSSD + Criptografado /home, não é mais montado automaticamente no login

Troquei algumas caixas paraSSSD, então eles agora são autenticados em um servidor LDAP central e armazenam em cache as credenciais quando estou offline. Isso funciona bem e os pacotes do Ubuntu foram instalados corretamente.

Mas agora, quando faço login, meu diretório inicial não é mais descriptografado/montado automaticamente. Se eu sair do GDM e fazer login no console, recebo este erro:

keyctl_seach Required key not avaliable

Se eu executar o comando sugerido (ecryptfs-mount-privado) e forneça minha senha, meu diretório inicial está desbloqueado corretamente.

Estou tentando entender como o processo de login mudou, de forma que minha senha não desbloqueia mais a chave de criptografia automaticamente. Eu acho que é um problema de PAM, então incluí meu/etc/pam.d/common-autharquivo abaixo.

Presumo que a senha esteja sendo passada para o SSSD e, em seguida, pule qualquer etapa usual para desbloquear a chave. Alguém pode explicar como isso é feito normalmente?

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

ATUALIZAÇÃO 1:

auth.log está relatando este erro quando um usuário faz login:

login[14202]: NULL passphrase; aborting

Um google só encontra esse erro na fonte de pam_ecryptfs.so e é acionado quando o PAM_AUTHTOK recebido é NULL:

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

Portanto, pelo menos pam_ecryptfs.so está sendo chamado (ou seja, não está sendo ignorado porque o SSSD está em vigor).No entanto, por que está recebendo uma senha NULL?

ATUALIZAÇÃO 2:

Agora que aprendi mais sobre o PAM, atualizei o post com uma cópia do meuautenticação comumarquivo, já que é aquele que está sendo usado no login (nãosenha comum)

Responder1

Acontece que a resposta estava na documentação! Eu só precisava primeiro descobrir qual era o problema e depois voltar a verificar cada elemento da configuração:

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

Adicionando a opção "Passar para a frente" to pam_sss.so diz ao módulo SSSD para colocar a senha inserida na pilha, para que outros módulos (ou seja, pam_ecryptfs.so) possam usar as informações.

Portanto, meu arquivo /etc/pam.d/common-auth habilitado para ecryptfs + SSSD se parece com isto:

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

Observação:ter a palavra "debug" no final da linha pam_ecryptfs.so também quebrou as coisas!

Certamente aprendi muito sobre PAM, ecryptfs e gnome-keyring hoje! Espero que isso ajude as pessoas no futuro - e posso até enviar uma solicitação de recurso para adicioná-lo como configuração padrão.

informação relacionada