¿Dónde debería Linux guardar tu contraseña de VPN? No en el perfil
Los indicadores de secreto de NetworkManager deciden si el perfil, un agente de llavero o nadie guarda la contraseña. La respuesta depende de cuándo arranca la conexión.
La contraseña de VPN tiene que vivir en algún sitio: en el perfil de conexión, en un llavero que el escritorio desbloquea o en ninguno. NetworkManager llama a esa elección indicador de secreto, y elegir el equivocado es la razón por la que una conexión funciona tras iniciar sesión y falla como servicio. El indicador es una línea de configuración y decide cuál de esos tres resultados obtienes.
Tres indicadores cubren casi todos los casos, y la decisión trata de cuándo arranca la conexión.
Tres indicadores de secreto, tres comportamientos
Un indicador 0 significa que el secreto se guarda con la conexión, en cualquier almacén que contenga el perfil. Un indicador 1 lo hace propiedad del agente: el secreto viene de un agente de secretos como un llavero de escritorio, y NetworkManager lo pide al activar. Un indicador 2 significa no guardado, así que el secreto nunca se escribe y debe aportarse cada vez. El indicador 4 marca un secreto como no necesario, para conexiones que de verdad no necesitan ninguno.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Configura los indicadores por secreto en lugar de por conexión. Una conexión puede tener una contraseña propiedad del agente y una frase de paso de clave privada guardada.
Decide según cuándo arranca la conexión
Si un usuario con sesión iniciada arranca la conexión, la propiedad del agente es el valor predeterminado sensato: el llavero se desbloquea con el inicio de sesión y el secreto nunca queda en un archivo. Si la conexión debe levantarse antes de que nadie inicie sesión, la propiedad del agente es la elección equivocada, porque no hay llavero de sesión que desbloquear.
Esa es toda la decisión. Todo lo demás es una variante.
Para un servicio anterior al inicio de sesión, el patrón admitido es un almacén de ámbito de sistema o un archivo de clave protegido, y los permisos del archivo pasan a ser la protección. No resuelvas el problema pegando la contraseña en un script de shell que se ejecuta al arrancar.
Qué da el llavero y qué no
Un llavero mantiene el secreto fuera del perfil de conexión y lo ata a una sesión de usuario. No hace que el secreto esté disponible para un servicio sin sesión, ni cifra nada en la red. Son propiedades separadas que la gente suele fusionar. Lo que sí compra es un radio de daño menor cuando un archivo de perfil se filtra.
La clave privada a la que hace referencia el perfil necesita sus propios permisos, independientemente de dónde viva la contraseña.
Diagnóstico sin volcar secretos
Los nombres de conexión, los UUID y los indicadores suelen bastar para explicar un fallo. nmcli connection show lista el perfil, y los indicadores de secreto te dicen de dónde debía venir la contraseña.
Evita --show-secrets en tickets y chats. Una vez pegado, es una credencial en una transcripción.
Almacenar no es revocar
Quitar un secreto de un llavero no invalida la credencial que el operador remoto ya aceptó. La revocación de la cuenta es una acción del lado del servidor, y el almacenamiento local es un asunto aparte con un propietario aparte.
Decide ambas cosas antes del incidente, no durante. Una conexión interactiva de usuario y un servicio anterior al inicio de sesión necesitan respuestas distintas, y un script de shell compartido no es ninguna de las dos. La documentación de NetworkManager sobre los indicadores de secreto lista los valores completos.