SSSD + Criptografado / home, não há mais montagens automáticas no login

Question

Eu mudei algumas caixas para SSSD , para que agora elas se autentiquem em um servidor LDAP central e armazenem em cache as credenciais quando Estou offline. Isso funciona bem, e os pacotes do Ubuntu instalados corretamente.

Mas agora, quando faço o login, meu diretório pessoal não é mais descriptografado / montado automaticamente. Se eu desistir do GDM e fizer login no console, será apresentado este erro:

keyctl_seach Required key not avaliable

Se eu executar o comando sugerido ( ecryptfs-mount-private ) e fornecer essa minha senha, meu diretório pessoal será desbloqueado corretamente.

Estou tentando entender como o processo de login mudou, de modo que minha senha não está mais desbloqueando a chave de criptografia automaticamente. Eu acho que é um problema do PAM, então incluí meu arquivo /etc/pam.d/common-auth abaixo.

Eu presumo que a senha está sendo passada para o SSSD, então pule qualquer passo que seja feito para destravar 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

UPDATE 1:

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

login[14202]: NULL passphrase; aborting

Um google só exibe 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 o pam_ecryptfs.so está sendo chamado (isto é, não é porque está sendo ignorado porque o SSSD está no lugar). No entanto, por que está obtendo uma frase secreta NULL?

UPDATE 2:

Agora eu aprendi mais sobre o PAM, atualizei a postagem com uma cópia do meu arquivo common-auth , já que é o que está sendo usado no login (não comum senha )

    

Answer 1

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

link

Adicionando a opção " forward_pass " ao pam_sss.so diz ao módulo SSSD para colocar a senha digitada na pilha, para que outros módulos (por exemplo, pam_ecryptfs.so) possam usar as informações.

Assim, meu arquivo /etc/pam.d/common-auth ecryptfs + SSSD ativado é assim:

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!

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