Onde o Linux deve guardar a sua palavra-passe VPN? Não no perfil

A palavra-passe VPN tem de viver em algum lugar: no perfil de ligação, num porta-chaves que o ambiente de trabalho desbloqueia, ou em lado nenhum. O NetworkManager chama a essa escolha flag de segredo, e escolher a errada é a razão pela qual uma ligação funciona após o início de sessão e falha como serviço. A flag é uma linha de configuração, e decide qual destes três resultados obtém.

Três flags cobrem quase todos os casos, e a decisão é sobre quando a ligação começa.

Três flags de segredo, três comportamentos

Uma flag 0 significa que o segredo é guardado com a ligação, em qualquer armazenamento que contenha o perfil. Uma flag 1 torna-o propriedade do agente: o segredo vem de um agente de segredos como um porta-chaves do ambiente de trabalho, e o NetworkManager pede-o na ativação. Uma flag 2 significa não guardado, por isso o segredo nunca é escrito e tem de ser fornecido de cada vez. A flag 4 marca um segredo como não necessário, para ligações que realmente não precisam de nenhum.

Defina as flags por segredo em vez de por ligação. Uma ligação pode ter uma palavra-passe propriedade do agente e uma frase-passe de chave privada guardada.

Decida conforme o momento em que a ligação começa

Se um utilizador com sessão iniciada começar a ligação, a propriedade do agente é a predefinição sensata: o porta-chaves é desbloqueado pelo início de sessão e o segredo nunca fica num ficheiro. Se a ligação tiver de subir antes de alguém iniciar sessão, a propriedade do agente é a escolha errada, porque não há porta-chaves de sessão para desbloquear.

É toda a decisão. Tudo o resto é uma variante.

Para um serviço antes do início de sessão, o padrão suportado é um armazenamento ao nível do sistema ou um ficheiro de chave protegido, e as permissões do ficheiro tornam-se a proteção. Não resolva o problema colando a palavra-passe num script de shell que corre no arranque.

O que o porta-chaves dá e o que não dá

Um porta-chaves mantém o segredo fora do perfil de ligação e liga-o a uma sessão de utilizador. Não torna o segredo disponível para um serviço sem sessão, e não cifra nada na rede. São propriedades separadas que as pessoas costumam juntar. O que compra de facto é um raio de dano menor quando um ficheiro de perfil escapa.

A chave privada referida pelo perfil precisa das suas próprias permissões, independentemente de onde vive a palavra-passe.

Diagnóstico sem despejar segredos

Nomes de ligação, UUID e flags costumam bastar para explicar uma falha. nmcli connection show lista o perfil, e as flags de segredo dizem de onde a palavra-passe devia ter vindo.

Evite --show-secrets em tickets e conversas. Uma vez colado, é uma credencial numa transcrição.

Guardar não é revogar

Remover um segredo de um porta-chaves não invalida a credencial que o operador remoto já aceitou. A revogação da conta é uma ação do lado do servidor, e o armazenamento local é um assunto à parte com um proprietário à parte.

Decida ambas as coisas antes do incidente, não durante. Uma ligação interativa de utilizador e um serviço antes do início de sessão exigem respostas diferentes, e um script de shell partilhado não é nenhuma das duas. A documentação do NetworkManager sobre flags de segredo lista os valores por inteiro.