Empêcher NetworkManager d’afficher un mot de passe VPN enregistré

NetworkManager peut conserver un mot de passe VPN pour que la connexion monte sans que personne ne le saisisse, et il peut réafficher cette valeur via l’éditeur ou via nmcli --show-secrets. Trois modèles de propriété existent, et le comportement d’affichage n’est qu’un symptôme de celui que vous avez choisi. Choisissez d’abord le modèle, puis définissez l’indicateur qui lui correspond, plutôt que de masquer un champ avec un texte de remplacement qui déroutera la personne suivante.

Trois modèles de propriété

Le premier modèle demande à chaque fois. Rien n’est stocké, le secret n’existe que pendant l’activation, et quiconque démarre la connexion doit connaître le mot de passe. C’est l’option la moins pratique et la plus facile à défendre.

Le second confie le secret à un trousseau de clés appartenant à l’utilisateur. L’agent se déverrouille au début de la session et fournit la valeur à la demande, ce qui la garde hors du fichier de connexion mais lie la connexion à la session de cet utilisateur. Deux conditions en découlent : l’agent doit tourner, et il doit être déverrouillé.

Le troisième stocke un justificatif protégé pour une connexion système. Il survit aux redémarrages et fonctionne avant que quiconque se connecte, et en échange la valeur réside sur le disque, protégée par les permissions de fichier plutôt que par le chiffrement.

Chaque modèle est raisonnable dans le bon contexte. L’erreur est de les mélanger, et c’est ainsi qu’un portable finit avec un secret à deux endroits et sans réponse claire sur celui qui fait foi. Notez quel modèle un profil utilise. Une ligne dans le manuel de l’équipe évite à la personne suivante d’inventer un quatrième endroit où chercher.

Lisez l’état actuel avant de le modifier

Examinez le profil et l’état du secret en tant qu’utilisateur qui gère la connexion. La seconde commande est celle qui vous dit si la valeur est réellement lisible.

nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnection

Un fichier de clé dans ce répertoire appartient normalement à root avec le mode 600. Cela écarte les utilisateurs ordinaires et n’écarte pas root, ce qui compte quand la même machine est partagée ou quand une sauvegarde s’exécute en root.

Les permissions de fichier sont une frontière, pas un chiffrement. Quiconque peut lire le fichier en root a le mot de passe en clair. C’est un compromis acceptable pour un serveur sans surveillance et médiocre pour un poste de travail partagé. L’écrire une fois évite une longue discussion sur le point de savoir si la valeur est protégée.

Ce que fait chaque valeur d’indicateur

Le secret VPN porte une propriété flags, et les valeurs ne sont pas intuitives à partir des seuls nombres.

Le comportement effectif dépend aussi du greffon et du fait qu’un agent tourne ou non, alors traitez le tableau comme le contrat et le comportement observé comme ce que vous vérifiez. Une valeur qui fonctionne sur un poste de travail peut se comporter différemment sur un serveur sans session. C’est dans cet écart que vivent la plupart des tickets déroutants.

Définissez la propriété explicitement au lieu de supprimer une ligne en espérant. Un indicateur absent n’est pas une politique, et la prochaine mise à jour du paquet peut le remplir avec quelque chose que vous n’aviez pas prévu.

Faites correspondre le modèle au moment où la connexion démarre

Si la connexion ne démarre que lorsqu’un utilisateur est connecté, la propriété par l’agent convient bien et garde le secret hors du fichier. Si elle démarre au boot, avant qu’aucune session n’existe, un agent ne peut pas vous aider.

C’est toute la décision pour la plupart des machines. Cela explique aussi une classe de rapports déroutants où la connexion fonctionne en interactif et échoue après un redémarrage. L’indicateur n’a jamais changé ; le contexte, si.

Pour le cas sans surveillance, la réponse pratique est un fichier restreint appartenant à root ou une source de justificatifs approuvée. Gardez-le hors du profil de connexion si ce profil est un jour exporté ou copié vers une autre machine.

Si la valeur était déjà visible, changez-la

Modifier un indicateur laisse le mot de passe lui-même intact. Une valeur apparue dans une capture d’écran, dans l’historique du shell, dans un paquet envoyé au support ou dans un fichier que d’autres utilisateurs pouvaient ouvrir doit être considérée comme divulguée.

Changez-la sur le serveur, puis corrigez le client et terminez toute session qui s’est authentifiée avec l’ancienne. Supprimer la connexion locale ne révoque rien en face, et c’est la partie que les gens oublient.

Ensuite, cessez de mettre le mot de passe sur la ligne de commande. Il atterrit dans l’historique du shell et peut apparaître dans une liste de processus ; utilisez plutôt l’invite interactive ou l’agent.

Vérifiez en vous reconnectant

Répétez la commande qui a montré le secret et confirmez que le champ n’est plus affiché. Puis déconnectez-vous et reconnectez-vous, et redémarrez si la connexion démarre automatiquement, car la panne intéressante n’apparaît que lorsque le contexte de session change.

Si le secret apparaît encore, un autre profil ou un autre agent le fournit. Inspectez la connexion active et le trousseau de clés au lieu de supprimer des fichiers jusqu’à ce que le symptôme se déplace.