SSH કીનો પાસફ્રેઝ ફાઇલને સુરક્ષિત રાખે છે, માર્ગને નહીં

જૂના લેપટોપની બેકઅપ ડ્રાઇવમાં હજી પણ ખાનગી SSH કી છે, અને કોઈ પૂછે છે કે VPN તેને સુરક્ષિત રાખે છે કે નહીં. તે રાખતું નથી, અને ક્યારેય રાખ્યું નથી. VPN બે નેટવર્ક વચ્ચેનો માર્ગ સુરક્ષિત રાખે છે; પાસફ્રેઝ ફાઇલને સુરક્ષિત રાખે છે; એજન્ટ ચાલતું સેશન સુરક્ષિત રાખે છે. ત્રણ જુદી રીતો, ત્રણ જુદી નિષ્ફળતાઓ, અને ચોરાયેલી નકલને ફક્ત પહેલી બેની ચિંતા છે.

પાસફ્રેઝ ફાઇલનું છે

SSH કીનો પાસફ્રેઝ સ્થિર સ્થિતિમાં ખાનગી કી સામગ્રીને એન્ક્રિપ્ટ કરે છે. તે સર્વરને મોકલાતો એકાઉન્ટ પાસવર્ડ નથી, અને VPNમાં જોડાવા માટે વપરાતું ઓળખપત્ર નથી. આ બંનેને ભેગા કરવાથી એવા ફેરફારો થાય છે જે જોખમનું નિરાકરણ કરતા નથી.

OpenSSHનું ssh-keygen માર્ગદર્શિકા પાસફ્રેઝની સંભાળ આવરે છે, જેમાં -p સ્વિચનો સમાવેશ થાય છે જે પહેલેથી અસ્તિત્વમાં હોય તેવી કી પર નવો પાસફ્રેઝ સેટ કરે છે.

હાલની કી માટે આદેશનું સ્વરૂપ સરળ છે, અને તે ફાઇલને ફરીથી લખે છે:

ssh-keygen -p -f ~/.ssh/id_ed25519

કીના માલિકની મંજૂર જાળવણી અને પુનઃપ્રાપ્તિ પ્રક્રિયા વાપરો, કારણ કે આ લેખન છે, નિરીક્ષણ નહીં. ખાનગી ફાઇલ પ્રકાશિત કરશો નહીં અને વહેંચાયેલ આદેશ લાઇન પર સાચો પાસફ્રેઝ ન મૂકો. પાસફ્રેઝ બદલવાથી પહેલાં લીધેલી નકલ ફરીથી એન્ક્રિપ્ટ થતી નથી. જૂની નકલનું સ્થાન ટિકિટમાં નોંધો જેથી માલિક નક્કી કરી શકે કે તેનો નાશ કરવો છે કે નહીં.

નકલ લેપટોપ અને ટનલ કરતાં વધુ જીવે છે

એકવાર કી ફાઇલની નકલ થઈ જાય પછી લેપટોપનું ચાલુ VPN જોડાણ તેના વિશે કંઈ કહેતું નથી. મહત્વનું એ છે કે ફાઇલ પોતે કેટલી સારી રીતે સુરક્ષિત છે, અને કયા સર્વરો હજી પણ મેળ ખાતી જાહેર કી પર ભરોસો કરે છે.

વર્તમાન ફાઇલ પરનો પાસફ્રેઝ બદલવાથી નકલને અસર થતી નથી, અને સર્વર પરના authorized_keysમાંથી એ જ જાહેર કી દૂર થતી નથી. રદ કરવું અને ફરીથી એન્ક્રિપ્ટ કરવું અલગ ક્રિયાઓ છે.

તેથી લીક થયેલી ખાનગી કીને નેટવર્ક ઘટના નહીં, ઓળખની ઘટના ગણો. સ્વીકૃત કીને જે સર્વરો અને નોંધણી પ્રક્રિયા ધરાવે છે તેમના દ્વારા દૂર કરો અથવા બદલો. VPN બંધ કરવું એક ક્ષણે એક માર્ગ મર્યાદિત કરે છે; તે રદ કરવું નથી.

અનલોક કરવાથી રહસ્ય એજન્ટમાં જાય છે

એજન્ટ પછીની પ્રમાણીકરણ માટે ડિક્રિપ્ટ થયેલી ઓળખ રાખે છે, જેથી વપરાશકર્તાને દરેક જોડાણ માટે પાસફ્રેઝ ફરી લખવો ન પડે. આ તેની પોતાની સુરક્ષા સીમા ધરાવતી સુવિધા છે.

ssh-agent તેના -t વિકલ્પ દ્વારા ઓળખ કેટલો સમય લોડ રહે તે મર્યાદિત કરી શકે છે, અને પ્રતિ-ઓળખ સેટિંગ તે મર્યાદાને વટાવી શકે છે. VPN ડિસ્કનેક્ટ થવાથી દરેક લોડ થયેલી કી ભૂલાઈ જાય એમ ધારવાને બદલે તમે ખરેખર ચલાવો છો તે એજન્ટ માટે નીતિ પસંદ કરો.

કી અનલોક થયા પછી ચેપ લાગેલી પ્રક્રિયા ચોરાયેલી એન્ક્રિપ્ટેડ ફાઇલ કરતાં જુદી સમસ્યા છે. એજન્ટને બીજા હોસ્ટ પર ફોરવર્ડ કરવાથી કી ફાઇલની નકલ કર્યા વિના પ્રમાણીકરણ ક્ષમતા સોંપાય છે, તેથી મંજૂર જરૂરિયાત માટે જ તેને સક્ષમ કરો.

ફેરફાર પહેલાં અને પછી એજન્ટ હાલમાં શું ધરાવે છે તેની યાદી બનાવો:

ssh-add -l

દેખરેખ વગરના કાર્યોને પોતાની યોજના જોઈએ

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

સમર્થિત રહસ્ય વિતરણ અથવા હાર્ડવેર-આધારિત કામગીરી માટે સેવા માલિક સાથે કામ કરો, અને નવીકરણ, નિષ્ફળતા અને પુનઃપ્રાપ્તિ આવરો. કીબોર્ડ પર માણસ જોઈએ એવી ઇચ્છા નિષ્ફળતાનો દેખાવ બદલી નાખે છે, કોઈ ન જોતું હોય તેવા હોસ્ટની સરખામણીમાં.

સર્વરની હોસ્ટ-ઓળખ ચકાસણી અને તેના એકાઉન્ટ પ્રતિબંધો પણ રાખો. VPN માર્ગ તમને ખાનગી રસ્તો આપે છે; તે સાબિત કરતું નથી કે તમે પહોંચો છો તે દરેક SSH શ્રોતા તમારો ઇચ્છિત હોસ્ટ છે. શ્રોતા અને હોસ્ટ કીની ફિંગરપ્રિન્ટ કીની જેમ જ એ જ યાદીમાં નોંધો.

સીમાઓ અલગ-અલગ ચકાસો

દરેક સીમાને તેના પોતાના પ્રશ્નથી ચકાસો. પાસફ્રેઝ વિના ફાઇલ ખૂલે છે? ડિસ્કનેક્ટ પછી પણ એજન્ટ ઓળખ રાખે છે? સર્વર હજી જાહેર કી સ્વીકારે છે?

બે આદેશો પહેલા અને ત્રીજા પ્રશ્નનો જવાબ આપે છે:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

ફાઇલ સુરક્ષા, મંજૂર કી ઉપયોગ અને સર્વર-બાજુની દૂર કરવા એ ત્રણ અલગ લાઇન તરીકે નોંધો. ટનલ, પાસફ્રેઝ અને એજન્ટ દરેક સંબંધનો જુદો ભાગ સાચવે છે, અને તેમાંથી ફક્ત એક જ નેટવર્ક વિશે છે.