El servei OpenVPN s’atura en demanar la contrasenya de la clau privada: com arreglar-ho

OpenVPN demana la contrasenya de la clau privada a la màquina local, així que un fitxer d’inici de sessió que funciona mai no la respon. En un servei no hi ha terminal on escriure i l’arrencada o bé es penja o bé falla amb una entrada de registre que anomena l’entrada, no la causa. Hi ha dos secrets i cadascun necessita la seva pròpia font llegible abans de reiniciar la unitat. El recorregut de sota els separa i després comprova la identitat que obre realment cada fitxer.

Distingiu les dues preguntes

La contrasenya de la clau desxifra la clau privada local; les credencials del compte autentiquen la sessió amb el servidor. Vénen de llocs diferents, fallen en moments diferents i donen missatges diferents. Confondre-les fa que la gent busqui un restabliment de contrasenya quan el compte no hi tenia res a veure. Llegiu el text de la petició abans de canviar qualsevol opció, perquè la redacció és l’única pista fiable de quin secret falta.

A Community OpenVPN 2.x, askpass indica un fitxer que porta la contrasenya de la clau a la primera línia, i auth-user-pass indica un fitxer amb el nom d’usuari en una línia i la contrasenya a la següent. Cap dels dos fitxers no pot satisfer l’altra opció. Una aplicació d’escriptori o un perfil de NetworkManager poden guardar tots dos al seu propi magatzem de secrets, que un client de línia d’ordres no llegeix mai, així que anoteu quin client configureu abans d’escriure qualsevol camí.

Apunteu les dues opcions a fitxers llegibles

Un perfil que necessita les dues entrades acaba amb tres referències de fitxer: la clau xifrada, la contrasenya que la desbloqueja i la parella d’inici de sessió. Afegiu-les sense tocar la CA ni les comprovacions d’identitat, perquè aquestes decideixen qui és el servidor i no formen part d’aquest problema. Si el desplegament no fa servir cap credencial de compte, afegir auth-user-pass crea una entrada que ningú no pot proporcionar.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Les opcions sense argument es comporten diferent de les opcions amb camí, i la diferència importa en un servei. Una askpass sense argument encara llegeix la consola, i un fitxer auth-user-pass amb només un nom d’usuari encara deixa una petició de contrasenya esperant. Un cop el client passa a dimoni no pot demanar cap entrada al terminal, així que un servei configurat així no arrenca.

Els camins absoluts eliminen la qüestió del directori de treball, però no atorguen accés. La propietat, el mode i el recorregut vénen després, i tots tres es comproven contra el compte amb què s’executa el procés.

Llegiu la configuració de la unitat abans que el perfil

La unitat, no el fitxer que editaveu, decideix quina configuració carrega la instància. Llegiu la seva línia d’ordres i qualsevol drop-in, i després seguiu el directori de treball fins al perfil que realment s’usa. Una referència de contrasenya afegida a un altre fitxer .ovpn no canvia res per a aquesta instància.

Tres ordres de només lectura responen a la major part. La primera imprimeix la unitat i qualsevol drop-in, la segona imprimeix la identitat i els paràmetres de sandbox que limiten el procés, i la tercera imprimeix de què es va queixar realment l’última arrencada. Feu servir el nom d’instància que existeix a l’amfitrió:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Fixeu-vos en ProtectHome i en les opcions pròpies del perfil user, group i chroot. Un fitxer sota un directori personal pot ser llegible al vostre shell i invisible dins del servei quan els directoris personals s’amaguen. El compte amb què arrenca systemd no sempre és el compte que acaba obrint la clau.

Demostreu que la identitat d’execució pot obrir tots dos fitxers

Llegir el mode no n’hi ha prou, perquè cada directori del camí ha de ser travessable per la mateixa identitat. Recorreu el camí component a component i després proveu l’obertura com el compte que fa servir el procés. Un fitxer amb mode 600 propietat de root només funciona mentre el procés encara és root, cosa que no és certa després de la baixada de privilegis que fan molts perfils. Dues ordres cobreixen el recorregut i l’obertura:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

La primera ordre imprimeix el mode de cada component i falla on el compte no pot travessar; la segona respon l’única pregunta que importa: si la identitat d’execució pot obrir el fitxer per llegir-lo. Cap de les dues no imprimeix el contingut del fitxer, i això és el punt quan el fitxer porta una contrasenya. Repetiu la prova per al fitxer d’inici de sessió, perquè sovint es guarden amb propietats diferents.

Si el procés fa servir un chroot o un namespace restringit, executeu la mateixa prova des de dins d’aquesta vista, o la resposta descriu el sistema de fitxers equivocat. Una contrasenya guardada sota un directori personal amagat és l’exemple habitual de prova que passa fora de la unitat i falla dins.

Comproveu la primera arrencada i després una reconnexió

Arrenqueu la instància un cop i llegiu la primera fallada, no l’última. Un fitxer d’entrada que falta, un desxifrat de clau fallit i un AUTH_FAILED del servidor són tres esdeveniments diferents amb tres reparacions diferents. Arreglar un avís de permisos no demostra res sobre si la clau es va desbloquejar.

La línia del registre us diu quin dels tres teniu. La reparació es dedueix de quina entrada va fallar:

Després proveu el cicle de vida que realment necessiteu: una arrencada en el boot i qualsevol reconnexió admesa, no només una arrencada manual des del vostre shell. Amb auth-nocache les entrades es descarten després del primer ús, així que una reconnexió posterior encara necessita una font llegible. Un clauer desbloquejat a l’inici de sessió de l’escriptori no està disponible per a un servei que va arrencar abans que ningú iniciés sessió, i aquesta és la raó habitual per la qual una prova manual passa i un reinici falla. Si la primera arrencada té èxit i una reconnexió posterior falla, llegiu el registre per a l’esdeveniment de reconnexió abans de tornar a canviar permisos.

Guardar la contrasenya al costat de la clau redueix el que us aporta el xifratge, així que restrinngiu aquest fitxer i les seves còpies. Tracteu treure la contrasenya de la clau com una decisió de credencials a part, no com la reparació d’una entrada que falta. Un desplegament que depèn d’aprovació humana o MFA interactiva necessita el seu agent o integració de gestió compatible; un codi d’un sol ús guardat permanentment no és un substitut equivalent.