Correcció: OpenVPN no va poder llegir el nom d'usuari d'Auth de l'entrada estàndard

could not read Auth username from stdin sembla un problema d'autenticació i no ho és. OpenVPN va intentar demanar el nom d'usuari per l'entrada estàndard, no va trobar res llegible i es va aturar abans d'arribar a contactar amb el servidor. El compte pot ser perfectament vàlid; simplement el procés no té ningú a qui preguntar.

Per això el primer pas útil és confirmar què llegeix el client, no tornar a provar la connexió ni canviar paràmetres del costat del servidor. Seguiu les comprovacions següents en ordre i atureu-vos a la primera que falli.

Llegiu l'error com una fallada local d'entrada

Quan auth-user-pass apareix sense un argument de fitxer, el client espera demanar-lo. En un shell interactiu aquesta petició funciona perquè el procés té un terminal. Sota systemd, una tasca cron o un contenidor, l'entrada estàndard sol estar buida i la lectura retorna immediatament amb l'error que veieu.

El missatge també indica quin camp ha fallat, el nom d'usuari o la contrasenya, cosa que diu fins on ha arribat la lectura. Que falti el nom d'usuari vol dir que el procés no ha pogut llegir res. Que falti la contrasenya després d'un nom d'usuari correcte vol dir que el flux d'entrada s'ha acabat entre les dues lectures, cosa típica d'un fitxer escrit a mitges o d'una canonada que s'ha tancat.

Confirmeu la visió del mateix client abans de canviar res més. Executeu-lo en primer pla amb la mateixa configuració i el mateix usuari, i mireu si apareix la petició. Si apareix al vostre shell però no sota el gestor de serveis, la diferència és la font d'entrada, no les credencials. Una comparació ràpida del fitxer d'unitat i de l'entorn del shell sol mostrar quin dels dos proporciona un terminal.

Doneu al servei una font de credencials admesa

La font admesa per a l'execució sense supervisió és un fitxer de credencials passat com a argument a auth-user-pass. El fitxer es llegeix com a text pla: la primera línia és el nom d'usuari, la segona és la contrasenya. Apunteu-hi amb un camí absolut com ara /etc/openvpn/client/creds perquè el directori de treball del compte de servei no pugui canviar el significat de la directiva.

Els permisos importen tant com el camí. El fitxer ha de ser llegible pel compte que executa el client i no per tothom, i hauria de pertànyer al compte de servei o a root amb un grup que inclogui el servei. Comproveu-ne la llegibilitat com a aquest compte, sense imprimir-ne el contingut.

Un camí relatiu és el mode de fallada silenciós. El perfil pot ser en un directori mentre systemd inicia el procés en un altre, de manera que un fitxer que es resol al vostre shell no es resol per al servei. Moveu les credencials a una ubicació fixa i referiu-vos-hi de manera absoluta. Després inicieu el servei un cop i confirmeu que s'utilitza el mateix camí, en lloc de confiar en la visió de l'editor de perfils.

Si el desplegament requereix un codi d'un sol ús o un altre repte interactiu, decidiu si el flux de treball del client realment el pot gestionar sense supervisió. Un fitxer amb una contrasenya estàtica no pot respondre a un codi que canvia, i reintentar una petició sense resposta no aporta cap informació.

Per què script-security no ajudarà

script-security controla si el client pot executar scripts i quant els pot passar, inclòs si es pot lliurar una contrasenya a un script mitjançant una variable d'entorn. No diu res sobre d'on vénen el nom d'usuari i la contrasenya.

Apujar-lo a un nivell superior és un reflex habitual perquè el missatge esmenta Auth, però canvia els permisos dels scripts, no la font d'entrada, i amplia què pot executar el client. Si un script auxiliar forma part del disseny, arregleu primer la font d'entrada i manteniu el nivell de seguretat al valor més baix que necessiti el desplegament.

La interfície de gestió és una alternativa legítima. Un frontal hi pot connectar, rebre la petició de credencials i respondre amb el nom d'usuari i la contrasenya, que és com funcionen alguns GUI. Si la feu servir, lligueu-la a una adreça local, protegiu-la amb un fitxer de contrasenya de gestió i limiteu qui s'hi pot connectar, perquè és un canal de control del client.

Verifiqueu la fase següent després que el client llegeixi el fitxer

Un cop el client pot llegir les credencials, la fallada següent és un intercanvi real amb el servidor i el seu missatge té un significat diferent. Una fallada d'autenticació en aquesta fase vol dir que el servidor ha rebutjat el compte; una resposta de repte vol dir que el servidor vol un altre factor. Tracteu-los com a problemes nous i no com el mateix repetit.

Proveu tot el camí tal com el servei l'executarà: mateix compte, mateix directori de treball, mateix entorn d'unitat. Una connexió que només funciona quan s'inicia des del vostre shell és senyal que una variable d'entorn o un terminal encara forma part del flux.

Després guardeu els secrets on toca. Les contrasenyes als arguments de línia d'ordres apareixen a la taula de processos, i les contrasenyes a la sortida de depuració acaben als tiquets. Feu servir un fitxer protegit o la interfície de gestió, manteniu els registres a un nivell que no repeteixi credencials i canvieu el fitxer quan marxi qualsevol persona amb accés.

Llista de comprovació: camí absolut de credencials, llegible com a compte de servei, cap terminal necessari, script-security al mínim, interfície de gestió només si està lligada i autenticada, i la resposta del servidor resultant tractada com un esdeveniment separat.