auth-nocache cun ficheiro de credenciais: axuda ou prexudica?

OpenVPN imprime ao arrincar un aviso que suxire auth-nocache, e a resposta tentadora é engadir a opción e ver como a liña desaparece. Ese consello supón un inicio de sesión interactivo. Cando o usuario e o contrasinal viven nun ficheiro, a comparación cambia: a opción deixa de protexer a copia duradeira e, nun cliente que abandona privilexios, pode romper a renegociación máis adiante. Convén manter separados dous modelos de almacenamento antes de editar un perfil.

Dúas formas de responder á petición de credenciais

O primeiro modelo é unha persoa que escribe as credenciais nun terminal, ou unha interface de xestión que as garda para a sesión. OpenVPN conserva esa copia para poder responder á seguinte renegociación sen volver preguntar, e diso trata exactamente o aviso. Non hai nada no disco, así que o único que hai que protexer é o proceso que garda o valor. Pecha o cliente e a copia desaparece con el.

O segundo modelo é auth-user-pass apuntando a un ficheiro, onde o ficheiro é o almacén e o cliente léoo cando necesita un valor. A exposición que importa aquí non é a memoria do proceso senón os permisos e a propiedade dese ficheiro. O aviso de arrinque vén das directivas da configuración, non dunha inspección de como forneces o contrasinal, así que aparece en ambos os modelos e non apunta a ningún.

O resto desta comparación deriva desa división: xestión da memoria para un modelo, xestión do ficheiro e identidade do proceso para o outro.

Que descarta realmente auth-nocache

Cun inicio de sesión interactivo, --auth-nocache elimina a copia gardada da memoria despois de usala. O custo é unha petición nova en cada intervalo de renegociación, porque a seguinte rolda non pode reutilizar o que se descartou.

Cun inicio de sesión baseado en ficheiro o cliente pode volver ler o ficheiro, así que o descarte é case invisible. Faise visible no único lugar onde a xente non o espera: despois de que o daemon abandone privilexios, se o ficheiro de credenciais non é lexible pola conta coa que agora se executa.

Engade a opción porque entendes ese intercambio, non porque apareceu un aviso. Unha opción engadida para deixar un rexistro máis silencioso é unha opción cuxo efecto ninguén mediu.

Onde se rompe a ruta baseada en ficheiro

Un cliente que arrinca como root para abrir o dispositivo de túnel e logo cambia a user e group le o ficheiro de credenciais dúas veces: unha antes do cambio, outra na renegociación que segue. Se o ficheiro ten modo 600 e é propiedade de root, a segunda lectura falla, e o fallo aparece unha hora despois como un erro de autenticación que parece un problema do servidor. Revisa o rexistro do cliente arredor do intervalo de renegociación e despois revisa a conta e o ficheiro xuntos.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

As dúas liñas importan. A primeira di quen pode ler o ficheiro, a segunda di quen é realmente o daemon en execución, e unha discrepancia entre elas explica un fallo que ningunha reescritura do contrasinal arranxará.

As correccións prácticas non son glamurosas: move o ficheiro a un directorio e a un propietario que a conta do daemon poida ler, ou mantén a lectura privilexiada e confirma que o teu cliente só le unha vez. Non o resolvas facendo o ficheiro lexible para todos.

O caso que si quere a opción

Un inicio de sesión cun código dun só uso quere auth-nocache por unha razón distinta. Un código dun só uso gástase coa primeira autenticación, así que unha copia na caché é inútil na seguinte renegociación e un valor caducado incluso podería reproducirse.

Iso é unha cuestión sobre o tipo de credencial, non sobre onde se almacena. Un contrasinal estático nun ficheiro protexido ten o perfil oposto: debe ser lexible en cada renegociación, e a protección que necesitas está no ficheiro.

Mantén esas dúas razóns separadas nos comentarios do perfil, porque se non o seguinte administrador asumirá que a opción está aí pola razón que el tería elixido.

A comparación nunha decisión

Elixe o modelo interactivo cando hai unha persoa presente e a frescura importa, e acepta a petición repetida como o seu custo. Elixe o modelo de ficheiro cando o cliente funciona sen supervisión, e dedica o esforzo á propiedade, o modo e o abandono de privilexios.

Ningún modelo fai segura un contrasinal almacenado por si só, nin ningún fai significativo o aviso de arrinque.

Se o aviso é a única razón pola que abriches o perfil, anota a decisión en lugar dunha opción sen explicación: as credenciais veñen dun ficheiro lexible pola conta do daemon, viuse unha renegociación ter éxito, e o apartado sobre renegociación do manual de OpenVPN 2.6 leuse antes de cambiar o seu intervalo. Esa nota sobrevive a calquera bandeira por separado.