Выпраўленне: OpenVPN не можа прачытаць імя карыстальніка Auth са стандартнага ўводу

could not read Auth username from stdin выглядае як праблема аўтэнтыфікацыі, але ёй не з'яўляецца. OpenVPN паспрабаваў запытаць імя карыстальніка са стандартнага ўводу, не знайшоў нічога чытэльнага і спыніўся, так і не звязаўшыся з серверам. Уліковы запіс можа быць цалкам сапраўдным; проста працэсу няма ў каго пытаць.

Таму перш за ўсё варта пацвердзіць, што менавіта чытае кліент, а не паўтараць злучэнне або мяняць налады на баку сервера. Прайдзіце праверкі ніжэй па парадку і спыніцеся на першай няўдалай.

Чытайце памылку як лакальны збой уводу

Калі auth-user-pass з'яўляецца без аргумента-файла, кліент чакае запыту. У інтэрактыўнай абалонцы гэты запыт працуе, бо працэс валодае тэрміналам. Пад systemd, заданнем cron або кантэйнерам стандартны ўвод звычайна пусты, і чытанне адразу вяртае памылку, якую вы бачыце.

Паведамленне таксама называе поле, якое не ўдалося, — імя карыстальніка або пароль, — і гэта паказвае, як далёка зайшло чытанне. Адсутнасць імя карыстальніка азначае, што працэс не прачытаў нічога наогул. Адсутнасць пароля пасля паспяховага імя карыстальніка азначае, што паток уводу скончыўся паміж двума чытаннямі, што тыпова для недапісанага файла або зачыненага канала.

Пацвердзіце ўласны погляд кліента, перш чым мяняць што-небудзь яшчэ. Запусціце яго ў пярэднім плане з той жа канфігурацыяй і тым жа карыстальнікам і паназірайце, ці з'явіцца запыт. Калі ў вашай абалонцы ён ёсць, а пад кіраўніком службы няма, розніца ў крыніцы ўводу, а не ва ўліковых даных. Хуткае параўнанне unit-файла і асяроддзя абалонкі звычайна паказвае, які з іх дае тэрмінал.

Дайце службе падтрыманую крыніцу ўліковых даных

Падтрыманая крыніца без удзелу чалавека — гэта файл уліковых даных, перададзены як аргумент да auth-user-pass. Файл чытаецца як звычайны тэкст: першы радок — імя карыстальніка, другі — пароль. Пакажыце на яго абсалютным шляхам, напрыклад /etc/openvpn/client/creds , каб працоўны каталог службовага запісу не мог змяніць сэнс дырэктывы.

Дазволы не менш важныя за шлях. Файл павінен быць чытэльным для запісу, які запускае кліент, і не для ўсіх астатніх, а таксама належаць службоваму запісу або root з групай, якая ўключае службу. Праверце чытэльнасць ад імя гэтага запісу, не выводзячы змесціва.

Адносны шлях — гэта ціхі рэжым збою. Профіль можа ляжаць у адным каталогу, а systemd запускае працэс у іншым, таму файл, які бачны з вашай абалонкі, не бачны службе. Перанясіце ўліковыя даныя ў фіксаванае месца і спасылайцеся на іх абсалютна. Затым адзін раз запусціце службу і пацвердзіце, што выкарыстоўваецца той жа шлях, а не давярайце выгляду рэдактара профілю.

Калі разгортванне патрабуе аднаразовага кода або іншага інтэрактыўнага выкліку, вырашыце, ці сапраўды працэс кліента падтрымлівае яго без удзелу чалавека. Файл са статычным паролем не можа адказаць на зменлівы код, і паўтор запыту, на які няма адказу, не дадае ніякай інфармацыі.

Чаму script-security не дапаможа

script-security кіруе тым, ці можа кліент запускаць сцэнарыі і колькі ён можа ім перадаць, уключаючы тое, ці можна перадаць пароль сцэнарыю праз зменную асяроддзя. Ён нічога не кажа пра тое, адкуль бяруцца імя карыстальніка і пароль.

Падвышэнне ўзроўню — звычайная рэакцыя, бо паведамленне згадвае Auth, але яно мяняе дазволы сцэнарыяў, а не крыніцу ўводу, і пашырае тое, што кліент можа выконваць. Калі дапаможны сцэнарый — частка задумы, спачатку выправіце крыніцу ўводу і трымайце ўзровень бяспекі на найніжэйшым значэнні, якое патрэбна разгортванню.

Інтэрфейс кіравання — законная альтэрнатыва. Франтэнд можа падключыцца да яго, атрымаць запыт уліковых даных і адказаць імем карыстальніка і паролем; так працуюць некаторыя GUI. Калі выкарыстоўваеце яго, прывяжыце да лакальнага адраса, абараніце файлам пароля кіравання і абмяжуйце, хто можа падключацца, бо гэта канал кіравання кліентам.

Праверце наступны этап пасля таго, як кліент прачытае файл

Як толькі кліент зможа прачытаць уліковыя даныя, наступны збой — гэта сапраўдны абмен з серверам, і яго паведамленне мае іншае значэнне. Збой аўтэнтыфікацыі на гэтым этапе азначае, што сервер адхіліў уліковы запіс; адказ-выклік азначае, што сервер хоча іншы фактар. Разглядайце іх як новыя праблемы, а не як паўтор той самай.

Праверце ўвесь шлях так, як яго будзе запускаць служба: той жа запіс, той жа працоўны каталог, тое ж асяроддзе unit. Злучэнне, якое працуе толькі пры запуску з вашай абалонкі, — знак таго, што зменная асяроддзя або тэрмінал усё яшчэ частка працэсу.

Затым трымайце сакрэты там, дзе ім належыць. Паролі ў аргументах каманднага радка трапляюць у табліцу працэсаў, а паролі ў адладкавым вывадзе — у тыкеты. Выкарыстоўвайце абаронены файл або інтэрфейс кіравання, трымайце журналы на ўзроўні, які не паўтарае ўліковыя даныя, і мяняйце файл, калі сыходзіць любы, хто меў доступ.

Кантрольны спіс: абсалютны шлях да ўліковых даных, чытэльны службовым запісам, тэрмінал не патрабуецца, script-security на мінімуме, інтэрфейс кіравання толькі калі ён прывязаны і аўтэнтыфікаваны, а атрыманы адказ сервера разглядаецца як асобная падзея.