MaxSessions, MaxStartups કે નોંધણી: કઈ SSH મર્યાદા પસંદ કરવી

પ્રતિ ગ્રાહક એક ઉપકરણનું વચન આપતી ટનલ સેવાઓને એ વચન MaxSessions તરફથી ભાગ્યે જ મળે છે, અને પહેલું પરીક્ષણ સામાન્ય રીતે તે સાબિત કરે છે. ગ્રાહક બીજી ssh પ્રક્રિયા ખોલે છે, પહેલું સત્ર ચાલુ રહે છે, અને બંને ટનલ ટ્રાફિક વહન કરે છે. દરેક રૂપરેખાંકન વિકલ્પ અલગ વસ્તુની ગણતરી કરે છે, અને તેમાંથી કોઈ ઉપકરણોની ગણતરી કરતું નથી. પહેલા વચનને નામ આપવું તેમની વચ્ચેની પસંદગીને સ્પષ્ટ બનાવે છે.

દરેક વિકલ્પ ખરેખર શું ગણે છે

MaxSessions એક પ્રમાણીકૃત નેટવર્ક જોડાણ દ્વારા વહન થતા ખુલ્લા સત્રોની સંખ્યા મર્યાદિત કરે છે. અહીં સત્ર એટલે શેલ, exec વિનંતી, SFTP જેવી સબસિસ્ટમ, અથવા એક SSH ટ્રાન્સપોર્ટની અંદર મલ્ટિપ્લેક્સ થયેલી સમાન ચેનલ. બીજું ssh આહ્વાન બીજું ટ્રાન્સપોર્ટ ખોલે છે, ફરી પ્રમાણીકરણ કરે છે અને પોતાની પરવાનગી મેળવે છે. પહેલા જોડાણની સત્ર સંખ્યા તેના માટે અપ્રસ્તુત છે.

MaxStartups હજુ પ્રમાણીકૃત ન થયેલા સમવર્તી જોડાણોને મર્યાદિત કરે છે, જે શરૂઆતની થ્રેશોલ્ડ, દર અને પૂર્ણ થ્રેશોલ્ડ તરીકે દર્શાવાય છે. તે એટલા માટે છે કે અડધા-ખુલ્લા હેન્ડશેકનો ઉભરો ડિમનના પ્રમાણીકરણ-પૂર્વ સંસાધનોને ખતમ કરી ન શકે. ક્લાયન્ટ પ્રમાણીકૃત થાય કે તરત તે જોડાણ MaxStartups સામે ગણાવાનું બંધ કરે છે અને કોઈનું સત્ર બની જાય છે. તે ક્યારેય પ્રતિ-વપરાશકર્તા કોટા ન હતું, અને તેને વધારવાથી ગ્રાહક વધુ કરી શકતો નથી.

ઉપકરણ નોંધણીનો નિયમ કોઈ પણ રીતે sshd વિકલ્પ નથી. તે જે પણ સિસ્ટમ ઓળખપત્રો બહાર પાડે છે અને કયું ઉપકરણ તેમને રાખે છે તે ટ્રેક કરે છે તેનું છે, એટલે કે તેને કાઉન્ટરને બદલે નોંધણી, યાદી અને રદની જરૂર છે. આ જરૂરિયાતને sshd રૂપરેખાંકનમાં ભેળવવી એ જ જગ્યા છે જ્યાં આમાંના મોટાભાગના ડિઝાઇન અટકી જાય છે.

MaxSessions ક્યાં કોટા રહેતું નથી

Match User બ્લોક બદલે છે કે કયા રૂપરેખાંકન મૂલ્યો તે વપરાશકર્તાને લાગુ પડે છે, તેથી સેવા ખાતા માટે વધુ કડક MaxSessions સેટ કરવાની તે કુદરતી જગ્યા છે. તે જોડાણોમાં એકત્રિત કરી શકતું નથી, કારણ કે વિકલ્પ દરેક ટ્રાન્સપોર્ટ માટે મૂલ્યાંકન થાય છે. બે ટ્રાન્સપોર્ટને અલગ અલગ મર્યાદા મળે છે, અને વપરાશકર્તા અંતે બ્લોક જે મંજૂરી આપે તેનાથી બમણું મેળવે છે.

ફોર્વર્ડિંગ એ અલગ આશ્ચર્ય છે. TCP ફોર્વર્ડિંગને સત્ર ચેનલની જરૂર નથી, તેથી MaxSessions 0 શેલ અને સબસિસ્ટમ પર પ્રતિબંધ મૂકી શકે છે અને તેમ છતાં -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 ઘટાડીને બીજું ટ્રાન્સપોર્ટ ધ્યાન આપશે તેવી આશા સાથે નહીં.