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]

फाइल संरक्षण, परवानगी असलेला की वापर आणि सर्व्हर-बाजूची काढणी या तीन स्वतंत्र ओळी म्हणून नोंदवा. बोगदा, पासफ्रेझ आणि एजंट प्रत्येकजण नात्याचा वेगळा भाग राखतो, आणि त्यापैकी फक्त एक नेटवर्कबद्दल आहे.