'n Skrip wat 'n verskaffer se VPN-kliënt begin, hang tot dit uityd, en die log wys die kliënt vra vir 'n verifikasiekode wat niemand ingetik het nie. Die wagwoord is voorsien, so die ooglopende gevolgtrekking is dat die wagwoord verkeerd is. Dit is nie. Die kode-oproep is 'n aparte gesprek op 'n aparte kanaal, en jou skrip het dit nooit oopgemaak nie.

Werk die vyf kontroles hieronder in volgorde deur. Stop by die eerste een wat misluk, want elke latere stap veronderstel dat die vroeëres geld.

Kontrole 1: lees die kliënt hoegenaamd standaardinvoer?

Toets voordat jy enige outomatisering skryf: stuur 'n dummy-geheim deur 'n pyp na die kliënt en kyk wat gebeur. As dit sy opdrag druk en dan wag, lees dit nie die pyp nie.

Baie kliënte maak die terminaal-toestel direk oop, of weier om 'n geheim van 'n stroom wat nie 'n terminaal is nie, te neem, sodat 'n verdwaalde pyp nie 'n wagwoord kan lek nie. OpenVPN is die gedokumenteerde uitsondering, want --auth-user-pass neem 'n lêerpad. Verskaffers se kliënte wat vir 'n eenmalige kode vra, het gewoonlik geen ekwivalente vlag nie, en hul opdrag wag op 'n terminaal wat jou skrip nooit verskaf het nie.

Kontrole 2: het die kindproses 'n terminaal?

'n pty ken 'n terminaal aan die kindproses toe, wat opdragte omskakel in leesbare uitvoer wat jy in volgorde kan antwoord.

import pexpect

child = pexpect.spawn("openconnect vpn.example.net", encoding="utf-8", timeout=30)
child.expect("GROUP:")
child.sendline("staff")
child.expect("USERNAME:")
child.sendline("alice")
child.expect("PASSWORD:")
child.sendline(PASSWORD)
child.expect("Connected as", timeout=60)

Die opdragstringe hierbo is illustratief; kopieer die presiese teks wat jou kliënt druk, insluitend hoofletters en leestekens. Elke verwagting het 'n tydlimiet, en 'n geslote kindproses werp 'n uitsondering in plaas van om 'n status terug te gee, so omring die reeks en behandel einde-van-lêer as 'n mislukking. Let op wat hierdie blok nie doen nie: die kindproses sterf saam met die skrip, want 'n pty is nie 'n losmaak-meganisme nie en disown is 'n ingeboude skulpfunksie wat nie 'n proses kan bereik wat jou skrip geskep het nie.

Kontrole 3: is daar 'n ondersteunde nie-interaktiewe invoer?

Skerm-skraping breek by kliënt-opgraderings, so soek eerste na 'n gedokumenteerde vlag.

Kyk in die hulp-uitvoer vir 'n token- of eenmalige-kode-opsie, en kyk of die diens die kode aanvaar wat by die wagwoordveld aangeheg word. Waar die kliënt 'n geloofsbriewe-lêer lees, gee dit die lêer eerder as 'n opdrag:

openvpn --config office.ovpn --auth-user-pass <(printf "%s\n%s\n" "$USER_NAME" "$PASSWORD")

Proses-substitusie gee die kliënt 'n leesbare pad op stelsels wat /dev/fd verskaf. Die geheim is steeds 'n geheim uit die kliënt se oogpunt, so hou dit uit logs, skulp-geskiedenis en proseslyste. As die kliënt /dev/fd verwerp of die geloofsbriewe-pad meer as een keer oopmaak, skryf 'n regte lêer met streng beperkings en verwyder dit in dieselfde skrip.

Kontrole 4: sal die tonnel die skrip oorleef?

By verstek sterf die tonnel saam met sy ouer, wat die teenoorgestelde is van wat 'n selflaai-skrip nodig het.

disown -h help net wanneer jy die kliënt as 'n skulptaak begin het, want dit wysig daardie skulp se taaktabel en kan nie 'n proses bereik wat jou skrip deur 'n pty geskep het nie. 'n Diensbestuurder is die beter tuiste vir alles wat onbewaak moet herverbind, want dit herbegin die kliënt en teken aan waarom dit dood is. In elk geval, verwag 'n nuwe kode ná elke herverbinding: 'n eenmalige token word deur die eerste suksesvolle verifikasie verbruik.

Let op wat sudo aan die volgorde doen. 'n sudo-wagwoordopdrag is nie die VPN se opdrag nie, en om dit met die VPN-wagwoord te antwoord is die algemeenste manier waarop 'n andersins korrekte verwagtingsorde steeds misluk.

Kontrole 5: moet 'n persoon se kode in 'n skrip wees?

Dit is die kontrole wat mense oorslaan. 'n Token behoort aan 'n persoon, terwyl 'n tonnel wat volgens 'n skedule moet opkom aan die masjien behoort.

As 'n taak onbewaak moet herverbind, vra of 'n masjinsertifikaat of 'n diensrekening die interaktiewe aanmelding kan vervang. Om iemand se eenmalige kode te outomatiseer verander 'n tweede faktor in 'n gestoorde geheim, wat 'n beleidsverandering is eerder as 'n gerief vir skripwerk. Waar die diens albei ondersteun, kies die geloofsbriewe wat pas by hoe die taak werklik loop. Skryf die antwoord neer, want die volgende persoon sal vra waarom die skrip 'n token hou.

Hoe 'n werkende skrip lyk

Die skrip druk die stap wat dit bereik het, nooit die geheim nie, en keer terug met 'n nie-nul kode by enige mislukte verwagting.

Toets dit deur dit opsetlik te breek: verkeerde wagwoord, verkeerde groep, vervalde token. Elke mislukking moet by 'n genoemde stap stop in plaas daarvan om te hang. Hardloop dit dan een keer teen die werklike diens en kontroleer die tonnel van buite die skrip, nie van binne nie.

Verwante artikels