O servizo de OpenVPN detense ao pedir o contrasinal da clave privada: como arranxalo
Un servizo non ten terminal, así que unha clave cifrada necesita askpass e un ficheiro lexible. Separe o contrasinal da clave do inicio de sesión no servidor e revise a unidade.
OpenVPN pide o contrasinal da clave privada na máquina local, así que un ficheiro de inicio de sesión que funciona nunca o responde. Nun servizo non hai terminal onde escribir, e o arranque ou se colga ou falla cunha entrada do rexistro que nomea a entrada e non a causa. Hai dous segredos e cada un necesita a súa propia fonte lexible antes de reiniciar a unidade. O percorrido de abaixo sepáraos e despois comproba a identidade que realmente abre cada ficheiro.
Distinga as dúas peticións
O contrasinal da clave descifra a clave privada local; as credenciais da conta autentican a sesión co servidor. Veñen de lugares distintos, fallan en momentos distintos e dan mensaxes distintas. Confundilas leva a buscar un restablecemento de contrasinal cando a conta non tiña nada que ver. Lea o texto da petición antes de cambiar calquera opción, porque a redacción é a única pista fiable de que segredo falta.
En Community OpenVPN 2.x, askpass nomea un ficheiro que garda o contrasinal da clave na súa primeira liña, e auth-user-pass nomea un ficheiro co nome de usuario nunha liña e o contrasinal na seguinte. Ningún dos dous ficheiros satisfai a outra opción. Unha aplicación de escritorio ou un perfil de NetworkManager poden gardar ambos no seu propio almacén de segredos, que un cliente de liña de ordes nunca le, así que anote que cliente está configurando antes de escribir calquera ruta.
Apunte ambas opcións a ficheiros lexibles
Un perfil que necesita as dúas entradas acaba con tres referencias de ficheiro: a clave cifrada, o contrasinal que a desbloquea e o par de inicio de sesión. Engádaas sen tocar a CA nin as comprobacións de identidade, porque estas deciden quen é o servidor e non forman parte deste problema. Se o despregamento non usa credenciais de conta en absoluto, engadir auth-user-pass crea unha entrada que ninguén pode proporcionar.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authAs opcións sen argumento compórtanse distinto das opcións con ruta, e a diferenza importa nun servizo. Unha askpass sen argumento segue lendo a consola, e un ficheiro auth-user-pass con só un nome de usuario segue deixando unha petición de contrasinal esperando. En canto o cliente pasa a demonio non pode pedir entrada ao terminal, así que un servizo configurado así non arranca.
As rutas absolutas eliminan a cuestión do directorio de traballo, pero non conceden acceso. A propiedade, o modo e o percorrido veñen despois, e os tres compróbanse contra a conta coa que se executa o proceso.
Lea a configuración da unidade antes que o perfil
A unidade, non o ficheiro que estaba editando, decide que configuración carga a instancia. Lea a súa liña de ordes e calquera drop-in, e despois siga o directorio de traballo ata o perfil que realmente se usa. Unha referencia de contrasinal engadida a outro ficheiro .ovpn non cambia nada para esta instancia.
Tres ordes de só lectura responden á maior parte. A primeira imprime a unidade e calquera drop-in, a segunda imprime a identidade e os axustes de sandbox que limitan o proceso, e a terceira imprime de que se queixou realmente o último arranque. Use o nome de instancia que exista no host:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bFíxese en ProtectHome e nas opcións propias do perfil user, group e chroot. Un ficheiro baixo un directorio persoal pode ser lexible no seu shell e invisible dentro do servizo cando se ocultan os directorios persoais. A conta coa que arranca systemd non sempre é a conta que acaba abrindo a clave.
Demostre que a identidade de execución pode abrir ambos ficheiros
Ler o modo non abonda, porque cada directorio da ruta debe ser atravesable pola mesma identidade. Percorra a ruta compoñente a compoñente e despois probe a apertura como a conta que usa o proceso. Un ficheiro con modo 600 propiedade de root só funciona mentres o proceso segue sendo root, o que non é certo tras a baixada de privilexios que fan moitos perfís. Dúas ordes cobren o percorrido e a apertura:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableA primeira orde imprime o modo de cada compoñente e falla onde a conta non pode atravesar; a segunda responde á única pregunta importante: se a identidade de execución pode abrir o ficheiro para lectura. Ningunha imprime o contido do ficheiro, que é xusto o que se busca cando o ficheiro garda un contrasinal. Repita a proba para o ficheiro de inicio de sesión, porque os dous adoitan gardarse con propietarios distintos.
Se o proceso usa un chroot ou un namespace restrinxido, execute a mesma proba desde dentro desa vista, ou a resposta describe o sistema de ficheiros equivocado. Un contrasinal gardado baixo un directorio persoal oculto é o exemplo habitual de proba que pasa fóra da unidade e falla dentro.
Comprobe o primeiro arranque e despois unha reconexión
Arranque a instancia unha vez e lea o primeiro fallo, non o último. Un ficheiro de entrada ausente, un descifrado de clave fallido e un AUTH_FAILED do servidor son tres sucesos distintos con tres reparacións distintas. Arranxar un aviso de permisos non demostra nada sobre se a clave se desbloqueou.
A liña do rexistro di cal dos tres ten. A reparación dedúcese de que entrada fallou:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Despois probe o ciclo de vida que realmente necesita: un arranque no boot e calquera reconexión admitida, non só un arranque manual desde o seu shell. Con auth-nocache as entradas descártanse tras o primeiro uso, así que unha reconexión posterior segue necesitando unha fonte lexible. Un chaveiro desbloqueado ao iniciar sesión no escritorio non está dispoñible para un servizo que arrancou antes de que ninguén iniciase sesión, e esa é a razón habitual pola que unha proba manual pasa e un reinicio falla. Se o primeiro arranque ten éxito e unha reconexión posterior falla, lea o rexistro do evento de reconexión antes de volver cambiar permisos.
Gardar o contrasinal xunto á clave reduce o que aporta o cifrado, así que restrinxa ese ficheiro e as súas copias. Trate quitar o contrasinal da clave como unha decisión de credenciais aparte, non como a reparación dunha entrada ausente. Un despregamento que depende de aprobación humana ou MFA interactiva necesita o seu axente ou integración de xestión compatible; un código dun só uso gardado de forma permanente non é un substituto equivalente.