Ինչպես ավտոմատացնել VPN մուտքը, որը սպասում է token կոդի
Հրամանի տողի VPN հաճախորդը, որը հարցնում է տերմինալում, արգելափակում է սկրիպտը, որը միայն գաղտնաբառ է ուղարկում խողովակով: Կատարեք այս հինգ ստուգումները, նախքան expect-ին դիմելը:
Սկրիպտը, որը գործարկում է մատակարարի VPN հաճախորդը, կախվում է մինչև ժամկետի լրանալը, և մատյանը ցույց է տալիս, որ հաճախորդը պահանջում է հաստատման կոդ, որը ոչ ոք չի մուտքագրել։ Գաղտնաբառը տրվել էր, ուստի ակնհայտ եզրակացությունն այն է, որ գաղտնաբառը սխալ է։ Այդպես չէ։ Կոդի հարցումը առանձին զրույց է առանձին ալիքով, և ձեր սկրիպտը երբեք չի բացել այն։
Անցեք ստորև նշված հինգ ստուգումները հերթականությամբ։ Կանգ առեք առաջին ձախողվածի վրա, որովհետև յուրաքանչյուր հաջորդ քայլ ենթադրում է, որ նախորդները ճիշտ են։
Ստուգում 1. արդյո՞ք հաճախորդն ընդհանրապես կարդում է ստանդարտ մուտքը?
Փորձարկեք նախքան որևէ ավտոմատացում գրելը՝ խողովակով կեղծ գաղտնիք ուղարկեք հաճախորդին և տեսեք, թե ինչ է լինում։ Եթե այն տպում է իր հարցումը և հետո սպասում, ապա խողովակը չի կարդում։
Շատ հաճախորդներ ուղղակիորեն բացում են տերմինալի սարքը կամ հրաժարվում են գաղտնիք վերցնել ոչ տերմինալ հոսքից, որպեսզի մոլորված խողովակը չկարողանա արտահոսել գաղտնաբառը։ OpenVPN-ը փաստաթղթավորված բացառությունն է, որովհետև --auth-user-pass-ը վերցնում է ֆայլի ուղի։ Մեկանգամյա կոդ պահանջող մատակարարների հաճախորդները սովորաբար չունեն համարժեք դրոշակ, և նրանց հարցումը սպասում է տերմինալի, որը ձեր սկրիպտը երբեք չի տրամադրել։
Ստուգում 2. արդյո՞ք զավակ գործընթացն ունի տերմինալ?
pty-ն տերմինալ է հատկացնում զավակին, ինչը հարցումները դարձնում է ընթեռնելի արտածում, որին կարող եք հերթով պատասխանել։
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)Վերևի հարցումների տողերը օրինակելի են՝ պատճենեք ձեր հաճախորդի տպած ճշգրիտ տեքստը՝ ներառյալ մեծատառերն ու կետադրությունը։ Յուրաքանչյուր սպասում ունի ժամկետ, և փակ զավակը բացառություն է նետում վիճակ վերադարձնելու փոխարեն, ուստի փաթաթեք հաջորդականությունը և ֆայլի վերջը համարեք ձախողում։ Նկատեք, թե այս բլոկը ինչ չի անում՝ զավակը մահանում է սկրիպտի հետ, որովհետև pty-ն անջատման մեխանիզմ չէ, և disown-ը shell-ի ներկառուցված հրաման է, որը չի հասնում ձեր սկրիպտի ստեղծած գործընթացին։
Ստուգում 3. կա՞ աջակցվող ոչ ինտերակտիվ մուտք։
Էկրանի քերծումը կոտրվում է հաճախորդի թարմացումների ժամանակ, ուստի նախ փնտրեք փաստաթղթավորված դրոշակ։
Ստուգեք օգնության արտածումը token կամ մեկանգամյա կոդի տարբերակի համար, Եվ ստուգեք՝ արդյոք ծառայությունն ընդունում է գաղտնաբառի դաշտին կցված կոդը։
openvpn --config office.ovpn --auth-user-pass <(printf "%s\n%s\n" "$USER_NAME" "$PASSWORD")Գործընթացի փոխարինումը հաճախորդին տալիս է ընթեռնելի ուղի այն համակարգերում, որոնք տրամադրում են /dev/fd։ Գաղտնիքը հաճախորդի տեսանկյունից մնում է գաղտնիք, ուստի պահեք այն մատյաններից, shell-ի պատմությունից և գործընթացների ցանկերից դուրս։ Եթե հաճախորդը մերժում է /dev/fd-ն կամ հավատարմագրերի ուղին բացում է մեկից ավելի անգամ, գրեք իրական ֆայլ խիստ թույլտվություններով և ջնջեք այն նույն սկրիպտում։
Ստուգում 4. արդյո՞ք թունելը կապրի ավելի երկար, քան սկրիպտը?
Լռելյայն թունելը մահանում է իր ծնողի հետ, ինչը հակառակն է այն բանի, ինչ պետք է գործարկման սկրիպտին։
disown -h-ը օգնում է միայն այն դեպքում, երբ հաճախորդը գործարկել եք որպես shell-ի աշխատանք, որովհետև այն խմբագրում է այդ shell-ի աշխատանքների աղյուսակը և չի հասնում ձեր սկրիպտի՝ pty-ով ստեղծած գործընթացին։ Ծառայությունների կառավարիչը ավելի լավ տուն է այն ամենի համար, ինչ պետք է վերամիանա առանց հսկողության, որովհետև այն վերագործարկում է հաճախորդին և գրանցում, թե ինչու այն մահացավ։ Ամեն դեպքում, յուրաքանչյուր վերամիավորումից հետո սպասեք նոր կոդի՝ մեկանգամյա token-ը սպառվում է առաջին հաջող նույնականացմամբ։
Նկատեք, թե sudo-ն ինչ է անում հաջորդականությանը։ sudo-ի գաղտնաբառի հարցումը VPN-ի հարցումը չէ, և դրան VPN-ի գաղտնաբառով պատասխանելը ամենատարածված ձևն է, որով այլապես ճիշտ սպասումների կարգը դեռ ձախողվում է։
Ստուգում 5. արդյո՞ք մարդու կոդը պետք է լինի սկրիպտում?
Սա այն ստուգումն է, որը մարդիկ բաց թողնում են։ Token-ը պատկանում է մարդուն, մինչդեռ թունելը, որը պետք է բարձրանա ըստ ժամանակացույցի, պատկանում է մեքենային։
Եթե աշխատանքը պետք է վերամիանա առանց հսկողության, հարցրեք՝ արդյոք մեքենայի վկայականը կամ ծառայության հաշիվը կարող է փոխարինել ինտերակտիվ մուտքին։ Ինչ-որ մեկի մեկանգամյա կոդի ավտոմատացումը երկրորդ գործոնը դարձնում է պահված գաղտնիք, ինչը քաղաքականության փոփոխություն է, ոչ թե սկրիպտավորման հարմարավետություն։ Այնտեղ, որտեղ ծառայությունը աջակցում է երկուսին, ընտրեք այն հավատարմագիրը, որը համապատասխանում է աշխատանքի իրական ընթացքին։ Գրեք պատասխանը, որովհետև հաջորդ մարդը կհարցնի, թե ինչու սկրիպտը token է պահում։
Ինչպիսին է աշխատող սկրիպտը
Սկրիպտը տպում է հասած քայլը, երբեք՝ գաղտնիքը, և ցանկացած ձախողված սպասման դեպքում դուրս է գալիս ոչ զրոյական կոդով։
Փորձարկեք այն դիտավորյալ կոտրելով՝ սխալ գաղտնաբառ, սխալ խումբ, ժամկետանց token։ Յուրաքանչյուր ձախողում պետք է կանգ առնի անվանված քայլում, այլ ոչ թե կախվի։ Այնուհետև մեկ անգամ գործարկեք այն իրական ծառայության դեմ և ստուգեք թունելը սկրիպտից դրսից, ոչ ներսից։