आपके VPS के लिए Tor-आधारित प्रबंधन पथ
SSH के लिए SOCKS प्रॉक्सी का उपयोग करें, एक निजी onion एंडपॉइंट प्रकाशित करें और सार्वजनिक पहुँच बंद करने से पहले DNS, प्रमाणीकरण और रिकवरी की जाँच करें।
एक नज़र में
Tor किसी VPS तक पहुँचने के लिए उपयोग किए जाने वाले नेटवर्क पथ को बदल सकता है, और SSH onion एंडपॉइंट पारंपरिक सार्वजनिक प्रबंधन गंतव्य से बच सकता है। न तो दृष्टिकोण सर्वर को स्वतः सुरक्षित करता है। SSH कुंजियाँ सुरक्षित करें, होस्ट पहचान सत्यापित करें, पहुँच प्रतिबंधित करें और इस पर निर्भर होने से पहले कॉन्फ़िगरेशन का परीक्षण करें।
चेकआउट के साथ-साथ प्रशासन की भी रक्षा करें
संरक्षित ब्राउज़र के माध्यम से सर्वर ऑर्डर करना बाद के SSH सत्र की स्वतः रक्षा नहीं करता। सीधा लॉगिन आपके स्रोत पते को सर्वर और पथ के नेटवर्कों को उजागर कर सकता है। पहले कनेक्शन से पहले तय करें कि प्रशासन कैसे काम करेगा, जिसमें पसंदीदा मार्ग विफल होने पर आपातकालीन पहुँच भी शामिल है।
Tor गंतव्य से क्लाइंट का सीधा IP छिपा सकता है, लेकिन यह पुनः उपयोग किए गए क्रेडेंशियल, पहचान उजागर करने वाले कॉन्फ़िगरेशन डेटा या हर ट्रैफ़िक-सहसंबंध हमले का उपाय नहीं है। यह विलंबता भी जोड़ता है। उपयोगी उद्देश्य एक सुसंगत प्रबंधन पथ है जिसका व्यवहार आप समझते हैं और जाँच सकते हैं।
कार्यशील स्थानीय Tor क्लाइंट से शुरू करें
एक सिस्टम Tor डेमॉन सामान्यतः 127.0.0.1:9050 पर SOCKS प्रदान करता है, जबकि Tor Browser सामान्यतः 9150 का उपयोग करता है। किसी भी पोर्ट को मानने के बजाय अपने वास्तविक कॉन्फ़िगरेशन को सत्यापित करें। एप्लिकेशन को अपना कनेक्शन उस प्रॉक्सी के माध्यम से भेजना चाहिए; Tor Browser खोलने से कंप्यूटर के हर प्रोग्राम का मार्ग नहीं बदलता।
समर्थित सिस्टमों पर, torsocks SSH जैसे एप्लिकेशनों को लपेटता है और समर्थित नेटवर्क कॉलों को Tor के माध्यम से भेजता है। सेटअप का परीक्षण केवल-दस्तावेज़ीकरण वाले उदाहरण पते को अपने सर्वर के वास्तविक पते से बदलकर करें। निम्नलिखित कमांड एक चल रहे सिस्टम Tor डेमॉन और एक समर्पित प्रशासनिक खाते को मानती है।
torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]मार्ग को SSH कॉन्फ़िगरेशन का हिस्सा बनाएँ
नियमित उपयोग के लिए, प्रति-होस्ट कॉन्फ़िगरेशन रैपर भूलने की संभावना कम करता है। नीचे दिया गया उदाहरण SOCKS5 प्रॉक्सी समर्थन वाले netcat कार्यान्वयन का उपयोग करता है। कार्यान्वयन भिन्न होते हैं, इसलिए अपने स्थापित संस्करण में -x और -X विकल्पों की पुष्टि करें और जाँचें कि होस्टनाम रिज़ॉल्यूशन दूरस्थ है या नहीं।
IdentitiesOnly सर्वर को दी जाने वाली कुंजियों को सीमित करता है; इसे इस परियोजना के लिए इस्तेमाल की गई नई कुंजी के साथ जोड़ें। किसी विश्वसनीय provisioning चैनल के माध्यम से सर्वर की host-key fingerprint जाँचें और सुरक्षित रखें। Tor नेटवर्क पथ बदलता है, लेकिन SSH host authentication अभी भी आवश्यक है।
Host silent-admin
HostName 203.0.113.45
User admin
IdentityFile ~/.ssh/silentvps_ed25519
IdentitiesOnly yes
ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %pSSH को onion सेवा के पीछे ले जाएँ
एक onion endpoint सार्वजनिक रूप से पहुँच योग्य SSH पोर्ट के बिना प्रशासन की अनुमति देता है और इस कनेक्शन के लिए Tor exit का उपयोग करने से बचता है। सर्वर पर Tor इंस्टॉल और कॉन्फ़िगर करें, फिर एक onion वर्चुअल पोर्ट को स्थानीय SSH सेवा से मैप करें। यह उदाहरण एक शुरुआती कॉन्फ़िगरेशन है; सेवा पथ और कमांड वितरण के अनुसार भिन्न होते हैं।
Tor द्वारा सेवा निर्देशिका बनाने के बाद, उसकी hostname फ़ाइल निजी रूप से प्राप्त करें और अपने क्लाइंट प्रॉक्सी के माध्यम से कनेक्शन का परीक्षण करें। onion सेवा की identity कुंजियाँ निजी रखें। सफल स्वतंत्र लॉगिन के बाद ही SSH को localhost तक सीमित करें और सार्वजनिक पहुँच हटाएँ। यह बदलाव करने से पहले सत्यापित करें कि आपका recovery console काम करता है।
HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22निजी endpoint के लिए क्लाइंट प्राधिकरण जोड़ें
अतिरिक्त प्राधिकरण के बिना, जो भी onion पता जान लेता है वह सेवा और उसके SSH प्रॉम्प्ट तक पहुँच सकता है। Tor v3 क्लाइंट प्राधिकरण एक अलग क्रिप्टोग्राफिक द्वार जोड़ता है: सेवा के पास अधिकृत क्लाइंट की सार्वजनिक कुंजी होती है और क्लाइंट के पास मेल खाती निजी कुंजी होती है।
कुंजी प्रारूपों और authorized_clients निर्देशिका के लिए Tor Project के वर्तमान निर्देशों का पालन करें। सत्यापित करें कि अनधिकृत क्लाइंट कनेक्ट नहीं कर सकता। SSH कुंजी प्रमाणीकरण भी बनाए रखें, और योजना बनाएँ कि खोए हुए डिवाइस का प्राधिकरण अपनी शेष पहुँच खोए बिना कैसे रद्द करें।
DNS का परीक्षण करें और identity लीक से बचें
स्थानीय resolver द्वारा किया गया hostname lookup कनेक्शन के प्रॉक्सी तक पहुँचने से पहले आपके लक्ष्य को प्रकट कर सकता है। clearnet गंतव्य के लिए सर्वर IP का उपयोग करना उस विशेष lookup से बचता है; onion नामों को Tor के भीतर resolution की आवश्यकता होती है। अन्य hostnames के लिए, सामान्य प्रॉक्सी सेटिंग पर निर्भर होने के बजाय एप्लिकेशन के remote-DNS व्यवहार की पुष्टि करें।
अतिथि सिस्टम अभी भी authentication timestamps, usernames और journal entries रख सकता है। हर diagnostic को आँख मूंदकर अक्षम करने के बजाय जानबूझकर उनके प्रतिधारण की समीक्षा करें। पहचानकर्ता विवरणों के लिए स्थानीय hostnames, commit metadata और प्रतिलिपि की गई कॉन्फ़िगरेशन का भी निरीक्षण करें। Tor उन्हें एप्लिकेशन ट्रैफ़िक से नहीं हटाता।
- समर्पित कुंजी और पृथक परियोजना कार्यप्रवाह का उपयोग करें।
- अपेक्षित SOCKS पोर्ट और remote DNS व्यवहार को सत्यापित करें।
- listeners बदलने से पहले recovery पहुँच और दूसरा परीक्षित लॉगिन बनाए रखें।
- अपडेट के बाद Tor और SSH सेवा की समीक्षा करें।
- onion identity कुंजियाँ या क्लाइंट प्राधिकरण रहस्य कभी साझा न करें।
लंबे सत्र और भविष्य का रखरखाव व्यावहारिक रखें
लंबे प्रशासनिक कार्य tmux या screen के भीतर चलाएँ ताकि कनेक्शन बाधित होने पर सत्र नष्ट न हो। Tor circuits और नेटवर्क स्थितियाँ बदल सकती हैं, इसलिए कमांड को दोहराने योग्य रखें और समझें कि उन्हें कैसे फिर से शुरू करना है। जब रखरखाव की योजना बनाई जाती है तो थोड़ी अतिरिक्त latency सहना आसान होता है।
वही onion पैटर्न एक स्थानीय dashboard या निजी Git सेवा के आगे हो सकता है। प्रत्येक एप्लिकेशन को अभी भी authentication, सॉफ़्टवेयर अपडेट और सावधान कॉन्फ़िगरेशन की आवश्यकता होती है। जहाँ आपकी गोपनीयता आवश्यकताएँ माँग करें वहाँ समर्थन, नवीनीकरण और बैकअप के लिए संरक्षित मार्ग का उपयोग करना जारी रखें; निरंतरता उतनी ही मायने रखती है जितनी प्रारंभिक सेटअप।