O serviço OpenVPN para no pedido da senha da chave privada: como corrigir

OpenVPN pede a frase-passe da chave privada na máquina local, por isso um ficheiro de início de sessão funcional nunca lhe responde. Num serviço não há terminal onde escrever, e o arranque ou fica pendurado ou falha com uma entrada de journal que nomeia a entrada e não a causa. Estão envolvidos dois segredos, e cada um precisa da sua própria fonte legível antes de a unidade ser reiniciada. O percurso abaixo separa-os e depois verifica a identidade que realmente abre cada ficheiro.

Distinga os dois pedidos

A frase-passe da chave decifra a chave privada local; as credenciais da conta autenticam a sessão no servidor. Vêm de locais diferentes, falham em momentos diferentes e produzem mensagens diferentes. Confundi-las leva as pessoas a procurar uma reposição de palavra-passe quando a conta não estava envolvida. Leia o texto do pedido antes de alterar qualquer opção, porque a formulação é a única pista fiável sobre qual segredo falta.

No Community OpenVPN 2.x, askpass indica um ficheiro que guarda a frase-passe da chave na primeira linha, e auth-user-pass indica um ficheiro com o nome de utilizador numa linha e a palavra-passe na seguinte. Nenhum dos ficheiros satisfaz a outra opção. Uma aplicação de ambiente de trabalho ou um perfil do NetworkManager podem guardar ambos no seu próprio cofre de segredos, que um cliente de linha de comandos nunca lê, por isso anote que cliente está a configurar antes de escrever qualquer caminho.

Aponte ambas as opções para ficheiros legíveis

Um perfil que precisa das duas entradas acaba com três referências a ficheiros: a chave cifrada, a frase-passe que a desbloqueia e o par de início de sessão. Acrescente-as sem tocar na CA nem nas verificações de identidade, porque essas decidem quem é o servidor e não fazem parte deste problema. Se a implementação não usar credenciais de conta de todo, acrescentar auth-user-pass cria uma entrada que ninguém consegue fornecer.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

As opções sem argumento comportam-se de forma diferente das opções com caminho, e num serviço a diferença importa. Um askpass sem argumento continua a ler a consola, e um ficheiro auth-user-pass com apenas um nome de utilizador continua a deixar um pedido de palavra-passe à espera. Assim que o cliente passa a daemon já não consegue pedir entrada a um terminal, por isso um serviço configurado assim não arranca.

Os caminhos absolutos eliminam a questão do diretório de trabalho mas não concedem acesso. A propriedade, o modo e a travessia vêm a seguir, e os três são verificados em relação à conta com que o processo corre.

Leia a configuração da unidade antes do perfil

É a unidade, e não o ficheiro que estava a editar, que decide que configuração a instância carrega. Leia a sua linha de comandos e quaisquer drop-ins, e depois siga o diretório de trabalho até ao perfil que é realmente usado. Uma referência à frase-passe acrescentada a outro ficheiro .ovpn não altera nada para esta instância.

Três comandos só de leitura respondem à maior parte. O primeiro imprime a unidade e quaisquer drop-ins, o segundo a identidade e as definições de sandbox que limitam o processo, e o terceiro aquilo de que o último arranque se queixou realmente. Use o nome de instância que existe no anfitrião:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Repare em ProtectHome e nas opções próprias do perfil user, group e chroot. Um ficheiro sob um diretório pessoal pode ser legível na sua shell e invisível dentro do serviço quando os diretórios pessoais são ocultados. A conta com que o systemd arranca não é sempre a conta que acaba por abrir a chave.

Prove que a identidade de execução consegue abrir ambos os ficheiros

Ler o modo não basta, porque cada diretório do caminho tem de ser atravessável pela mesma identidade. Percorra o caminho componente a componente e depois teste a abertura como a conta que o processo usa. Um ficheiro com modo 600 pertencente a root só funciona enquanto o processo ainda é root, o que não é verdade depois da descida de privilégios que muitos perfis fazem. Dois comandos cobrem a travessia e a abertura:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

O primeiro comando imprime o modo de cada componente e falha onde a conta não consegue atravessar; o segundo responde à única pergunta importante: se a identidade de execução consegue abrir o ficheiro para leitura. Nenhum imprime o conteúdo do ficheiro, e é exatamente esse o ponto quando o ficheiro guarda uma frase-passe. Repita o teste para o ficheiro de início de sessão, porque os dois são muitas vezes guardados com proprietários diferentes.

Se o processo usar um chroot ou um namespace restrito, execute o mesmo teste de dentro dessa vista, ou a resposta descreve o sistema de ficheiros errado. Uma frase-passe guardada sob um diretório pessoal oculto é o exemplo habitual de um teste que passa fora da unidade e falha dentro.

Verifique o primeiro arranque e depois uma reconexão

Arranque a instância uma vez e leia a primeira falha, não a última. Um ficheiro de entrada em falta, uma decifração da chave falhada e um AUTH_FAILED do servidor são três acontecimentos diferentes com três reparações diferentes. Corrigir um aviso de permissões não prova nada sobre se a chave foi desbloqueada.

A linha do journal diz qual dos três tem. A reparação decorre de qual entrada falhou:

Depois teste o ciclo de vida de que realmente precisa: um arranque no boot e qualquer reconexão suportada, não apenas um arranque manual a partir da sua shell. Com auth-nocache as entradas são descartadas após o primeiro uso, por isso uma reconexão posterior continua a precisar de uma fonte legível. Um porta-chaves desbloqueado no início de sessão do ambiente de trabalho não está disponível para um serviço que arrancou antes de alguém iniciar sessão, e é essa a razão habitual para um teste manual passar e um reinício falhar. Se o primeiro arranque tiver êxito e uma reconexão posterior falhar, leia o journal para o evento de reconexão antes de voltar a alterar permissões.

Guardar a frase-passe ao lado da chave reduz o que a cifra lhe dá, por isso restrinja esse ficheiro e as suas cópias de segurança. Trate a remoção da frase-passe da chave como uma decisão de credenciais separada, e não como a reparação de uma entrada em falta. Uma implementação que depende de aprovação humana ou de MFA interativa precisa do seu agente ou integração de gestão suportados; um código de uso único guardado permanentemente não é um substituto equivalente.