O nmcli continua a pedir a palavra-passe da VPN: guarde o segredo localmente

O mesmo perfil, duas sessões: liga-se a partir do ambiente de trabalho e fica pendurado por SSH num pedido a que nada consegue responder. Nada está avariado e nenhuma definição se perdeu. O NetworkManager está a pedir a credencial a um agente de segredos, e um agente de segredos é um componente do ambiente de trabalho que não existe na sessão que está a usar.

Execute a sequência abaixo e o túnel sobe sem interface gráfica, com a ressalva de que guardar um segredo altera quem pode usar esse perfil.

Confirme o diagnóstico antes de alterar o que quer que seja

A diferença entre ativação interativa e não interativa é todo o diagnóstico. Se nmcli --ask connection up tiver êxito enquanto uma ativação normal encrava, o perfil está correto e falta a origem do segredo. Essa única comparação poupa-lhe reescrever uma configuração que funciona.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Leia os indicadores em vez de os adivinhar. Os valores que significam "perguntar a um agente" são o que procura, e os nomes exatos das chaves variam entre plugins de VPN porque vivem no dicionário de dados do próprio plugin. Um perfil FortiSSL e um perfil IPsec não usam necessariamente os mesmos nomes, por isso trabalhe a partir da saída do seu próprio perfil.

Confirme também que o pacote do plugin para esse protocolo está instalado. Um plugin em falta aparece como um tipo de ligação desconhecido ou como um erro de ativação que não diz nada sobre palavras-passe, e andar atrás do segredo nesse estado desperdiça a mesma hora duas vezes. Uma consulta de pacotes é mais barata do que uma tarde inteira a editar ficheiros de chaves.

Mova o segredo para o ficheiro de chaves

O ficheiro de ligação vive em /etc/NetworkManager/system-connections/. Os segredos não são guardados aí por predefinição, e é esse o sentido dos indicadores que acabou de ler. Alterar um indicador para zero diz ao NetworkManager que o valor está guardado com o perfil em vez de ser pedido no momento da ativação.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

Para um perfil com dois segredos, o padrão repete-se: um indicador por segredo na secção [vpn], e os valores em [vpn-secrets]. Um perfil IPsec transporta normalmente uma chave pré-partilhada ao lado da credencial do utilizador, e o plugin dá-lhes nomes diferentes de um campo de palavra-passe normal, por isso copie os nomes das chaves da saída de vpn.data em vez de um artigo de blogue que usava outro plugin. Um único nome de chave errado produz um perfil que carrega e depois falha na autenticação, o que se lê exatamente como uma palavra-passe errada. Compare o seu ficheiro com um perfil funcional do mesmo plugin antes de voltar a ligar-se.

Coloque entre aspas os valores que contenham espaços, aspas ou um sinal de dólar. Um valor sem aspas com um $ lá dentro será lido literalmente ou expandido consoante o local onde é analisado, e a falha de autenticação resultante parece uma palavra-passe errada.

Depois corrija o proprietário e o modo do ficheiro. Estes ficheiros de chaves são lidos por um serviço privilegiado, e um ficheiro que outros utilizadores podem ler é considerado não fidedigno, que é a razão habitual pela qual um perfil editado parece ser ignorado. Proprietário root, modo 600, sem exceções.

Recarregue e depois ative

O ficheiro é lido quando a ligação é carregada, por isso editá-lo não chega. Recarregue os perfis e depois levante a ligação explicitamente.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Se o recarregamento não apanhar a alteração, um reinício completo do serviço apanha-a, e há relatos exatamente disso. Prefira o recarregamento quando outras ligações importam, porque reiniciar o serviço corta todas as ligações geridas, e num anfitrião remoto isso pode terminar a sua sessão antes de o túnel que queria estar no ar.

Use o UUID quando os nomes são ambíguos. As máquinas com vários perfis de clientes acumulam quase-duplicados, e ativar o errado produz uma falha que parece um problema de credenciais.

Quando o segredo guardado não é o problema

Um perfil FortiSSL pode falhar mesmo com uma credencial guardada correta porque o cliente nunca confia no certificado da gateway. Essa definição não está na caixa de diálogo principal; está atrás das opções avançadas da VPN, onde se introduz o resumo do certificado fidedigno. Se o registo mencionar o certificado em vez da palavra-passe, está neste ramo e nenhuma quantidade de edição de [vpn-secrets] ajudará.

Aqui cabem mais duas verificações. Confirme que o perfil não foi importado de um ficheiro que ainda aponta para um caminho que o plugin não consegue ler, e confirme que o perfil é o ativo e não um duplicado obsoleto. Ambos produzem falhas de ativação que se leem como erros de autenticação.

Decida se guardar é aceitável

Uma PSK e uma palavra-passe guardadas são legíveis por tudo o que corra como root nessa máquina. Numa máquina que controla, é uma troca razoável por um serviço sem interface. Num anfitrião partilhado, merece uma conversa, porque o perfil contém agora uma credencial que antes era protegida pelo porta-chaves do ambiente de trabalho. Pergunte quem mais consegue chegar a root nesse anfitrião antes de decidir, não depois de a alteração estar feita.

Se a política proibir guardar segredos de VPN, não enfraqueça o perfil para fazer funcionar uma tarefa cron. Execute a ligação a partir de uma sessão que tenha um agente, ou use outro mecanismo para a automatização.

Por último, registe que perfis transportam segredos para que ninguém copie um para um portátil sem reparar. Um comentário acima da secção de segredos com a data e o motivo é suficiente, e poupará a alguém uma revisão incómoda mais tarde.