Ang Invalid Secrets ay Problema ng Container, Hindi ng Panuntunan sa Password

Kapag nakita ang "invalid secrets", isang konklusyon lang ang madalas mabuo: ayaw ng VPN sa mga bantas. Madalas mali ang konklusyong iyon, dahil ang mensahe ay kadalasang galing sa lokal na paghawak bago pa may gateway na tumingin sa account. Dalawang disenyo ang naghahatid ng parehong password, isang graphical na field at isang credential file, at magkaiba ang lugar kung saan sila nabibigo. Ihambing ang mga container bago gawing simple ang password na tama naman sa lahat ng panahon.

Dumarating ang error bago pa ang gateway

Lokal na validation, naka-lock na secret store, kulang na agent at maling anyo ng credential file, lahat ay gumagawa ng mga pagkabigo na nararanasan ng user bilang isang pagtanggi. Wala sa mga ito ang may authentication server. Ang sariling pagtanggi ng gateway ay hiwalay na pangyayari, at kadalasan may ibang mensahe at ibang timing. Nangyayari ito pagkatapos mabuo ang tunnel at maipadala ang mga credential.

Kaya ang unang tanong ay hindi kung aling mga karakter ang legal, kundi saan huminto ang pagtatangka. Ang client na hindi kailanman nagbukas ng koneksyon ay walang tumanggi. Isulat ang yugtong naobserbahan mo, dahil nakasalalay sa klasipikasyong iyon ang bawat susunod na hakbang.

Binabago rin ng pagkakaibang ito kung sino ang mag-aayos. Ang problema sa container ay pag-aari ng device at ng may-ari nito, habang ang pagtanggi sa account ay pag-aari ng nagpapatakbo ng authentication backend.

Ihambing ang mga container, hindi ang mga karakter

Ang GUI password field, keychain entry, dalawang linyang credential file at automation secret ay nagdadala ng parehong halaga sa magkaibang sobre. May sariling patakaran ang sobre, at iyon ang kadalasang nasisira. Bihirang maging problema ang halaga; ang paghahatid ng halaga ang problema. Paghiwalayin ang dalawang ideya at mas maikli ang diagnosis.

Community OpenVPN 2.6 client options ay naglalarawan ng dalawang linyang file para sa auth-user-pass, kasama ang gawi kapag wala ang password line: magpo-prompt na lang ang client. Ang isang detalyeng iyon ang nagpapaliwanag sa isang uri ng ulat na "bakit hinihingi ang password na ibinigay ko na". Sinasabi rin nito na ang walang laman na ikalawang linya ay makabuluhang estado, hindi walang pinsalang pagpili ng format.

Hiwalay na layer muli ang quoting: ang mga quotation mark sa loob ng plain credential file ay naka-store bilang data, habang tinatanggal ito ng shell bago makakita ng anuman ang programa. Ang parehong karakter ay walang pinsala sa isang lugar at structural sa isa. Hindi masasabi ng table kung aling container ang ginamit ng client mo, kaya basahin ang sariling configuration ng client bago pumili ng row.

Structural din ang mga line break. Ang file na line-delimited ang fields ay hindi makapagdadala ng halagang may newline, at limitasyon iyon ng format, hindi hatol sa lakas ng password. Gamitin ang sinusuportahang mekanismo ng deployment sa halip na putulin ang secret para umkas sa isang gawang file.

Buuin ang credential file nang walang pinsala ng shell

Ang pinakaligtas na lokal na ruta ay naglalayo sa secret mula sa history ng shell at mula sa argument list ng proseso. Basahin ang dalawang field nang interactive, pagkatapos isulat ang dalawang linyang inaasahan ng client. Ang lahat ng iba ay maaaring manatili sa configuration file na madaling suriin.

read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds

Ang unang dalawang command ay nagbabasa ng username at pagkatapos ng password nang walang echo, ang pangatlo ay nagsusulat ng dalawang linya, ang pang-apat ay naglilimita sa file, at ang huli ay nagbubukas ng client gamit ang file na iyon. Tandaan na read -r ay nag-iingat ng backslash, at iyon mismo ang uri ng detalyeng nagpapalit ng gumaganang password sa nabigong isa kapag nakalimutan.

Iwasang buuin ang file gamit ang unquoted na variable o here-document na puno ng shell expansion. Maaaring baguhin ng dalawa ang mga karakter bago makarating sa file, at ang resultang pagkabigo ay mukhang pagtanggi ng VPN dahil tunay na iba ang password sa disk sa password na alam mo. Kung pinaghihinalaan mo ito, ihambing ang byte length ng file sa inaasahang halaga nang hindi ipiniprinta ang secret mismo. Ang pagkakaiba ng isa o dalawang byte ang pirma ng isang aksidente sa quoting.

Basahin ang yugto mula sa unang error

Itago ang unang partikular na mensahe mula sa isang pagtatangka, pagkatapos klasipikahin ito. Lokal na validation error, kulang na private key, hindi available na secret agent at pagkabigo ng authentication sa gateway ay apat na magkaibang resulta na may apat na magkaibang may-ari. Isa lang sa kanila ang tungkol sa account.

Kung talagang tinatanggihan ng gateway ang tamang naipadalang credential, suriin ang account, ang authentication backend at anumang kinakailangang challenge kasama ng administrator. Ang pangkalahatang pagkabigo sa authentication ay hindi nagpapangalan ng ipinagbabawal na karakter.

Ibalik ang aprubadong halaga sa tamang mekanismo sa halip na bawasan ito sa mga titik at digit. Ang patakaran sa password ay pag-aari ng operator, at ang workaround na tahimik na nilalampasan iyon ay hindi pag-aayos. Itinatago rin nito ang tunay na depekto sa susunod na tao, na makakaharap sa parehong error na may mahinang password at walang mas mabuting ideya.