OpenVPN auth-user-pass: fails, stdin vai uzvedne? Kā izvēlēties

Trīs lietas nosaka, kuru akreditācijas datu avotu izmantot: vai pie konsoles sēž cilvēks, vai noslēpums drīkst dzīvot diskā un vai citam procesam ir jāatbild uz uzvedni. Izvēloties nepareizi, klients ziņo par stdin problēmu, lai gan parole ir pilnīgi derīga, un tas bez iemesla sūta lielāko daļu cilvēku uz serveri. Vispirms izvēlieties ceļu; kļūdu ziņojumiem ir jēga tikai tad, kad zināt, kurš ceļš tos radīja.

Trīs nosacījumi, kas to nosaka

Konsoles uzvedne ir vienīgais ceļš, kam vajadzīgs cilvēks, tāpēc tas ir vienīgais, kas klusi neizdodas systemd vienībā vai konteinerā. Ja cilvēks palaiž klientu un ieraksta paroli, neviens fails nav iesaistīts un nekas sensitīvs nenokļūst diskā. Ja klients tiek palaists sāknēšanas laikā, tā pati uzvedne kļūst par iekāršanu, un taimauts parasti parādās kā vispārīga savienojuma kļūda, nevis akreditācijas datu kļūda.

Akreditācijas datu fails ir pareizā atbilde, kad process tiek palaists bez uzraudzības un noslēpums drīkst palikt diskā kontrolētā atļauju kopā. Kad noslēpumu nedrīkst rakstīt vispār - tikai glabātuves politika, īslaicīgs tokens - jums vajag plūsmu, ko klients var atvērt, kas praksē nozīmē procesa aizstāšanu vai palīgu, kas raksta faila deskriptorā. Pārvaldības saskarne aptver ceturto gadījumu: kontrolieris, kas jau pārvalda tuneļa dzīves ciklu un var atbildēt uz jautājumiem caur socket.

• Cilvēks pie konsoles, bez automatizācijas: interaktīva uzvedne.
• Palaišana bez uzraudzības, noslēpumu drīkst glabāt: akreditācijas datu fails ar režīmu 0600.
• Palaišana bez uzraudzības, noslēpumu nedrīkst glabāt: procesa aizstāšana vai fd, kurā raksta noslēpumu aģents.
• Klientu pieder citam procesam: pārvaldības saskarne.

Kad der divas atbildes, izvēlieties to, kas tur noslēpumu ārpus argv un ārpus shell vēstures. Paroli, kas nodota kā programmas arguments, var nolasīt jebkurš vietējais lietotājs caur procesu sarakstu, un šo atklāšanu ir grūti atcelt.

Ko katrs ievades ceļš patiešām dara

--auth-user-pass vienatnē konsolē prasa lietotājvārdu un paroli. Ja tam dod faila nosaukumu, klients pirmo rindu ņem kā lietotājvārdu, bet otro kā paroli; nekas neatbalsta pēdiņas, komentārus vai atslēgas-vērtības sintaksi. Tas ir viss formāts, tāpēc ikviens, kas to rediģē, gaidot INI failu, to salauž. Iekļautais <auth-user-pass> bloks satur tās pašas divas rindas profilā, kas padara pašu profilu par noslēpumu un ievieto to tajā pašā apstrādes klasē kā privāto atslēgu.

Pārējie divi ceļi ir plūsma un socket. OpenVPN ir nepieciešams tikai lasāms faila deskriptors, tāpēc tā pieņems procesa aizstāšanu, ar cauruli atbalstītu /dev/fd ierakstu vai faila nosaukumu, kas patiesībā ir FIFO. Pārvaldības saskarne atšķiras pēc būtības: klients jautā uzraugošajam procesam vērtības, nevis lasa tās pats. Šī atšķirība ir svarīga atkārtotas savienošanas laikā: akreditācijas datu fails, FIFO, kurā noslēpumu palīgs var rakstīt vēlreiz, un pārvaldības saskarne var nodrošināt no jauna bez cilvēka; procesa aizstāšana to nevar, jo deskriptors tiek iztērēts pirmajā lasīšanā.

Failam jābūt tieši divām rindām

Divi kļūmes režīmi aptver lielāko daļu bojātu akreditācijas datu failu. Windows redaktors atstāj CRLF beigas, vagona atgriešana kļūst par paroles daļu, un serveris noraida vērtību, kas ekrānā izskatās pareiza. Tukša otrā rinda - tukša rinda tur, kur jābūt parolei - atstāj klientu ar tukšu paroli, ko serveris noraida, lai gan vērtība ekrānā izskatās pareiza. Papildu jauna rinda pēc paroles ir nekaitīga. Rakstiet failu no shell, nevis no redaktora, un pārbaudiet baitus:

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

Ceļš ir tikpat svarīgs kā saturs. Relatīvais ceļš tiek atrisināts attiecībā pret procesa darba direktoriju, kas pakalpojumam reti ir direktorija, kurā jūs testējāt. Izmantojiet absolūtu ceļu, padariet failu par klientu palaidošā konta īpašumu un saglabājiet režīmu 0600, lai grupa un citi to nevarētu lasīt. OpenVPN 2.6 rokasgrāmata uzskaita direktīvas pieņemtās formas; pārbaudiet to, pirms izgudrojat trešo.

Pārbaudiet failu, pirms vainojat serveri. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 izpilde izdrukā, vai fails tika atvērts un vēlāk, vai akreditācijas dati tika pieņemti, kas pasaka, kuru slāni mainīt tālāk.

Plūsmas, stdin un to radītās kļūdas

Paroles ievadīšana cauruli ir pirmais, ko vairums cilvēku izmēģina, un ceļš ar visvairāk pārsteigumiem. Procesa aizstāšana darbojas, jo klientam nepieciešams tikai lasāms deskriptors: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin nodošana darbojas tikai tad, kad stdin joprojām ir atvērts un lasāms tajā brīdī, kad klients jautā, kas nav taisnība cauruļvadā, kas to jau ir patērējis.

ERROR: could not read Auth username from stdin ir divi atšķirīgi iemesli. Dažos 2.3.x klientos ziņojums nāca no stdin apstrādes defekta, ko vēlāki 2.3 laidieni izlaboja, tāpēc tik vecs klients uzlabojas tikai ar atjaunināšanu. Mūsdienu klientā tas pats formulējums nozīmē, ka klients pieprasīja konsoles ievadi un stdin nebija terminālis - tieši tā situācija systemd vienībā, cron uzdevumā vai konteinerā, kas palaists bez -t.

auth-nocache pievieno trešo cilpu, kas izskatās kā salauzta parole. Tā pēc lietošanas izmet akreditācijas datus no atmiņas, tāpēc atkārtotai savienošanai, ko izraisījusi tīkla maiņa, nav ko atskaņot, un uzvedne atgriežas. Tā ir direktīva, kas darbojas kā projektēta. auth-nocache maina to, ko klients patur atmiņā, nevis to, ko serveris vai identitātes nodrošinātājs domā par kontu, tāpēc viss labojums ir to pašu failu nodrošināt no jauna, kas tiek nolasīts no jauna restartā - un pārvaldītam savienojumam šim nodrošinājumam jānāk no apstiprinātās noslēpumu glabātuves, nevis no paroles skriptā.

Pārvaldības saskarne, kad uzvedni pieder cits process

Kontrolieris, kas jau uzrauga tuneli, var arī atbildēt uz tā jautājumiem. Palaidiet klientu ar --management 127.0.0.1 7505, lasiet stāvokļa rindas un sekojiet līdzi >PASSWORD:Need 'Auth' username/password. Kontrolieris atbild ar username "Auth" alice un pēc tam password "Auth" ... atsevišķās komandu rindās. 'Auth' marķieris atkārto pieprasījuma identifikatoru, un tam jāsakrīt, citādi atbilde tiek ignorēta un klients gaida.

Cena ir stāvokļa mašīna, kas tagad pieder jums: savienojumu secība, klienta restartēšana un vietējais socket, kuram citiem resursdatora lietotājiem nevajadzētu piekļūt. To, ko jūs pērkat, ir izpildes laikā nodrošināti akreditācijas dati, bez faila diskā un bez uzvednes, kas var iekārties. Ja nekas cits jūsu steikā jau nerunā ar šo protokolu, šis ceļš pievieno komponentu, kas jāuztur.

Kļūmes, kas izskatās kā akreditācijas datu problēmas

TLS rokasspiediens, kas nekad nebeidzas, vai VERIFY ERROR: depth=0, error=certificate signature failure, ir uzticēšanās problēma un notiek pirms jebkura lietotājvārda nolasīšanas. UDP klausītājam vērsts proto tcp klients neizdodas tajā pašā vietā: paketes nekad nesasniedz autentifikācijas posmu, tāpēc katra parole šķiet nepareiza asociācijas dēļ. Turiet sertifikātu pārbaudi ieslēgtu pirms akreditācijas datu nosūtīšanas; pazīstama uzvedne neko nepasaka par to, kas saņem paroli. Pārbaudiet sertifikātu ķēdi, kopējo nosaukumu un transportu, pirms pieskaraties akreditācijas datiem.

Shell kļūdas skriptā, kas saliek profilu, ir otrs nepareizais pavediens. Trūkstoša atstarpe [ ! -f "$file" ] iekšpusē rada command not found, skripts apstājas agri, profils nekad netiek pārbūvēts, un klients tiek palaists ar iepriekšējo. Šī kļūda pieder shell, nevis autentifikācijai, un nekāda paroles pārrakstīšana to neizdzēsīs.

Ne katra uzvedne šajā plūsmā ir šie akreditācijas dati. Privātās atslēgas paroles frāze, HTTP starpniekservera pieteikšanās un pakalpojuma parole ir trīs dažādi noslēpumi, kas tiek prasīti dažādās fāzēs, un atslēgas paroles frāzi parasti apstrādā klients vai aģents, nevis auth-user-pass. Ja uzvedne parādās pirms TLS sesijas izveides, jūs atbildat uz nepareizo jautājumu, un nekāda konta atiestatīšana nepalīdzēs. Kad nepareizā uzvedne ir izslēgta, atlikušās pārbaudes sākas no agrākā slāņa:

• Lasiet pirmo protokola kļūdu, nevis pēdējo akreditācijas datu rindu: TLS, pēc tam autentifikācija, pēc tam push.
• Pārliecinieties, ka fails ir divas rindas, nesatur vagona atgriešanas un tam ir norādīts absolūts ceļš.
• Pārliecinieties, ka profils un komandrinda nav pretrunā par direktīvu.
• Atdaliet "akreditācijas dati pieņemti" no "traffics plūst" - maršrutēšana un DNS ir vēlāks slānis.

Kad klients sasniedz push fāzi, pārtrauciet skatīties uz akreditācijas datiem un sāciet lasīt maršrutus un DNS serverus, ko serveris nosūtīja. Tā ir nākamā problēma, un tai nav nekāda sakara ar paroli, kuru tikko izlabojāt.