MaxSessions, MaxStartups թե սարքի գրանցում. ո՞ր SSH սահմանն ընտրել

Մեկ սարք յուրաքանչյուր բաժանորդի համար խոստացող թունելային ծառայությունները հազվադեպ են այդ խոստումը ստանում MaxSessions-ից, և առաջին թեստը սովորաբար դա ապացուցում է։ Բաժանորդը բացում է երկրորդ ssh պրոցես, առաջին սեսիան շարունակում է աշխատել, և երկու թունելներն էլ տեղափոխում են տրաֆիկ։ Յուրաքանչյուր կարգավորման տարբերակ հաշվում է տարբեր բան, և դրանցից ոչ մեկը սարքեր չի հաշվում։ Խոստումն առաջինը անվանելն է, որ նրանց միջև ընտրությունը դարձնում է ակնհայտ։

Ինչ է իրականում հաշվում յուրաքանչյուր տարբերակը

MaxSessions-ը սահմանափակում է մեկ նույնականացված ցանցային կապի կողմից տեղափոխվող բաց սեսիաների քանակը։ Սեսիան այստեղ նշանակում է shell, exec հարցում, SFTP-ի նման ենթահամակարգ կամ նմանատիպ ալիք, որը մուլտիպլեքսված է մեկ SSH տրանսպորտի ներսում։ Երկրորդ ssh կանչը բացում է երկրորդ տրանսպորտ, նորից նույնականացվում և ստանում է իր թույլտվությունը։ Առաջին կապի սեսիաների քանակն իր համար անկարևոր է։

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

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

Որտեղ MaxSessions-ը դադարում է քվոտա լինել

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

Վերահասցեավորումն առանձին անակնկալ է։ TCP վերահասցեավորումը սեսիայի ալիք չի պահանջում, ուստի MaxSessions 0-ը կարող է արգելել shell-երը և ենթահամակարգերը և միևնույն ժամանակ թույլատրել -L և -R թունելները։ Ծառայությունը, որը միայն վերահասցեավորում է և սեսիաների քանակը համարում իր թունելի քվոտա, ոչինչ չի չափում։ Այդ վարքը փաստաթղթավորված է OpenSSH սերվերի կարգավորման տեղեկատուում, և արժե կարդալ այն նախքան տարբերակի անվան շուրջ նախագծելը։

Արտթողեք գործող կարգավորումը, այլ ոչ թե այն ֆայլը, որը կարծում եք բեռնված է։ Ներառումները և drop-in պանակները հաճախ նշանակում են, որ գործող արժեքը այն արժեքը չէ, որը դուք խմբագրել եք։

MaxStartups-ը պաշտպանում է դեմոնին, ոչ թե բաժանորդին

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

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

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

Մեկ օգտատիրոջ բնիկը պահանջում է ընդհանուր վիճակ

Իսկական մեկ ակտիվ տրանսպորտի քաղաքականությունը պահանջում է ամրագրում, որը պահվում է sshd-ից դուրս ինչ-որ տեղ։ Ընդունման քայլը պետք է ատոմար կերպով զբաղեցնի հաշվի բնիկը, ազատի այն, երբ կապը փակվում է, ժամկետանց դարձնի, երբ հաճախորդն անհետանում է առանց փակելու, և որոշի՝ նոր փորձը մերժվում է, թե փոխարինում է հինին։ Այդ վերջին որոշումը ապրանքային որոշում է, ոչ թե տեխնիկական մանրուք, որովհետև ակտիվ թունելի փոխարինումը ինչ-որ մեկին անջատում է։

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

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

Ստուգեք քաղաքականությունը երկու իրական կապերով

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

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

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

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