Oplossing: OpenVPN kon de Auth-gebruikersnaam niet van standaardinvoer lezen

could not read Auth username from stdin lijkt een authenticatieprobleem en is het niet. OpenVPN probeerde de gebruikersnaam via standaardinvoer op te vragen, vond niets leesbaars en stopte voordat het ooit de server had benaderd. Het account kan volkomen geldig zijn; het proces heeft simpelweg niemand om het aan te vragen.

Daarom is de eerste nuttige stap vaststellen wat de client leest, niet de verbinding opnieuw proberen of instellingen aan de serverkant wijzigen. Loop de onderstaande controles in volgorde door en stop bij de eerste die mislukt.

Lees de fout als een lokale invoerfout

Wanneer auth-user-pass zonder bestandsargument verschijnt, verwacht de client te vragen. In een interactieve shell werkt die prompt omdat het proces een terminal bezit. Onder systemd, een cron-taak of een container is standaardinvoer meestal leeg, en de lezing keert onmiddellijk terug met de fout die u ziet.

Het bericht noemt ook het veld dat mislukte, gebruikersnaam of wachtwoord, wat aangeeft hoe ver de lezing kwam. Een ontbrekende gebruikersnaam betekent dat het proces helemaal niets kon lezen. Een ontbrekend wachtwoord na een geslaagde gebruikersnaam betekent dat de invoerstroom tussen de twee lezingen eindigde, wat typerend is voor een halfgeschreven bestand of een gesloten pijp.

Bevestig de eigen kijk van de client voordat u iets anders wijzigt. Voer hem op de voorgrond uit met dezelfde configuratie en dezelfde gebruiker, en kijk of de prompt verschijnt. Verschijnt die in uw shell maar niet onder de servicemanager, dan is het verschil de invoerbron, niet de inloggegevens. Een snelle vergelijking van het unit-bestand en uw shellomgeving laat meestal zien welke van de twee een terminal levert.

Geef de dienst een ondersteunde bron voor inloggegevens

De ondersteunde bron voor onbeheerd draaien is een inloggegevensbestand dat als argument aan auth-user-pass wordt doorgegeven. Het bestand wordt als platte tekst gelezen: de eerste regel is de gebruikersnaam, de tweede het wachtwoord. Wijs er met een absoluut pad naar, bijvoorbeeld /etc/openvpn/client/creds , zodat de werkmap van het dienstaccount de betekenis van de richtlijn niet kan veranderen.

Rechten zijn even belangrijk als het pad. Het bestand moet leesbaar zijn voor het account dat de client uitvoert en niet voor iedereen, en het zou eigendom moeten zijn van het dienstaccount of van root met een groep die de dienst omvat. Controleer de leesbaarheid als dat account, zonder de inhoud af te drukken.

Een relatief pad is de stille faalmodus. Het profiel kan in de ene map staan terwijl systemd het proces elders start, dus een bestand dat in uw shell wordt gevonden, wordt voor de dienst niet gevonden. Verplaats de inloggegevens naar een vaste locatie en verwijs er absoluut naar. Start daarna de dienst één keer en bevestig dat hetzelfde pad wordt gebruikt, in plaats van de weergave van de profieleditor te vertrouwen.

Als de uitrol een eenmalige code of een andere interactieve uitdaging vereist, beslis dan of de werkstroom van de client dat echt onbeheerd ondersteunt. Een bestand met een statisch wachtwoord kan geen roterende code beantwoorden, en een onbeantwoordbare prompt opnieuw proberen voegt geen informatie toe.

Waarom script-security niet helpt

script-security bepaalt of de client scripts mag uitvoeren en hoeveel hij eraan mag doorgeven, inclusief of een wachtwoord via een omgevingsvariabele aan een script kan worden gegeven. Het zegt niets over waar de gebruikersnaam en het wachtwoord oorspronkelijk vandaan komen.

Het naar een hoger niveau tillen is een veelvoorkomende reflex omdat het bericht Auth noemt, maar het wijzigt scriptrechten in plaats van de invoerbron, en het verruimt wat de client mag uitvoeren. Als een hulpscript deel van het ontwerp is, repareer dan eerst de invoerbron en houd het beveiligingsniveau op de laagste waarde die de uitrol nodig heeft.

De beheerinterface is een legitiem alternatief. Een frontend kan ermee verbinden, het verzoek om inloggegevens ontvangen en antwoorden met de gebruikersnaam en het wachtwoord, zo werken sommige GUI's. Gebruikt u hem, bind hem dan aan een lokaal adres, bescherm hem met een beheerwachtwoordbestand en beperk wie kan verbinden, want het is een besturingskanaal voor de client.

Controleer de volgende fase nadat de client het bestand heeft gelezen

Zodra de client de inloggegevens kan lezen, is de volgende fout een echte uitwisseling met de server, en de boodschap ervan heeft een andere betekenis. Een authenticatiefout in die fase betekent dat de server het account heeft geweigerd; een uitdagingsantwoord betekent dat de server een andere factor wil. Behandel ze als nieuwe problemen en niet als hetzelfde opnieuw.

Test het hele pad zoals de dienst het zal uitvoeren: hetzelfde account, dezelfde werkmap, dezelfde unit-omgeving. Een verbinding die alleen werkt wanneer hij vanuit uw shell wordt gestart, is een teken dat een omgevingsvariabele of een terminal nog deel van de stroom uitmaakt.

Houd de geheimen daarna waar ze horen. Wachtwoorden in opdrachtregelargumenten verschijnen in de procestabel, en wachtwoorden in foutopsporingsuitvoer belanden in tickets. Gebruik een beschermd bestand of de beheerinterface, houd logboeken op een niveau dat geen inloggegevens herhaalt, en wissel het bestand wanneer iemand met toegang vertrekt.

Controlelijst: absoluut pad naar de inloggegevens, leesbaar als dienstaccount, geen terminal nodig, script-security op het minimum gelaten, beheerinterface alleen als die is gebonden en geauthenticeerd, en de resulterende serverreactie als een aparte gebeurtenis behandeld.