SSH એજન્ટ ફોરવર્ડિંગ વિરુદ્ધ કી કોપી કરવી: ખરેખર શું લીક થાય છે
પબ્લિક-કી લોગિન સહી મોકલે છે, પ્રાઇવેટ કી નહીં. એજન્ટ ફોરવર્ડિંગ હજુ પણ બીજા હોસ્ટને સહી કરવાની ક્ષમતા આપે છે, જે અલગ એક્સપોઝર છે.
બે અલગ ઘટનાઓને લીક થયેલી SSH કી કહેવામાં આવે છે, અને તે વિવિધ પ્રતિસાદ માંગે છે. પબ્લિક-કી પ્રમાણીકરણ પબ્લિક કી અને પ્રાઇવેટ કી વડે બનાવેલી સહી મોકલે છે, તેથી પ્રાઇવેટ કી ક્યારેય વિનંતીનું ક્ષેત્ર હોતું નથી. એજન્ટ ફોરવર્ડિંગ બીજું કંઈક ખુલ્લું કરે છે, કારણ કે તમારા ફોરવર્ડ કરેલા એજન્ટ સુધી પહોંચી શકતું દૂરનું હોસ્ટ કી ક્યારેય રાખ્યા વિના તેને સહી કરવા કહી શકે છે. આ બંનેને એક ઘટના તરીકે ગણવાથી કાં તો નિરર્થક કી બદલી થાય છે અથવા ડેલિગેશન ચાલુ રહે છે.
પબ્લિક-કી લોગિન કી નહીં, સહી મોકલે છે
પ્રમાણીકરણની આપલે વપરાશકર્તાની પબ્લિક કી અને સેશન ડેટા પરની સહી વહન કરે છે. સર્વર તે સહીને પહેલેથી વિશ્વાસ ધરાવતી કી સાથે ચકાસે છે, તેથી પ્રાઇવેટ અડધો ભાગ અવિશ્વસનીય નેટવર્ક પાર ક્લાયન્ટ પર રહી શકે છે. ટનલ જોતો VPN ઓપરેટર કોઈ પણ સંજોગોમાં એન્ક્રિપ્ટ થયેલું SSH સેશન જુએ છે.
તે પ્રોટોકોલનું વર્ણન કરે છે, માર્ગ પરના દરેક અંતિમ બિંદુની વિશ્વસનીયતાનું નહીં. હોસ્ટ-ઓળખ ચકાસણી અકબંધ રાખો, કારણ કે કોઈ પણ હોસ્ટ કી સ્વીકારતો ક્લાયન્ટ અહીં ચર્ચાતા નિયંત્રણ કરતાં અલગ નિયંત્રણ છોડી દે છે. પકડાયેલું સેશન અને પકડાયેલી કી અલગ તારણો છે, અને તેમાંથી ફક્ત એક જ ઓળખપત્રોની ખોટ છે. બંનેને અહેવાલમાં અલગ વાક્યોમાં રાખો.
ssh-keygen -lf ~/.ssh/id_ed25519.pub ssh -o StrictHostKeyChecking=yes [email protected]
પ્રથમ આદેશ પબ્લિક ફિંગરપ્રિન્ટ છાપે છે જેથી તમે તેને સર્વર જે સૂચિબદ્ધ કરે છે તેની સાથે સરખાવી શકો. બીજો આદેશ કોઈએ ન વાંચેલા ડિફોલ્ટ પર ભરોસો રાખવાને બદલે હોસ્ટ-કી ચકાસણીને સ્પષ્ટ કરે છે. કી વિશે કંઈપણ બદલતા પહેલાં બંને ચલાવો, જેથી આધારરેખા દસ્તાવેજિત થાય.
એજન્ટ ફોરવર્ડિંગ સહી કરવાની ક્ષમતા સોંપે છે
ફોરવર્ડિંગ ચાલુ હોય ત્યારે દૂરના હોસ્ટ પર સોકેટ દેખાય છે અને સ્થાનિક એજન્ટ તેમાંથી આવતી વિનંતીઓનો જવાબ આપે છે. સેશન દરમિયાન તે સોકેટ વાપરી શકતો કોઈ પણ વ્યક્તિ લોડ કરેલી ઓળખ સ્વીકારતા હોસ્ટ સમક્ષ તમારા તરીકે પ્રમાણીકરણ કરી શકે છે. તે કામ કરે તે માટે કોઈ પ્રાઇવેટ કી નેટવર્ક પાર કરતી નથી.
એક્સપોઝર ક્ષમતા છે, ફાઇલ નહીં. તેથી ફોરવર્ડિંગ નામવાળા કાર્ય અને નામવાળા હોસ્ટનું છે, લેપટોપ બનાવતા દરેક કનેક્શનનું નહીં. ફોરવર્ડ કરેલા એજન્ટ વિના કનેક્શન રિલે કરતું જમ્પ હોસ્ટ સામાન્ય રીતે જરૂરિયાત સંપૂર્ણપણે દૂર કરે છે.
ssh-add -l ssh -o ForwardAgent=no [email protected] ssh -J [email protected] [email protected]
પ્રથમ એ બતાવે છે કે એજન્ટ હાલમાં કઈ ઓળખ ધરાવે છે, જે તેનું સોકેટ બીજી મશીનને આપતા પહેલાં જાણવા જેવું છે. બીજો ડેલિગેશન વિના જોડાય છે. ત્રીજો જમ્પ હોસ્ટની તે પેટર્ન દર્શાવે છે જે ઘણી વાર ફોરવર્ડિંગને સંપૂર્ણપણે બદલી નાખે છે.
તમારી પાસેના પુરાવા પરથી પ્રતિસાદ પસંદ કરો
જે સહીકારક ઓળખ ખુલ્લી પડી હોવાનું માનવામાં આવે છે તેના માટે બદલી અને રદ કરવાની પ્રક્રિયા જરૂરી છે, અને જે સેવાઓ તેના પર વિશ્વાસ રાખતી હતી તેમાંથી તેની સ્વીકૃતિ દૂર કરવી જરૂરી છે. તમારા લેપટોપ પરની નકલ ભૂંસવાથી અન્ય દરેક નકલ અસ્પૃશ્ય રહે છે. સેવાઓથી શરૂ કરો, પછી ક્લાયન્ટ સાફ કરો.
કામચલાઉ ડેલિગેશન સમસ્યા વધુ સાંકડી છે. જે ફોરવર્ડિંગની જરૂર ન હતી તે સમાપ્ત કરો, અને ઘટનાના માલિક સાથે સમીક્ષા કરો કે તે કયા સેશન અને ઓળખને આવરી લેતું હતું. કી બદલી પછી પણ આવી શકે, પરંતુ તે પુરાવા નક્કી કરે છે, ચિંતા નહીં.
કોઈ નિરીક્ષિત નિકાસ સાબિત કરતી નથી કે તમે જે મિકેનિઝમથી ડરતા હતા તે દેખાયું નહીં, એટલું જ. તે સોકેટની બીજી બાજુનું હોસ્ટ બીજું શું કરી શક્યું હોત તે વિશે કંઈ કહેતું નથી.
અહેવાલમાં નિયંત્રણો અલગ રાખો
પ્રાઇવેટ સામગ્રીનું રક્ષણ કરો, કોણ તેની પાસે સહી માંગી શકે તે મર્યાદિત કરો, સામેની બાજુની ઓળખ ચકાસાયેલી રાખો. તે ત્રણ નિયંત્રણો છે જે એકબીજાને મજબૂત કરે છે, અને શું થયું તે સમજાવતી વખતે તેમાંથી કોઈ પણ બીજાનું સ્થાન લેતું નથી.
છેડાયેલું લેપટોપ અથવા તેના પરની વિશેષાધિકારવાળી એપ્લિકેશન ઘણા વિશાળ પ્રભાવવાળો ત્રીજો કિસ્સો છે. VPN માર્ગ બદલવાથી તે ઉકેલાતું નથી અને ડિસ્કમાંથી વંચાઈ ગયેલી હોઈ શકે તેવી કી પરનો વિશ્વાસ પાછો આવતો નથી.
કયું ઘટક વિશ્વસનીય હતું, ફોરવર્ડિંગ ચાલુ હતું કે નહીં, અને ખરેખર શું નિરીક્ષણ કરાયું તે લખો. તે જ રેકોર્ડ આગલા નિર્ણયને લીકનો અર્થ શું છે તેવી અટકળના બદલે વાજબી બનાવે છે.