OpenVPN auth-user-pass: датотека, stdin или прашање? Како да изберете

Три работи одлучуваат кој извор на акредитиви да го користите: дали некое лице седи пред конзолата, дали тајната смее да живее на дискот и дали друг процес треба да одговори на прашањето. Ако изберете погрешно, клиентот пријавува проблем со stdin додека лозинката е сосема валидна, што ги испраќа повеќето кај серверот без причина. Прво изберете го патот; пораките за грешка имаат смисла само кога знаете кој пат ги создал.

Трите услови што одлучуваат

Прашањето во конзолата е единствениот пат што бара човек, па затоа е единствениот што тивко неуспева во systemd единица или контејнер. Ако лице го стартува клиентот и ја внесе лозинката, не е вклучена датотека и ништо чувствително не завршува на дискот. Ако клиентот се стартува при подигање, истото прашање станува заглавување, а истекот на време обично се појавува како општа грешка во врската, а не како грешка со акредитивите.

Датотеката со акредитиви е точниот одговор кога процесот се стартува без надзор и тајната смее да остане на дискот под контролиран сет дозволи. Кога тајната не смее воопшто да се запише - политика само на трезор, краткотраен токен - потребен ви е тек што клиентот може да го отвори, што во пракса значи замена на процес или помошник што пишува во датотечен дескриптор. Интерфејсот за управување го покрива четвртиот случај: контролер што веќе го управува животниот циклус на тунелот и може да одговара на прашања преку сокет.

• Човек пред конзолата, без автоматизација: интерактивно прашање.
• Стартување без надзор, тајната смее да се чува: датотека со акредитиви со режим 0600.
• Стартување без надзор, тајната не смее да се чува: замена на процес или fd во кој пишува агент за тајни.
• Друг процес го поседува клиентот: интерфејс за управување.

Кога одговараат два одговора, изберете го оној што ја држи тајната надвор од argv и надвор од историјата на shell. Лозинката предадена како аргумент на програма е читлива за секој локален корисник преку списокот на процеси, а тоа изложување тешко се поништува.

Што всушност прави секој влезен пат

--auth-user-pass сам по себе бара корисничко име и лозинка во конзолата. Кога ќе добие име на датотека, клиентот го зема првиот ред како корисничко име, а вториот како лозинка; ништо не поддржува наводници, коментари или синтакса клуч-вредност. Тоа е целиот формат, па секој што го уредува очекувајќи INI датотека го расипува. Вградениот блок <auth-user-pass> ги држи истите два реда во профилот, што самиот профил го прави тајна и го става во истата класа на ракување како приватен клуч.

Другите два пата се тек и сокет. На OpenVPN му треба само читлив датотечен дескриптор, па затоа ќе прифати замена на процес, запис /dev/fd поддржан со цевка или име на датотека што всушност е FIFO. Интерфејсот за управување е различен по природа: клиентот ги прашува вредностите од надзорен процес наместо сам да ги чита. Таа разлика е важна при повторно поврзување: датотеката со акредитиви, FIFO во кој помошникот за тајни може повторно да пишува и интерфејсот за управување можат повторно да снабдат без човек; замената на процес не може, затоа што дескрипторот се троши при првото читање.

Датотеката мора да има точно два реда

Два режима на откажување покриваат повеќето расипани датотеки со акредитиви. Уредувач на Windows остава CRLF завршетоци, враќањето на вагонот станува дел од лозинката, и серверот одбива вредност што на екранот изгледа исправна. Празен втор ред - празен ред таму каде што треба да биде лозинката - го остава клиентот со празна лозинка, која серверот ја одбива иако вредноста на екранот изгледа исправна. Дополнителен нов ред по лозинката е безопасен. Пишувајте ја датотеката од shell, не од уредувач, и проверете ги бајтите:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Патот е исто толку важен како содржината. Релативниот пат се решава во однос на работниот директориум на процесот, што за услуга ретко е директориумот во кој тестиравте. Користете апсолутен пат, направете датотеката да биде сопственост на сметката што го стартува клиентот и држете режим 0600 за да не можат групата и другите да ја читаат. Прирачникот за OpenVPN 2.6 ги наведува прифатените форми на директивата; проверете го пред да измислите трета.

Тестирајте ја датотеката пред да го обвините серверот. Извршувањето на openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 испечатува дали датотеката е отворена и подоцна дали акредитивите се прифатени, што ви кажува кој слој да го смените следно.

Тецишта, stdin и грешките што ги произведуваат

Пуштањето на лозинката во цевка е првото што повеќето луѓе го пробуваат и патот со најмногу изненадувања. Замената на процес работи затоа што на клиентот му треба само читлив дескриптор: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Предавањето /dev/stdin работи само кога stdin е сѐ уште отворен и читлив во моментот кога клиентот прашува, што не е точно во цевковод што веќе го потрошил.

ERROR: could not read Auth username from stdin има два различни причини. Кај некои 2.3.x клиенти пораката доаѓаше од дефект во ракувањето со stdin што го поправија подоцнежните 2.3 изданија, па толку стар клиент се подобрува само со надградба. Кај современ клиент истиот текст значи дека клиентот побарал конзолен влез и stdin не бил терминал - точно ситуацијата во systemd единица, задача на cron или контејнер стартуван без -t.

auth-nocache додава трет циклус што изгледа како расипана лозинка. Ги отфрла акредитивите од меморијата по употреба, па повторното поврзување предизвикано од промена на мрежата нема што да репродуцира и прашањето се враќа. Тоа е директивата што работи како што е проектирана. auth-nocache менува што клиентот чува во меморијата, а не што мисли серверот или давателот на идентитет за сметката, па целата поправка е повторно снабдување на истата датотека, повторно прочитана при рестарт - а за управувана врска тоа снабдување треба да дојде од одобреното складиште за тајни, не од лозинка во скрипта.

Интерфејсот за управување кога прашањето го поседува друг процес

Контролерот што веќе го надгледува тунелот може да одговара и на неговите прашања. Стартувајте го клиентот со --management 127.0.0.1 7505, читајте ги редовите за состојба и внимавајте на >PASSWORD:Need 'Auth' username/password. Контролерот одговара со username "Auth" alice по што следи password "Auth" ... на одделни командни редови. Токенот 'Auth' го повторува идентификаторот од барањето и мора да се совпадне, инаку одговорот се игнорира и клиентот чека.

Цената е машина за состојби што сега ја поседувате: редослед на врски, рестартирања на клиентот и локален сокет до кој другите корисници на домаќинот не смеат да стигнат. Она што го купувате се акредитиви доставени во време на извршување, без датотека на дискот и без прашање што може да се заглави. Ако ништо друго во вашиот стек веќе не го зборува протоколот, овој пат додава компонента што треба да се одржува.

Откажувања што изгледаат како проблеми со акредитиви

TLS ракување што никогаш не завршува, или VERIFY ERROR: depth=0, error=certificate signature failure, е проблем со довербата и се случува пред да се прочита било кое корисничко име. Клиент proto tcp насочен кон UDP слушател откажува на истото место: пакетите никогаш не стигнуваат до фазата на автентикација, па секоја лозинка изгледа погрешна по асоцијација. Држете ја проверката на сертификатот вклучена пред акредитивите да бидат испратени; познато прашање не кажува ништо за тоа кој ја прима лозинката. Проверете го синџирот на сертификати, заедничкото име и транспортот пред да ги допрете акредитивите.

Грешките во shell во скриптата што го составува профилот се другата лажна трага. Недостасувачки простор внатре во [ ! -f "$file" ] произведува command not found, скриптата запира рано, профилот никогаш не се преизградува и клиентот се стартува со претходниот. Таа грешка и припаѓа на shell, не на автентикацијата, и никакво препишување на лозинката нема да ја избрише.

Не секое прашање во овој тек се овие акредитиви. Лозинката за приватен клуч, најавата преку HTTP прокси и лозинката на услугата се три различни тајни што се бараат во различни фази, а лозинката за клуч обично ја обработува клиентот или агент, а не auth-user-pass. Ако прашањето се појави пред TLS сесијата да биде воспоставена, одговарате на погрешното прашање и никакво ресетирање на сметката нема да помогне. Откако погрешното прашање е исклучено, останатите проверки започнуваат од најраниот слој:

• Читајте ја првата грешка на протоколот, не последниот ред со акредитиви: TLS, потоа автентикација, потоа push.
• Потврдете дека датотеката е два реда, нема враќања на вагонот и е наведена со апсолутен пат.
• Потврдете дека профилот и командната линија не се разидуваат за директивата.
• Одделете "акредитивите се прифатени" од "сообраќајот тече" - рутирањето и DNS се подоцнежен слој.

Кога клиентот ќе стигне до фазата push, престанете да гледате во акредитивите и почнете да ги читате рутите и DNS серверите што ги испратил серверот. Тоа е следниот проблем и нема никаква врска со лозинката што штотуку ја поправивте.