Ուղղում՝ OpenVPN-ը չկարողացավ Auth օգտանունը կարդալ ստանդարտ մուտքից

could not read Auth username from stdin հավատարմագրման խնդրի տեսք ունի և այդպիսին չէ։ OpenVPN-ը փորձեց օգտանունը հարցնել ստանդարտ մուտքից, ընթեռնելի ոչինչ չգտավ և կանգ առավ նախքան սերվերի հետ կապվելը։ Հաշիվը կարող է լիովին վավեր լինել. պարզապես գործընթացը հարցնելու մարդ չունի։

Այդ պատճառով առաջին օգտակար քայլը հաստատելն է, թե ինչ է կարդում հաճախորդը, այլ ոչ թե նորից փորձել կապը կամ փոխել սերվերի կողմի կարգավորումները։ Անցեք ստորև բերված ստուգումները հերթականությամբ և կանգ առեք առաջին ձախողվածի վրա։

Կարդացեք սխալը որպես տեղական մուտքի ձախողում

Երբ auth-user-pass հայտնվում է առանց ֆայլի արգումենտի, հաճախորդը սպասում է հարցման։ Ինտերակտիվ shell-ում այդ հարցումն աշխատում է, քանի որ գործընթացն ունի տերմինալ։ systemd-ի, cron առաջադրանքի կամ կոնտեյների տակ ստանդարտ մուտքը սովորաբար դատարկ է, և ընթերցումն անմիջապես վերադառնում է ձեր տեսած սխալով։

Հաղորդագրությունը նաև նշում է ձախողված դաշտը՝ օգտանունը կամ գաղտնաբառը, ինչը ցույց է տալիս, թե որքան հեռու գնաց ընթերցումը։ Օգտանվի բացակայությունը նշանակում է, որ գործընթացն ընդհանրապես ոչինչ չկարողացավ կարդալ։ Հաջող օգտանվից հետո գաղտնաբառի բացակայությունը նշանակում է, որ մուտքի հոսքն ավարտվեց երկու ընթերցումների միջև, ինչը բնորոշ է կիսով չափ գրված ֆայլին կամ փակ խողովակին։

Նախքան այլ բան փոխելը հաստատեք հաճախորդի սեփական տեսակետը։ Գործարկեք այն առաջին պլանում նույն կոնֆիգուրացիայով և նույն օգտատիրոջով, և հետևեք՝ արդյոք հարցումը հայտնվում է։ Եթե այն հայտնվում է ձեր shell-ում, բայց ոչ ծառայության կառավարչի տակ, տարբերությունը մուտքի աղբյուրում է, ոչ հավատարմագրերում։ Unit ֆայլի և ձեր shell-ի միջավայրի արագ համեմատությունը սովորաբար ցույց է տալիս, թե որն է տերմինալ տրամադրում։

Ծառայությանը տվեք աջակցվող հավատարմագրերի աղբյուր

Առանց հսկողության աշխատանքի աջակցվող աղբյուրը հավատարմագրերի ֆայլն է, որը որպես արգումենտ փոխանցվում է auth-user-pass-ին։ Ֆայլը կարդացվում է որպես պարզ տեքստ. առաջին տողը օգտանունն է, երկրորդը՝ գաղտնաբառը։ Նշեք այն բացարձակ ուղով, օրինակ՝ /etc/openvpn/client/creds , որպեսզի ծառայության հաշվի աշխատանքային գրացուցակը չկարողանա փոխել հրահանգի իմաստը։

Թույլտվությունները նույնքան կարևոր են, որքան ուղին։ Ֆայլը պետք է ընթեռնելի լինի հաճախորդը գործարկող հաշվի համար և ոչ բոլորի, և պետք է պատկանի ծառայության հաշվին կամ root-ին՝ ծառայությունը ներառող խմբով։ Ստուգեք ընթեռնելիությունը որպես այդ հաշիվ՝ չտպելով բովանդակությունը։

Հարաբերական ուղին լուռ ձախողման եղանակն է։ Պրոֆիլը կարող է լինել մեկ գրացուցակում, մինչ systemd-ը գործընթացը գործարկում է այլ տեղ, ուստի ձեր shell-ում լուծվող ֆայլը ծառայության համար չի լուծվում։ Տեղափոխեք հավատարմագրերը ֆիքսված վայր և հղեք դրանց բացարձակ։ Այնուհետև մեկ անգամ գործարկեք ծառայությունը և հաստատեք, որ օգտագործվում է նույն ուղին, փոխանակ վստահելու պրոֆիլի խմբագրիչի տեսքին։

Եթե տեղադրումը պահանջում է մեկանգամյա կոդ կամ այլ ինտերակտիվ մարտահրավեր, որոշեք՝ արդյոք հաճախորդի աշխատանքային հոսքը իսկապես աջակցում է դրան առանց հսկողության։ Ստատիկ գաղտնաբառով ֆայլը չի կարող պատասխանել պտտվող կոդին, և անպատասխանելի հարցումը կրկնելը ոչինչ չի ավելացնում։

Ինչու script-security-ն չի օգնի

script-security վերահսկում է՝ արդյոք հաճախորդը կարող է սկրիպտներ գործարկել և որքան կարող է փոխանցել նրանց, ներառյալ՝ արդյոք գաղտնաբառը կարելի է փոխանցել սկրիպտին միջավայրի փոփոխականով։ Այն ոչինչ չի ասում այն մասին, թե որտեղից են սկզբնապես գալիս օգտանունը և գաղտնաբառը։

Այն ավելի բարձր մակարդակի բարձրացնելը սովորական ռեֆլեքս է, քանի որ հաղորդագրությունը հիշատակում է Auth, բայց դա փոխում է սկրիպտների թույլտվությունները, ոչ թե մուտքի աղբյուրը, և ընդլայնում է, թե ինչ կարող է գործարկել հաճախորդը։ Եթե օժանդակ սկրիպտը դիզայնի մաս է, նախ ուղղեք մուտքի աղբյուրը և պահեք անվտանգության մակարդակը տեղադրմանը անհրաժեշտ ամենացածր արժեքի վրա։

Կառավարման միջերեսը օրինական այլընտրանք է։ Frontend-ը կարող է միանալ դրան, ստանալ հավատարմագրերի հարցումը և պատասխանել օգտանունով ու գաղտնաբառով, այդպես են աշխատում որոշ GUI-ներ։ Եթե օգտագործում եք այն, կապեք տեղական հասցեին, պաշտպանեք կառավարման գաղտնաբառի ֆայլով և սահմանափակեք, թե ով կարող է միանալ, որովհետև դա հաճախորդի կառավարման ուղին է։

Ստուգեք հաջորդ փուլը այն բանից հետո, երբ հաճախորդը կարդա ֆայլը

Հենց հաճախորդը կարողանա կարդալ հավատարմագրերը, հաջորդ ձախողումն իսկական փոխանակում է սերվերի հետ, և դրա հաղորդագրությունն այլ իմաստ ունի։ Այդ փուլում հավատարմագրման ձախողումը նշանակում է, որ սերվերը մերժել է հաշիվը. մարտահրավերի պատասխանը նշանակում է, որ սերվերը ցանկանում է այլ գործոն։ Դրանց վերաբերվեք որպես նոր խնդիրների, ոչ որպես նույնի կրկնության։

Փորձարկեք ամբողջ ուղին այնպես, ինչպես ծառայությունը կգործարկի այն՝ նույն հաշիվը, նույն աշխատանքային գրացուցակը, նույն unit միջավայրը։ Կապը, որն աշխատում է միայն ձեր shell-ից գործարկելիս, նշան է, որ միջավայրի փոփոխականը կամ տերմինալը դեռ հոսքի մաս են։

Այնուհետև պահեք գաղտնիքները այնտեղ, որտեղ պետք է։ Հրամանի տողի արգումենտներում գաղտնաբառերը երևում են գործընթացների աղյուսակում, իսկ վրիպազերծման արտածման մեջ եղածները հայտնվում են տոմսերում։ Օգտագործեք պաշտպանված ֆայլ կամ կառավարման միջերես, պահեք մատյանները այնպիսի մակարդակում, որը չի կրկնում հավատարմագրերը, և փոխեք ֆայլը, երբ հեռանում է մուտք ունեցող որևէ մեկը։

Ստուգաթերթ. հավատարմագրերի բացարձակ ուղի, ընթեռնելի որպես ծառայության հաշիվ, տերմինալ պետք չէ, script-security-ն իր նվազագույնում, կառավարման միջերեսը միայն եթե կապված և նույնականացված է, և արդյունքում ստացված սերվերի պատասխանը դիտվում է որպես առանձին իրադարձություն։