Où Linux doit-il stocker votre mot de passe VPN ? Pas dans le profil

Le mot de passe VPN doit vivre quelque part : dans le profil de connexion, dans un trousseau déverrouillé par le bureau, ou nulle part. NetworkManager appelle ce choix un indicateur de secret, et choisir le mauvais est la raison pour laquelle une connexion fonctionne après la connexion utilisateur et échoue en tant que service. L’indicateur est une ligne de configuration, et il décide lequel de ces trois résultats vous obtenez.

Trois indicateurs couvrent presque tous les cas, et la décision porte sur le moment où la connexion démarre.

Trois indicateurs de secret, trois comportements

Un indicateur à 0 signifie que le secret est enregistré avec la connexion, dans n’importe quel magasin qui détient le profil. Un indicateur à 1 le rend détenu par un agent : le secret vient d’un agent de secrets comme un trousseau de bureau, et NetworkManager le demande à l’activation. Un indicateur à 2 signifie non enregistré, donc le secret n’est jamais écrit et doit être fourni à chaque fois. L’indicateur 4 marque un secret comme non requis, pour les connexions qui n’en ont vraiment pas besoin.

Réglez les indicateurs par secret plutôt que par connexion. Une connexion peut avoir un mot de passe détenu par un agent et une phrase secrète de clé privée enregistrée.

Décidez selon le moment où la connexion démarre

Si un utilisateur connecté démarre la connexion, la détention par un agent est le choix par défaut raisonnable : le trousseau est déverrouillé par la connexion et le secret ne repose jamais dans un fichier. Si la connexion doit démarrer avant que quiconque se connecte, la détention par un agent est le mauvais choix, car il n’y a aucun trousseau de session à déverrouiller.

Voilà toute la décision. Tout le reste en est une variante.

Pour un service avant connexion, le modèle pris en charge est un magasin à l’échelle du système ou un fichier de clé protégé, et les permissions du fichier deviennent la protection. Ne résolvez pas le problème en collant le mot de passe dans un script shell exécuté au démarrage.

Ce que le trousseau apporte et ce qu’il n’apporte pas

Un trousseau garde le secret hors du profil de connexion et le lie à une session utilisateur. Il ne rend pas le secret disponible à un service sans session, et il ne chiffre rien sur le réseau. Ce sont des propriétés distinctes que les gens fusionnent souvent. Ce qu’il apporte vraiment, c’est un rayon d’impact plus réduit lorsqu’un fichier de profil fuit.

La clé privée référencée par le profil a besoin de ses propres permissions, indépendamment de l’endroit où vit le mot de passe.

Diagnostic sans déverser de secrets

Les noms de connexion, les UUID et les indicateurs suffisent généralement à expliquer une panne. nmcli connection show liste le profil, et les indicateurs de secret vous disent d’où le mot de passe était censé venir.

Évitez --show-secrets dans les tickets et les discussions. Une fois collé, c’est un identifiant dans une transcription.

Le stockage n’est pas la révocation

Retirer un secret d’un trousseau n’invalide pas l’identifiant que l’opérateur distant a déjà accepté. La révocation d’un compte est une action côté serveur, et le stockage local est une question distincte avec un propriétaire distinct.

Décidez les deux avant l’incident, pas pendant. Une connexion utilisateur interactive et un service avant connexion demandent des réponses différentes, et un script shell partagé n’est ni l’une ni l’autre. La documentation de NetworkManager sur les indicateurs de secret liste les valeurs en entier.