अमूर्त: लेख में ओपनएसएसएच की उन्नत विशेषताओं का वर्णन किया गया है, जो सिस्टम प्रशासक और प्रोग्रामर के जीवन को सरल बना सकता है जो शेल से डरते नहीं हैं। अधिकांश मैनुअलों के विपरीत, जो चाबियों और -L / D / R विकल्पों के अलावा कुछ भी वर्णन नहीं करते हैं, मैंने उन सभी दिलचस्प विशेषताओं और उपयुक्तताओं को इकट्ठा करने की कोशिश की जो ssh इसके साथ वहन करती है।

चेतावनी: यह पद बहुत बड़ा है, लेकिन उपयोग में आसानी के लिए, मैंने इसे टुकड़ों में नहीं काटने का फैसला किया।

सामग्री की तालिका:

प्रमुख प्रबंधन
फ़ाइलों को ssh के माध्यम से कॉपी करें
अग्रेषण इनपुट / आउटपुट स्ट्रीम
माउंट रिमोट एफएस ssh के माध्यम से
रिमोट कोड निष्पादन
.Ssh / config में कनेक्शन के लिए उपनाम और विकल्प
डिफ़ॉल्ट विकल्प
एक्स सर्वर अग्रेषण
मोजे-प्रॉक्सी के रूप में ssh
पोर्ट अग्रेषण - आगे और पीछे
उल्टा स्वर प्रॉक्सी
टनलिंग L2 / L3 यातायात
प्रमाणीकरण एजेंट अग्रेषण
एक अविश्वसनीय सर्वर के माध्यम से ssh के माध्यम से टनलिंग ssh ( सबसे अधिक संभावना है कि आप यह नहीं जानते हैं )

प्रमुख प्रबंधन

कुछ शब्दों में सिद्धांत: ssh पासवर्ड से नहीं, बल्कि की से लॉग इन किया जा सकता है। कुंजी में एक खुला और एक बंद हिस्सा होता है। खुले वाले को उपयोगकर्ता के होम डायरेक्टरी में रखा जाता है, "जिसके द्वारा" वे सर्वर पर जाते हैं, बंद उपयोगकर्ता के होम डायरेक्टरी में रखा जाता है, जो रिमोट सर्वर पर जाता है। हिस्सों की तुलना की जाती है (मैं अतिशयोक्ति करता हूं) और अगर सब कुछ ठीक है - तो उन्होंने इसे जाने दिया। महत्वपूर्ण: न केवल सर्वर पर क्लाइंट अधिकृत है, बल्कि क्लाइंट के संबंध में सर्वर भी है (अर्थात, सर्वर की अपनी कुंजी है)। पासवर्ड की तुलना में कुंजी की मुख्य विशेषता यह है कि इसे सर्वर में तोड़कर "चोरी" नहीं किया जा सकता है - कुंजी क्लाइंट से सर्वर में स्थानांतरित नहीं होती है, और प्राधिकरण के दौरान क्लाइंट सर्वर को साबित करता है कि यह कुंजी (उसी ट्रांसक्रिप्टोग्राफिक जादू) का मालिक है।

प्रमुख पीढ़ी

आप ssh-keygen कमांड का उपयोग करके अपनी कुंजी उत्पन्न कर सकते हैं। यदि आप पैरामीटर सेट नहीं करते हैं, तो यह सब कुछ बचा लेगा जैसा कि इसे करना चाहिए।

कुंजी को पासवर्ड से लॉक किया जा सकता है। यह पासवर्ड (पारंपरिक ग्राफिकल इंटरफेस में) एक बार अनुरोध किया जाता है और कुछ समय के लिए संग्रहीत किया जाता है। यदि पासवर्ड खाली है, तो इसका उपयोग करते समय नहीं पूछा जाएगा। भूल गए पासवर्ड को रिकवर करना संभव नहीं है।

आप ssh-keygen -p कमांड का उपयोग करके कुंजी के लिए पासवर्ड बदल सकते हैं।

मुख्य संरचना

(यदि वे डिफ़ॉल्ट रूप से स्थान के बारे में प्रश्न का उत्तर देते हैं)।
~ / .ssh / id_rsa.pub - सार्वजनिक कुंजी। यह उस सर्वर पर कॉपी किया जाता है जहां आपको एक्सेस करने की आवश्यकता होती है।
~ /। ssh / id_rsa - निजी कुंजी। इसे किसी को नहीं दिखाना चाहिए। यदि आप एक संदेश / चैट में पब के बजाय इसे कॉपी और पेस्ट करते हैं, तो आपको एक नई कुंजी उत्पन्न करने की आवश्यकता है। (मैं मजाक नहीं कर रहा हूं, लगभग 10% लोग जो एक ssh कुंजी पोस्ट id_rsa देने के लिए कहते हैं, और इन दस प्रतिशत में से 100% पुरुष हैं)।

सर्वर पर कॉपी की

जिस उपयोगकर्ता निर्देशिका में आप लॉग इन करना चाहते हैं, यदि आप ~ / .sh / अधिकृत_की फ़ाइल बनाते हैं और वहां सार्वजनिक कुंजी डालते हैं, तो आप पासवर्ड के बिना दर्ज कर सकते हैं। कृपया ध्यान दें कि फ़ाइल अनुमतियों को अनधिकृत उपयोगकर्ताओं को इस फ़ाइल को लिखने की अनुमति नहीं देनी चाहिए, अन्यथा ssh इसे स्वीकार नहीं करेगा। कुंजी में, अंतिम फ़ील्ड उपयोगकर्ता @ मशीन है। इसका प्राधिकरण से कोई लेना-देना नहीं है और केवल यह निर्धारित करने की सुविधा के लिए है कि कुंजी किसकी है। ध्यान दें कि कुंजी संरचना का उल्लंघन किए बिना इस फ़ील्ड को बदला जा सकता है (या हटाया भी जा सकता है)।

यदि आप उपयोगकर्ता पासवर्ड जानते हैं, तो प्रक्रिया को सरल बनाया जा सकता है। Ssh-copy-id उपयोगकर्ता @ सर्वर कमांड आपको मैन्युअल रूप से फ़ाइलों को संपादित किए बिना एक कुंजी कॉपी करने की अनुमति देता है।

नोट: पुराने ssh मैनुअल में अधिकृत_कीs2 का उल्लेख है। कारण: ssh का पहला संस्करण था, फिर दूसरा (वर्तमान) एक, उन्होंने अपने स्वयं के विन्यास का सेट बनाया, यह सभी के लिए बहुत थका हुआ था, और दूसरे संस्करण ने बहुत पहले ही बिना किसी "2" के संस्करणों पर स्विच कर दिया था। यही है, हमेशा अधिकृत_की और विभिन्न संस्करणों के बारे में नहीं सोचना चाहिए।

यदि आपने एक गैर-मानक पोर्ट पर ssh है, तो ssh-copy-id को काम करते समय विशेष ट्रिक्स की आवश्यकता होती है: ssh-copy-id '-p 443 user@server' (उद्धरण पर ध्यान)।

सर्वर कुंजी

पहली बार जब आप सर्वर पर जाते हैं, तो ssh पूछता है कि क्या आपको कुंजी पर भरोसा है। यदि आप उत्तर नहीं देते हैं, तो कनेक्शन बंद है। यदि हां, तो कुंजी को ~ / .ssh / ज्ञात_होस्ट फ़ाइल में सहेजा जाता है। पता करें कि कौन सी कुंजी असंभव है (क्योंकि यह सुरक्षा नहीं है)।

यदि सर्वर कुंजी बदल गई है (उदाहरण के लिए, सर्वर को फिर से इंस्टॉल किया गया है), ssh एक नकली कुंजी से चिल्लाता है। कृपया ध्यान दें कि यदि आपने सर्वर को स्पर्श नहीं किया है, लेकिन ssh yells, तो आप गलत सर्वर में सेंध लगा रहे हैं (उदाहरण के लिए, समान IP वाला एक अन्य कंप्यूटर नेटवर्क पर दिखाई दिया, यह विशेष रूप से 192.1.1.1 के साथ सभी प्रकार के स्थानीय नेटवर्क के लिए सही है, जिनमें से दुनिया में कई मिलियन हैं) । "मध्यम हमले में दुर्भावनापूर्ण आदमी" का परिदृश्य संभावना नहीं है, अक्सर आईपी के साथ सिर्फ एक त्रुटि होती है, हालांकि अगर "सबकुछ ठीक है" और कुंजी बदल गई है, तो यह कुछ स्तरों द्वारा व्यामोह के स्तर को बढ़ाने के लिए एक अवसर है (और यदि आप कुंजी द्वारा प्राधिकरण करते हैं और सर्वर ने अचानक पासवर्ड के लिए पूछा है - फिर व्यामोह को 100% पर चालू किया जा सकता है और पासवर्ड दर्ज नहीं किया जाना चाहिए)।

ज्ञात सर्वर कुंजी को हटाने के लिए, ssh-keygen -R सर्वर कमांड का उपयोग करें। इस स्थिति में, आपको आईपी कुंजी को हटाना होगा (वे अलग से संग्रहीत हैं): ssh-keygen -R 127.0.0.1 ।

सर्वर कुंजी / etc / ssh / ssh_host_rsa_key और /etc/ssh/ssh_host_rsa_key.pub में संग्रहीत होती है । वे हो सकते हैं:
a) नए सर्वर से पुराने सर्वर से कॉपी करें।
ख) ssh-keygen का उपयोग कर उत्पन्न करते हैं। आपको एक पासवर्ड (यानी, खाली) सेट करने की आवश्यकता नहीं है। Ssh सर्वर पासवर्ड की का उपयोग नहीं कर पाएगा।

ध्यान दें कि यदि आप किसी सर्वर (उदाहरण के लिए, वर्चुअल मशीनों में) को क्लोन कर रहे हैं, तो सर्वर की ssh-keys को फिर से बनाया जाना चाहिए।

यह जानने के लिए बेहतर है कि पुरानी कुंजियों को know_hosts से हटा दें, अन्यथा ssh डुप्लिकेट कुंजी पर शपथ लेगा।

फ़ाइलों की प्रतिलिपि बनाएँ

सर्वर पर फ़ाइलों को स्थानांतरित करना कभी-कभी थकाऊ हो सकता है। Sftp और अन्य अजीब चीजों के साथ उपद्रव करने के अलावा, ssh हमें एक scp कमांड प्रदान करता है, जो किसी sf सत्र के माध्यम से फाइल कॉपी करता है।

scp path/myfile user@8.8.8.8:/full/path/to/new/location/

रिवर्स भी संभव है:

scp user@8.8.8.8:/full/path/to/file /path/to/put/here

मछली की चेतावनी: इस तथ्य के बावजूद कि एमसी ssh कनेक्शन कर सकता है, बड़ी फ़ाइलों की प्रतिलिपि बनाना बहुत दर्दनाक होगा, क्योंकि मछली (वर्चुअल fs के साथ ssh के साथ काम करने के लिए mc मॉड्यूल) बहुत धीमी है। 100-200kb - सीमा, फिर धैर्य की परीक्षा शुरू होती है। (मुझे अपने बहुत ही कम उम्र के युवा याद थे, जब scp के बारे में पता नहीं था, मैंने ~ 5GB मछली के माध्यम से mc में कॉपी किया, इसे FastEiber पर 12 घंटे से थोड़ा अधिक समय लगा)।

नकल करने की क्षमता महान है। लेकिन मैं "के रूप में सहेजना चाहता हूं" - और तुरंत सर्वर पर। और ग्राफिकल मोड में कॉपी करने के लिए एक विशेष कार्यक्रम से नहीं, बल्कि किसी भी परिचित से।

तो आप कर सकते हैं:

sshfs

थ्योरी: फ्यूज मॉड्यूल आपको कर्नेल से यूजरस्पेस तक संबंधित प्रोग्राम में फाइल सिस्टम के लिए "निर्यात" करने की अनुमति देता है। इससे "छद्म फाइल सिस्टम" को लागू करना आसान हो जाता है। उदाहरण के लिए, हम ssh के माध्यम से दूरस्थ फाइल सिस्टम तक पहुंच प्रदान कर सकते हैं ताकि सभी स्थानीय एप्लिकेशन (कुछ अपवादों के साथ) कुछ भी संदेह न करें।

वास्तव में, एक अपवाद: O_DIRECT समर्थित नहीं है, अफसोस (यह sshfs समस्या नहीं है, यह सामान्य रूप से एक फ्यूज समस्या है)।

उपयोग: sshfs पैकेज स्थापित करें (यह स्वयं फ्यूज हो जाएगा)।

वास्तव में, मेरी स्क्रिप्ट का एक उदाहरण जो desunote.ru (मेरे होम कंप्यूटर पर स्थित है - चित्र इस आलेख में इसे से दिखाया गया है) को मेरे लैपटॉप पर दिखाता है:

 #! / बिन / बैश
 sshfs desunote.ru:/var/www/desunote.ru//media/desunote.ru -o

हम फ़ाइल + x बनाते हैं, इसे कॉल करते हैं, किसी भी एप्लिकेशन पर जाते हैं, कहते हैं कि सहेजें और देखें:

Sshfs विकल्प जो महत्वपूर्ण हो सकते हैं: -o पुन: कनेक्ट करें (त्रुटियों के बजाय पुन: कनेक्ट करने का प्रयास करें)।

यदि आप रूट से डेटा के साथ बहुत काम करते हैं, तो आप एक आईडीमैप (आवश्यकता) कर सकते हैं:

-ओ आईडीमैप = उपयोगकर्ता । यह निम्नानुसार काम करता है: यदि हम एक pupkin @ सर्वर उपयोगकर्ता के रूप में कनेक्ट करते हैं, और स्थानीय रूप से एक वैसिली उपयोगकर्ता के रूप में काम करते हैं, तो हम कहते हैं "मान लें कि पुतकिन फाइलें वैसिली फाइलें हैं।" अच्छी तरह से, या "जड़" अगर हम जड़ के रूप में कनेक्ट करते हैं।

मेरे मामले में, आईडीमैप की आवश्यकता नहीं है, क्योंकि उपयोगकर्ता नाम (स्थानीय और दूरस्थ) समान हैं।

ध्यान दें, यह केवल तभी काम करने के लिए आरामदायक है जब हमारे पास एक ssh-key (लेख की शुरुआत देखें), यदि नहीं, तो पासवर्ड प्राधिकरण 2-3 कनेक्शन को धकेलता है।

आप इसे वापस fusermount -u / path कमांड से डिस्कनेक्ट कर सकते हैं, हालांकि, यदि कनेक्शन चिपचिपा है (उदाहरण के लिए, कोई नेटवर्क नहीं है), तो आप रूट के नीचे से ऐसा करने की आवश्यकता कर सकते हैं: sudo umount -f / path।

रिमोट कोड निष्पादन

ssh रिमोट सर्वर पर कमांड निष्पादित कर सकता है और कनेक्शन को वहीं बंद कर सकता है। सबसे सरल उदाहरण:

ssh user@server ls /etc/

यह सर्वर पर / etc / की सामग्री को प्रदर्शित करेगा, और हमारे पास एक स्थानीय कमांड लाइन होगी।

कुछ एप्लिकेशन एक नियंत्रण टर्मिनल रखना चाहते हैं। उन्हें -t विकल्प के साथ चलाया जाना चाहिए:

ssh user@server -t remove_command

वैसे, हम इस तरह का कुछ कर सकते हैं:

ssh user@server cat /some/file|awk '{print $2}' |local_app

यह हमें निम्नलिखित सुविधा के लिए लाता है:

फॉरवर्ड स्टडिन / आउट

मान लें कि हम किसी प्रोग्राम को दूरस्थ रूप से अनुरोध करना चाहते हैं, और फिर उसका आउटपुट स्थानीय फ़ाइल में रखें

ssh user@8.8.8.8 कमांड> my_file

मान लीजिए कि हम स्थानीय आउटपुट को दूरस्थ रूप से रखना चाहते हैं

mycommand | scp - user@8.8.8.8: / path / Remote_file

उदाहरण को जटिल करते हैं - हम सर्वर से सर्वर पर फाइलें अपलोड कर सकते हैं: हम 10.1.1.2 पर स्टड लगाने के लिए एक श्रृंखला बनाते हैं, जो बाहर से हमारे लिए सुलभ नहीं है:

mycommand | ssh user@8.8.8.8 "scp - user@10.1.1.2: / path / to / file"

पाइप'ए (कृपया लाइवजर्नल में टिप्पणियों में सुझाए गए) का उपयोग करने के लिए इस तरह की एक अजीब चाल है।)

tar -c * | ssh user@server "cd && tar -x"

तार स्थानीय रूप से मुखौटा द्वारा फाइलें पैक करता है, उन्हें stdout को लिखता है, जहां से ssh उन्हें पढ़ता है, उन्हें दूरस्थ सर्वर पर स्टड पास करता है, जहां cd उन्हें अनदेखा करता है (स्टड नहीं पढ़ता है), और टार पढ़ता है और उन्हें अनपैक करता है। तो बोलने के लिए, scp गरीबों के लिए है।

उपनाम

सच कहूँ तो, हाल ही में जब तक मैं नहीं जानता था और इसका इस्तेमाल नहीं किया था। वे बहुत सहज निकले।

अधिक या कम बड़ी कंपनी में, यह अक्सर पता चलता है कि सर्वर नाम इस तरह दिखते हैं: spb-MX-i3.extrt.int.company.net। और वहां का उपयोगकर्ता स्थानीय के बराबर नहीं है। अर्थात्, आपको निम्नानुसार लॉग इन करना होगा: ssh ivanov_i@spb-MX-i3.extrt.int.company.net। हर बार जब आप टाइप करते हैं - तो आपको पर्याप्त सुरंग सिंड्रोम नहीं मिलते हैं। छोटी कंपनियों में, समस्या विपरीत है - कोई भी डीएनएस के बारे में नहीं सोचता है, और सर्वर तक पहुंच इस तरह दिखती है: ssh root@192.168.1.4। संक्षेप में, लेकिन अभी भी कष्टप्रद है। इससे भी अधिक नाटक, अगर हमारे पास एक गैर-मानक पोर्ट है, और, उदाहरण के लिए, एसएचएस का पहला संस्करण (हेलो टूस्किस्क)। तब सब कुछ इस तरह दिखता है: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net। पर चोक। मैं स्‍कैप के साथ नाटक के बारे में भी बात नहीं करना चाहता।

आईपी (/ etc / मेजबान) के लिए सिस्टम-वाइड उपनाम को पंजीकृत करना संभव है, लेकिन यह एक कुटिल आउटपुट है (और उपयोगकर्ता और विकल्प वैसे भी मुद्रित होते हैं)। एक छोटा रास्ता है।

~ / .Ssh / config फ़ाइल आपको सर्वर-विशिष्ट वाले सहित कनेक्शन पैरामीटर सेट करने की अनुमति देती है, जो सबसे महत्वपूर्ण है, प्रत्येक सर्वर के लिए एक अलग है। यहाँ एक उदाहरण विन्यास है:

 मेजबान रिक
         होस्टनाम ऊह-सींग और खुर
         उपयोगकर्ता व्यवस्थापक
         फॉरवर्डएक्स 11 हां
         संपीड़न हाँ
 मेजबान घर
         होस्टनाम myhome.dyndns.org
         उपयोगकर्ता वास्य
         PasswordAuthentication सं

उपयोग के लिए उपलब्ध सभी विकल्प आदमी ssh_config (sshd_config के साथ भ्रमित नहीं होना) में देखे जा सकते हैं।

डिफ़ॉल्ट विकल्प

UUSER प्रॉम्प्ट पर: आप होस्ट कनेक्शन का उपयोग करके डिफ़ॉल्ट कनेक्शन सेटिंग्स को निर्दिष्ट कर सकते हैं, अर्थात, उदाहरण के लिए:

 होस्ट *
 उपयोगकर्ता रूट
 संपीड़न हाँ

वही / etc / ssh / ssh_config में किया जा सकता है (/ / ssh / ssh d_config के साथ भ्रमित नहीं होना चाहिए), लेकिन इसके लिए मूल अधिकारों की आवश्यकता होती है और सभी उपयोगकर्ताओं पर लागू होती है।

एक्स सर्वर अग्रेषण

दरअसल, थोड़ा सा मैंने इस हिस्से को ऊपर दिए गए उदाहरण के विन्यास में सेट किया है। फॉरवर्डएक्स 11 सिर्फ इतना है।

सिद्धांत: यूनिक्स ग्राफिक्स अनुप्रयोग आमतौर पर एक्स सर्वर का उपयोग करते हैं (वेलैंड रास्ते में है, लेकिन अभी भी तैयार नहीं है)। इसका मतलब है कि एप्लिकेशन शुरू होता है और ड्राइंग के लिए एक्स सर्वर से कनेक्ट होता है। दूसरे शब्दों में, अगर आपके पास बिना नंगे सर्वर है और आपके पास स्थानीय एक्स-सर्वर (जहां आप काम करते हैं) है, तो आप अपने डेस्कटॉप पर ड्रॉ करने के लिए सर्वर से एप्लिकेशन को सक्षम कर सकते हैं। आमतौर पर एक दूरस्थ एक्स सर्वर से कनेक्ट करना सबसे सुरक्षित और सबसे तुच्छ चीज नहीं है। SSH इस प्रक्रिया को सरल करता है और इसे पूरी तरह से सुरक्षित बनाता है। और ट्रैफ़िक को फिर से भरने की क्षमता आपको कम ट्रैफ़िक के साथ करने की अनुमति देती है (यानी चैनल का उपयोग कम करें, यानी पिंग को कम करें (अधिक सटीक, विलंबता), यानी, लैग्स को कम करें)।

कुंजियाँ: -X - X- सर्वर को अग्रेषित करना। -वे प्राधिकार को अग्रेषित कर रहे हैं।

बस ssh -XYC उपयोगकर्ता @ सर्वर संयोजन याद रखें।
ऊपर दिए गए उदाहरण में (कंपनी के नाम काल्पनिक हैं) मैं सर्वर ऊह-हॉर्न-एंड-हॉफसेर्फ से कनेक्ट करता हूं, न केवल उस तरह से, बल्कि विंडोज़ सर्वर तक पहुंच प्राप्त करने के लक्ष्य के साथ। हम सभी नेटवर्क पर काम करते समय Microsoft की सुरक्षा जानते हैं , इसलिए नग्न RDP को बाहर रखना असुविधाजनक है। इसके बजाय, हम ssh के माध्यम से सर्वर से कनेक्ट करते हैं, और फिर वहां rdesktop कमांड चलाते हैं:

ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200

और एक चमत्कार, हमारे डेस्कटॉप पर खिड़कियों में लॉगिन विंडो। ध्यान से एन्क्रिप्टेड और नियमित रूप से ssh यातायात से अप्रभेद्य।

प्रॉक्सी को सॉक्स करता है

जब मैं खुद को अगले होटल (कैफे, सम्मेलन) में पाता हूं, तो स्थानीय वाईफाई अक्सर भयानक - बंद बंदरगाहों के रूप में बदल जाता है, यह पता नहीं है कि सुरक्षा का स्तर क्या है। हां, और अन्य लोगों के पहुंच बिंदुओं पर भरोसा बहुत ज्यादा नहीं है (यह व्यामोह नहीं है, मैंने यह देखा कि कैसे पासवर्ड और कुकीज़ को एक केला लैपटॉप का उपयोग करके हटा दिया जाता है जो पास के एक कैफे के नाम से सभी को 3 जी वितरित करता है (और प्रक्रिया में दिलचस्प बातें लिखता है))।

बंद पोर्ट विशेष समस्याओं का कारण बनते हैं। या तो जैबर कवर किया जाएगा, फिर IMAP, फिर कुछ और।

एक नियमित वीपीएन (पीपीपीपी, एल 2 टीपी, ओपनवीपीएन) ऐसी स्थितियों में काम नहीं करता है - यह बस से नहीं गुजरता है। यह प्रायोगिक रूप से ज्ञात है कि 443 वाँ पोर्ट सबसे अधिक बार छोड़ा जाता है, इसके अलावा, CONNECT मोड में, अर्थात, उन्हें "जैसा है" पास किया जाता है (नियमित http अभी भी पारदर्शी रूप से स्क्वीड पर लपेटा जा सकता है)।

समाधान मोज़े-प्रॉक्सी ssh मोड है। इसका सिद्धांत: ssh क्लाइंट सर्वर से जुड़ता है और स्थानीय रूप से सुनता है। अनुरोध प्राप्त करने के बाद, यह इसे (एक खुले कनेक्शन के माध्यम से) सर्वर पर भेजता है, सर्वर अनुरोध के अनुसार एक कनेक्शन स्थापित करता है और सभी डेटा को वापस ssh क्लाइंट में स्थानांतरित करता है। और वह आवेदक को जवाब देता है। काम करने के लिए, आपको "मोज़े-प्रॉक्सी का उपयोग" करने के लिए अनुप्रयोगों को बताने की आवश्यकता है। और प्रॉक्सी का आईपी पता निर्दिष्ट करें। Ssh के मामले में, यह सबसे अधिक बार लोकलहोस्ट है (इसलिए आप अजनबियों को अपना चैनल नहीं देंगे)।

एक शॉक-प्रॉक्सी कनेक्शन इस तरह दिखता है:

 ssh -D 8080 उपयोगकर्ता @ सर्वर

इस तथ्य के कारण कि अन्य लोगों की वाईफ़ाई अक्सर न केवल अंजीर होती है, बल्कि सुस्त भी होती है, यह -सी विकल्प (ट्रैफ़िक ट्रैफ़िक) को सक्षम करने के लिए अच्छा हो सकता है। यह लगभग ओपेरा टर्बो (केवल चित्र नहीं दबाता है) निकलता है। Http पर वास्तविक सर्फिंग में यह लगभग 2-3 बार क्लिक करता है (पढ़ें - यदि आपके पास 64kbit आपदा है, तो आप 40 मिनट में, लेकिन 40 सेकंड में मेगाबाइट पेज नहीं खोलेंगे। यह अच्छा है, लेकिन सब कुछ बेहतर है)। लेकिन सबसे महत्वपूर्ण बात: कोई चुराया हुआ कुकीज़ और अनसुना सत्र नहीं।

बंद किए गए बंदरगाहों के बारे में मैंने कुछ नहीं कहा। 22 वां पोर्ट ठीक उसी तरह बंद है जैसा कि जैबर के "अनावश्यक" पोर्ट से होता है। समाधान सर्वर को पोर्ट 443 पर लटका देना है। यह 22 से तस्वीरें लेने के लायक नहीं है, कभी-कभी डीपीआई (गहरे पैकेट निरीक्षण) के साथ सिस्टम होते हैं जो आपके "छद्म-एसएसएल" को जाने नहीं देंगे।

यह मेरे विन्यास जैसा दिखता है:

/ etc / ssh / sshd_config:
(टुकड़ा)
पोर्ट 22
पोर्ट 443

और यहाँ एक लैपटॉप से ~ / .ssh / config का एक टुकड़ा है जो vpn का वर्णन करता है

 मेजबान vpn
     होस्टनाम desunote.ru
     उपयोगकर्ता वास्य
     संपीड़न हाँ
     डायनामॉर्फवर्ड 127.1: 8080
     पोर्ट 443

(लोकलहोस्ट - 127.1 लिखने के "आलसी" रूप पर ध्यान दें, यह 127.0.0.1 लिखने का एक वैध तरीका है।)

पोर्ट अग्रेषण

हम SSH कार्यक्षमता के हिस्से को समझने में बेहद मुश्किल हैं, जो "सर्वर से" और "सर्वर" से टीसीपी सुरंग संचालन को रोकने की अनुमति देता है।

स्थिति को समझने के लिए, नीचे दिए गए सभी उदाहरण इस आरेख का उल्लेख करेंगे:

टिप्पणियाँ: दो ग्रे नेटवर्क। पहला नेटवर्क एक विशिष्ट कार्यालय नेटवर्क (NAT) जैसा दिखता है, दूसरा एक प्रवेश द्वार है, जो एक सफेद इंटरफ़ेस वाला एक सर्वर है और एक ग्रे अपने निजी नेटवर्क को देखता है। आगे के विचारों में, हम मानते हैं कि "हमारा" लैपटॉप ए है, और "सर्वर" बी है।

कार्य : हमारे पास स्थानीय रूप से चल रहा एप्लिकेशन है, हमें एक अन्य उपयोगकर्ता को उसे देखने के लिए अवसर (हमारे नेटवर्क के बाहर) देने की आवश्यकता है।

समाधान: स्थानीय पोर्ट (127.0.0.1:80) को सार्वजनिक रूप से सुलभ पते पर अग्रेषित करें। मान लीजिए हमारे "सार्वजनिक रूप से उपलब्ध" बी ने कुछ उपयोगी के साथ पोर्ट 80 लिया, इसलिए हम इसे गैर-मानक पोर्ट (8080) पर भेज देंगे।

अंतिम विन्यास: 8.8.8.8:8080 के लिए अनुरोध लैपटॉप ए के लोकलहोस्ट पर जाएगा।

ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8

-R विकल्प आपको अपने दूरस्थ ( R emote) सर्वर से आपके (स्थानीय) पोर्ट पर एक पोर्ट पुनर्निर्देशित करने की अनुमति देता है।
महत्वपूर्ण: यदि हम पते का उपयोग 8.8.8.8 करना चाहते हैं, तो हमें सर्वर सेटिंग्स बी में गेटवेपोर्ट को सक्षम करना होगा।
चुनौती । सर्वर "बी" पर, एक निश्चित डेमॉन सुन रहा है (उदाहरण के लिए, एक एसक्यूएल सर्वर)। हमारा आवेदन सर्वर (अन्य बिट्स, ओएस, बुराई व्यवस्थापक, प्रतिबंध और सीमाएं, आदि को लागू करने) के साथ संगत नहीं है। हम स्थानीय रूप से दूरस्थ लोकलहोस्ट का उपयोग करना चाहते हैं।

अंतिम कॉन्फ़िगरेशन: लोकलहोस्ट के लिए अनुरोध: 'ए' पर 3333 को लोकलहोस्ट: 3128 'बी' पर डेमन द्वारा सेवा दी जानी चाहिए।

ssh -L 127.1:3333:127.1:3128 user@8.8.8.8

-L विकल्प स्थानीय कॉल ( L ocal) को दूरस्थ सर्वर पर निर्देशित करने की अनुमति देता है।

कार्य : सर्वर "बी" पर, एक ग्रे इंटरफ़ेस पर, एक निश्चित सेवा सुन रही है और हम इस एप्लिकेशन को देखने के लिए एक सहयोगी (192.168.0.3) को सक्षम करना चाहते हैं।

अंतिम कॉन्फ़िगरेशन: हमारे ग्रे आईपी पते (192.168.0.2) का अनुरोध सर्वर बी के ग्रे इंटरफेस से मिलता है।

ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8

घोंसला सुरंगों

बेशक, सुरंगों को पुनर्निर्देशित किया जा सकता है।

आइए कार्य को जटिल करते हैं: अब हम एक सहयोगी को 10.1.1.2 (पोर्ट 80 पर) पते के साथ एक सर्वर पर लोकलहोस्ट पर चलने वाले एप्लिकेशन को दिखाना चाहते हैं।

समाधान मुश्किल है:

ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2

क्या चल रहा है? हम ssh को हमारे पते से सर्वर B के लोकलहोस्ट पर पुनर्निर्देशित करने और सर्वर s पर स्टार्ट ssh (यानी ssh क्लाइंट) जोड़ने के तुरंत बाद लोकलहोस्ट को सुनने के विकल्प के साथ और सर्वर 10.1.1.2 (जहां क्लाइंट कनेक्ट होना चाहिए) को रिक्वेस्ट भेजने के लिए कहते हैं। पोर्ट 9999 को मनमाने ढंग से चुना जाता है, मुख्य बात यह है कि यह पहली कॉल में और दूसरे में मेल खाता है।

उल्टा स्वर प्रॉक्सी

यदि पिछला उदाहरण आपको सरल और स्पष्ट लगा, तो यह अनुमान लगाने का प्रयास करें कि यह उदाहरण क्या करेगा:

ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2

यदि आप एक सुरक्षा अधिकारी हैं जिसका कार्य 10.1.1.2 सर्वर पर इंटरनेट के उपयोग को प्रतिबंधित करना है, तो आप पोप पर बालों को बाहर निकालना शुरू कर सकते हैं, क्योंकि यह कमांड कंप्यूटर के लिए चलने वाले प्रॉक्सी प्रॉक्सी के माध्यम से सर्वर 10.1.1.2 के लिए इंटरनेट एक्सेस का आयोजन करता है। ट्रैफ़िक पूरी तरह से एन्क्रिप्टेड है और किसी अन्य एसएसएच ट्रैफ़िक से अप्रभेद्य है। और नेटवर्क "192.168.0 / 24" के दृष्टिकोण से कंप्यूटर से आउटगोइंग ट्रैफ़िक कंप्यूटर ए के सामान्य ट्रैफ़िक से अलग नहीं है।

सुरंग

यदि इस बिंदु पर सुरक्षा विभाग के पुजारी गंजे नहीं चमकते हैं, और ssh को अभी भी नंबर एक सुरक्षा दुश्मन के रूप में सूचीबद्ध नहीं किया गया है, तो यहां हर चीज और हर चीज का अंतिम हत्यारा है: आईपी टनलिंग या यहां तक कि ईथरनेट। सबसे कट्टरपंथी मामलों में, यह आपको dhcp को सुरंग करने की अनुमति देता है, दूरदराज के एआरपी स्पूफिंग में संलग्न होता है, लेन और दूसरे स्तर के अन्य अपमानों पर जागता है।

अधिक विवरण यहां वर्णित हैं: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html

(मैं खुद, अफसोस, इसका इस्तेमाल नहीं किया)।

यह समझना आसान है कि ऐसी परिस्थितियों में किसी भी डीपीआई (गहरे पैकेट निरीक्षण) द्वारा ऐसी सुरंगों को पकड़ना असंभव है - या तो एसएच की अनुमति है (पढ़ें - आप क्या चाहते हैं) या ssh निषिद्ध है (और आप मामूली अफसोस महसूस किए बिना सुरक्षित रूप से बेवकूफ छोड़ सकते हैं)।

प्राधिकरण आगे

यदि आपको लगता है कि यह सब है, तो ....... हालांकि, लेखक के विपरीत, जो अभी तक "नीचे" नहीं लिखा गया है, पाठक पहले से देखता है कि नीचे बहुत सारे पत्र और साज़िश हैं।

ओपनएसएसएच आपको सर्वर को अन्य सर्वर से कनेक्ट करने के लिए एक ब्रिजहेड के रूप में उपयोग करने की अनुमति देता है, भले ही ये सर्वर अविश्वसनीय हों और वे जो चाहें दुरुपयोग कर सकते हैं।

एक साधारण प्राधिकरण अग्रेषण के साथ शुरू करने के लिए।

मैं तस्वीर दोहराता हूं:

मान लीजिए हम एक सर्वर 10.1.1.2 से कनेक्ट करना चाहते हैं, जो हमारी कुंजी को स्वीकार करने के लिए तैयार है। लेकिन हम इसे 8.8.8.8 पर कॉपी नहीं करना चाहते हैं, क्योंकि वहां प्रवेश द्वार और आधे लोगों के पास सूडो हैं और इसे अन्य लोगों की निर्देशिकाओं के माध्यम से अफवाह माना जा सकता है। एक समझौता विकल्प एक "अलग" ssh कुंजी रखना होगा जो user@8.8.8.8 से 10.1.1.2 तक अधिकृत होगी, लेकिन अगर हम 8.8.8.8 से 10.1.1.2 तक किसी को भी नहीं देना चाहते हैं, तो यह कोई विकल्प नहीं है (सभी और अधिक,) कि चाबी न केवल poyuzat हो सकता है, बल्कि खुद को "एक बरसात के दिन के लिए" भी कॉपी कर सकता है)।

ssh एक ssh एजेंट को अग्रेषित करने की क्षमता प्रदान करता है (यह एक सेवा है जो एक कुंजी के लिए एक पासवर्ड का अनुरोध करता है)। Ssh -A विकल्प दूरस्थ सर्वर के लिए आगे की ओर प्रमाणीकरण है।

कॉल इस तरह दिखता है:

ssh -A user@8.8.8.8 ssh user2@10.1.1.2

दूरस्थ ssh क्लाइंट (8.8.8.8 पर) 10.1.1.2 साबित कर सकता है कि हम केवल तभी हैं जब हम इस सर्वर से जुड़े हों और अपने क्लाइंट को हमारे प्राधिकरण एजेंट तक पहुँच प्रदान करें (लेकिन कुंजी नहीं!)।

ज्यादातर मामलों में, यह रोल करता है।

हालांकि, यदि सर्वर पूरी तरह से खराब है, तो रूट सर्वर सॉकेट का उपयोग कर सकता है जब हम जुड़े हुए हैं तो अवैयक्तिकरण के लिए।

एक और भी अधिक शक्तिशाली तरीका है - यह ssh को एक साधारण पाइप ("पाइप" के अर्थ में) में बदल देता है, जिसके माध्यम से हम रिमोट सर्वर के माध्यम से काम करते हैं।

इस विधि का मुख्य लाभ मध्यवर्ती सर्वर के प्रॉक्सी से पूर्ण स्वतंत्रता है। वह एक नकली ssh सर्वर का उपयोग कर सकता है, सभी बाइट्स और सभी क्रियाओं को लॉग इन कर सकता है, किसी भी डेटा को इंटरसेप्ट कर सकता है और उसे फोर्ज कर सकता है जैसे वह चाहता है - इंटरैक्शन "अंतिम" सर्वर और क्लाइंट के बीच जाता है। यदि टर्मिनल सर्वर का डेटा गलत है, तो हस्ताक्षर नहीं होगा। यदि डेटा के साथ छेड़छाड़ नहीं की जाती है, तो सत्र को संरक्षित मोड में सेट किया गया है, इसलिए अवरोधन करने के लिए कुछ भी नहीं है।

मैं इस शांत सेटिंग को नहीं जानता था, और इसके रिडरम्पेज को खोद दिया था ।

कॉन्फ़िगरेशन ssh की दो संभावनाओं से बंधा है: -W विकल्प (जो ssh को "पाइप" में बदल देता है) और ProxyCommand config विकल्प (कमांड लाइन विकल्प, ऐसा लगता है, नहीं), जो कहता है कि "प्रोग्राम को चलाएं और इसके स्टड / आउट से चिपके रहें"। ये विकल्प हाल ही में सामने आए हैं, इसलिए सेंटोस उपयोगकर्ता उड़ान में हैं।

यह इस तरह दिखता है (ऊपर चित्र के लिए आंकड़े):

.ssh / config:

 मेज़बान रप
      होस्टनाम 10.1.1.2
      उपयोगकर्ता user2
      ProxyCommand ssh -W% h:% p user@8.8.8.8

खैर, कनेक्शन तुच्छ है: ssh raep ।

मैं एक महत्वपूर्ण विचार दोहराता हूं: सर्वर 8.8.8.8 ट्रैफ़िक को रोक नहीं सकता है, न ही उपयोगकर्ता प्राधिकरण एजेंट का उपयोग कर सकता है, या अन्यथा ट्रैफ़िक को बदल सकता है। इनकार - हाँ, यह कर सकते हैं। लेकिन अगर अनुमति दी जाती है, तो यह डिक्रिप्शन या संशोधन के बिना खुद ही गुजर जाएगा। काम करने के लिए कॉन्फ़िगरेशन के लिए, आपको user_8.8.8.8 और user2@10.1.1.2 दोनों के लिए अधिकृत_की में अपनी सार्वजनिक कुंजी रखने की आवश्यकता है।

बेशक, कनेक्शन अन्य सभी baubles से लैस किया जा सकता है - पोर्ट फ़ॉरवर्डिंग, फ़ाइलिंग , मोज़े परदे के पीछे, L2 सुरंग, सुरंग खोदने। एक्स सर्वर, आदि।

अन्त

बेशक, सुरंगों के बारे में पोस्ट में एक सुरंग होनी चाहिए, और किसी भी सफल लेख में - सार्वभौमिक लोकप्रियता का गुप्त घटक। रखें:

उपयोगकर्ताओं को ssh मेमो