OpenVPN PAM: o argumento de login é um serviço, não um usuário

Um usuário foi adicionado no servidor, a senha foi digitada corretamente e a conexão ainda termina com AUTH_FAILED. A linha do plugin geralmente explica por quê: a palavra depois do caminho do plugin é um nome de serviço PAM, e ela decide qual pilha de módulos responde à pergunta. Não é um nome de usuário, e não é um ponteiro para um arquivo de senhas que OpenVPN lê sozinho.

O que a segunda palavra seleciona

A linha de configuração recebe um caminho de plugin e um argumento:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Esse argumento é passado à biblioteca PAM como o nome do serviço, o que faz a pilha em /etc/pam.d/openvpn ser a executada. Escreva login ali e você obtém, em vez disso, a política de login interativa, com os módulos que essa política incluir na sua distribuição.

Use o caminho do plugin fornecido pelo pacote instalado, não um caminho copiado de outro host. O nome do arquivo e o diretório diferem entre distribuições, e um caminho errado falha na inicialização com um erro de carregamento do plugin, não na autenticação.

Onde a pilha realmente lê as contas

O PAM é um despachante. O arquivo de serviço lista os módulos em ordem, e o primeiro que consegue responder decide o resultado. Uma pilha que chama pam_unix lê contas locais; uma pilha que chama um módulo LDAP ou RADIUS envia as credenciais para outro lugar completamente.

Leia o arquivo para o qual o nome do serviço resolve, incluindo tudo o que ele inclui:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

Se a pilha delega a um diretório, adicionar uma conta local não muda nada. Se ela lê contas locais, criar o usuário no diretório também não muda nada. A conta precisa existir onde a pilha olha, e esse é todo o diagnóstico na maioria destes relatos.

Uma tentativa, dois registros

Correlacione uma única conexão falha nos dois lados. O log do OpenVPN mostra o resultado do plugin e a rejeição do cliente; o log de autenticação do sistema mostra qual módulo rodou e o que ele decidiu. Lê-los na mesma janela de tempo é o que separa um arquivo de serviço ausente de um tempo limite do backend. Uma lacuna no log de autenticação significa que a pilha nunca foi alcançada.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

Teste o serviço diretamente com um utilitário que fale PAM, para não depurar a VPN e a pilha ao mesmo tempo. Um teste direto bem-sucedido com o mesmo nome de serviço e conta restringe o problema a como o daemon passa as credenciais, não à conta em si.

pamtester openvpn alice authenticate

Se o teste direto falhar com as mesmas credenciais que funcionam no console, a pilha não está lendo a origem de contas que você supôs. Se ele funcionar, veja a conversa que o plugin executa e o que o cliente realmente enviou. Execute-o também uma vez com uma senha deliberadamente errada, para ver a diferença entre uma recusa e um erro de módulo. Esses dois resultados parecem idênticos no log da VPN e completamente diferentes aqui.

Um serviço dedicado supera editar o login

Dê à VPN o seu próprio arquivo de serviço quando os requisitos dela diferirem do login interativo, como costumam diferir. Editar login ou common-auth muda a política de todo programa que os inclui, e a próxima pessoa que depurar um problema de login não relacionado herdará a sua alteração.

Copie os módulos de que você precisa para um arquivo de serviço pequeno, mantenha a ordem explícita e anote quem é o dono. Esse arquivo é o que se deve verificar quando uma redefinição de senha parece não ter efeito.

O que o cliente envia, e o que não envia

O cliente fornece um nome de usuário e uma senha por meio do seu prompt ou arquivo compatível. O plugin do servidor passa esses valores para a conversa PAM; ele não os lê da configuração do servidor. Uma linha do lado do servidor que pareça definir uma senha não faz isso, e nenhuma edição de perfil criará uma conta.

Nome de usuário e senha podem coexistir com certificados de cliente, e habilitar o PAM não é motivo para parar de verificar certificados. Mantenha as camadas que a implantação pretendia e corrija apenas a origem das contas.

A aceitação é bilateral: a conta pretendida tem sucesso, e uma conta que deveria ser recusada continua falhando. O README do plugin auth-pam documenta o argumento de serviço e os backends que ele pode atender, e é o lugar para confirmar a disposição que você está tentando construir.