नाव
sshd - OpenSSH SSH डिमन
सारांश
sshd [- deiqtD46 ] [- b bits ] [- f config_file ] [- g login_grace_time ] [- h host_key_file ] [- k key_gen_time ] [- o पर्याय ] [- पी पोर्ट ] [- यू लेन ]
वर्णन
sshd (SSH डिमन) ssh करीता डिमन प्रोग्राम आहे (1). हे कार्यक्रम rlogin ला बदलतात व rsh करीता , व असुरक्षित नेटवर्कवर दोन अविश्वासर्ह होस्टस् अंतर्गत सुरक्षित एनक्रिप्टेड संप्रेजणे पुरवते. प्रोग्राम शक्य तितके सोपे स्थापित आणि वापरासाठी आहेत.
sshd डिमन आहे जे क्लाएंटस्पासून जोडणीकरिता ऐकते. हे सहसा / etc / rc पासून बूट झाले आहे प्रत्येक येणाऱ्या जोडणीसाठी नवीन डिमन सेट केले जाते. फोर्क डीमन्स कि मुद्रा विनिमय, एन्क्रिप्शन, प्रमाणीकरण, कमांड एक्झिक्यूशन आणि डेटा एक्स्चेंज हाताळतात. हे sshd लागू करणे दोन्ही SSH प्रोटोकॉल आवृत्ती 1 आणि 2 एकाचवेळी समर्थन करते.
एसएसएच प्रोटोकॉल आवृत्ती 1
यजमानास ओळखण्यासाठी प्रत्येक होस्टमध्ये एक होस्ट-विशिष्ट RSA की (सामान्यतः 1024 बिट्स) वापरली जाते. याव्यतिरिक्त, जेव्हा डीमन सुरू होते, तेव्हा ते एक सर्व्हर RSA की (सामान्यतः 768 बिट्स) व्युत्पन्न करते ही किल्ली सामान्यतः प्रत्येक तास पुन: निर्माण केली जाते जर ती वापरली असेल आणि डिस्कवर संग्रहित केली नसेल.
जेव्हा कधी क्लायंट कनेक्ट करतो तेव्हा डीमन त्याच्या सार्वजनिक होस्ट आणि सर्व्हर कळासह प्रतिसाद देते क्लायंट त्याच्या स्वतःच्या डेटाबेस विरूद्ध आरएसए होस्ट की तुलना करतो की हे बदलले नाही. क्लायंट नंतर 256-बीट रँडम नंबर व्युत्पन्न करते. हे ही यादृच्छिक संख्या दोन्ही होस्ट की आणि सर्व्हर की वापरून ऍन्क्रिप्ट करते आणि एन्क्रिप्टेड नंबर सर्व्हरवर पाठवते. दोन्ही बाजू मग या यादृच्छिक संख्यास सत्र की म्हणून वापरतात जे सत्रामध्ये सर्व संप्रेषणे एनक्रिप्ट करण्यासाठी वापरले जाते. उर्वरित सत्र परंपरागत सायफर वापरून एनक्रिप्ट केले जाते, सध्या ब्लॉफिश किंवा 3DES, जी डीफॉल्टनुसार वापरली जात आहे. क्लायंट सर्व्हरद्वारे ऑफर केलेल्या वापरकर्त्यांकडून एनक्रिप्शन अल्गोरिदम निवडतात.
पुढे, सर्व्हर आणि क्लायंट प्रमाणीकरण संवाद प्रविष्ट करतात. क्लायंट .rhosts प्रमाणीकरण वापरून स्वतः प्रमाणित करण्याचा प्रयत्न करते, .rhosts प्रमाणीकरण RSA होस्ट प्रमाणीकरणासह, RSA आव्हान-प्रतिसाद प्रमाणीकरण, किंवा संकेतशब्द-आधारित प्रमाणीकरण .
Rhosts प्रमाणीकरण सामान्यतः अक्षम आहे कारण हे मुळतः असुरक्षित आहे, परंतु इच्छित असल्यास सर्व्हर कॉन्फिगरेशन फाईलमध्ये सक्षम केले जाऊ शकते. Rshd rlogind आणि rexecd अक्षम होत नसल्यास सिस्टम सुरक्षा सुधारली जात नाही (अशा प्रकारे मशीनमध्ये rlogin आणि rsh पूर्णपणे अक्षम करणे).
SSH प्रोटोकॉल आवृत्ती 2
आवृत्ती 2 समानरित्या कार्य करते: प्रत्येक होस्टमध्ये होस्ट-विशिष्ट की (आरएसए किंवा डीएसए) होस्टची ओळखण्यासाठी वापरली जाते. तथापि, जेव्हा डीमन प्रारंभ होते, तेव्हा तो सर्व्हर की व्युत्पन्न करत नाही. डिफी-हेल्मन की कराराद्वारे पुढील सुरक्षा प्रदान केली जाते. शेअर्स सेशन सत्रात हे कळ करार परिणाम
उर्वरित सत्र एक सिमेट्रिक सायफर वापरून एनक्रिप्ट केले आहे, सध्या 128 बिट एईएस, ब्लॉफिश, 3DES, CAST128, आर्कफोर, 1 9 2 बिट एईएस, किंवा 256 बिट एईएस. क्लायंट सर्व्हरद्वारे ऑफर केलेल्या वापरकर्त्यांकडून एनक्रिप्शन अल्गोरिदम निवडतात. याव्यतिरिक्त, सत्र एकाग्रता क्रिप्टोग्राफिक संदेश प्रमाणीकरण कोड (एचएमएसी-शाए 1 किंवा एचएमएसी-एमडी 5) द्वारे प्रदान केली आहे.
प्रोटोकॉल आवृत्ती 2 सार्वजनिक की आधारित वापरकर्ता (पब्किआअटिकेशन) किंवा क्लायंट होस्ट (होस्टबसेझअटिफिकेशन) प्रमाणीकरण पद्धत, पारंपारिक पासवर्ड प्रमाणीकरण आणि आव्हान-प्रतिसाद आधारित पद्धती प्रदान करते.
आदेश कार्यवाही आणि डेटा अग्रेषण
जर क्लाएंटने स्वतःच प्रमाणीकरण केले असेल तर सत्र तयार करण्यासाठी एक संवाद प्रविष्ट केला जाईल. यावेळी क्लायंट सिडो-टीटीआय, फॉरवर्डिंग X11 कनेक्शन, टीसीपी / आयपी कनेक्शन अग्रेषण, किंवा सुरक्षित चॅनलवर प्रमाणीकरण एजंट कनेक्शन अग्रेषित करण्यासारख्या गोष्टींची विनंती करू शकतो.
अखेरीस क्लायंट शेलसाठी विनंती करतो किंवा आदेश कार्यान्वित करतो. बाजू नंतर सत्र मोड प्रविष्ट करा या मोडमध्ये, दोन्ही बाजू कोणत्याही वेळी डेटा पाठवू शकते, आणि अशा डेटाला शेलवरून किंवा सर्व्हरच्या बाजूवर अग्रेषित केले जाते, आणि क्लायंटच्या बाजूला वापरकर्ता टर्मिनल.
जेव्हा वापरकर्ता कार्यक्रम संपुष्टात आणेल आणि सर्व अग्रेषित X11 आणि इतर कनेक्शन बंद केले जातील, तेव्हा सर्व्हर क्लाएंटला आदेश बाहेर जाण्याची स्थिती आणि दोन्ही बाजू बाहेर जाण्याची सूचना पाठवेल.
sshd ला कमांड लाइन पर्याय किंवा संरचना फाइल वापरून संरचीत करणे शक्य आहे. आदेश-ओळ पर्याय संरचना फाइलमध्ये निर्देशीत मूल्य ओव्हरराइड करते.
sshd हेंग्वग सिग्नल प्राप्त झाल्यावर त्याचे कॉन्फिगरेशन फाइल पुन्हांय करते, SIGHUP नावाने स्वतः सुरू केल्यावर, म्हणजेच, / usr / sbin / sshd
पर्याय खालीलप्रमाणे आहेत:
-बी बिट्स
तात्पुरत्या प्रोटोकॉल आवृत्ती 1 सर्व्हर की (डीफॉल्ट 768) मधील बिट संख्या निर्दिष्ट करते.
-डी
डीबग मोड. सर्व्हर सिस्टम लॉगवर वर्बोज डिबग आउटपुट पाठविते आणि पार्श्वभूमीमध्ये स्वतः ठेवत नाही. सर्व्हर देखील कार्य करणार नाही आणि फक्त एका कनेक्शनवर प्रक्रिया करेल. हा पर्याय फक्त सर्व्हरसाठी डीबगिंगसाठी उद्देशित आहे. बहु-डी पर्याय डिबगिंग स्तर वाढवतात. कमाल 3 आहे
-e
जेव्हा हा पर्याय निर्देशीत केला जातो, तेव्हा sshd आउटपुटला सिस्टम लॉगऐवजी मानक त्रुटीमध्ये पाठवेल.
-f कॉन्फिगरेशन_फाइल
संरचना फाइलचे नाव निर्देशीत करतो. मुलभूत आहे / etc / ssh / sshd_config sshd जर संरचना फाइल नसल्यास सुरू करण्यास नकार दिला जातो.
-g login_grace_time
क्लायंटना स्वत: प्रमाणित करण्यासाठी (डीफॉल्ट 120 सेकंद) देण्याची कृपा वेळ देते. क्लाएंट या सेकंदांमध्ये वापरकर्त्याचे प्रमाणीकरण करण्यास अपयशी ठरल्यास, सर्व्हर डिस्कनेक्ट करतो, आणि बाहेर पडतो. शून्य चे मूल्य मर्यादा सूचित करते.
-h host_key_file
एक फाइल निर्दिष्ट करते ज्यावरून होस्ट की वाचली जाते. हा पर्याय दिलाच पाहिजे जर sshd रूट म्हणून चालत नाही (सामान्य होस्ट की फाइल्स सहसा वाचण्यायोग्य नाही तर रूट म्हणून) पूर्वनिर्धारित प्रोटोकॉल आवृत्ती 1 करीता / etc / ssh / ssh_host_key व प्रोटोकॉल आवृत्तीसाठी / etc / ssh / ssh_hos_rsa_key व / etc / ssh / ssh_host_dsa_key आहे. विविध प्रोटोकॉल आवृत्ती व यजमान कळकरीता बहुस्तरीय कळ फाइल असणे शक्य आहे अल्गोरिदम
-i
निर्दिष्ट करतो की sshd inetd पासून चालविले जात आहे. sshd सहसा inetd वरून चालत नाही कारण क्लाएंटला प्रतिसाद देण्यापूर्वी सर्व्हर की व्युत्पन्न करण्याची आवश्यकता असते, आणि यास दहापट लागू शकतात जर प्रत्येक वेळी किल्ली पुन्हा निर्माण केली गेली तर ग्राहकांना खूप प्रतीक्षा करावी लागेल. तथापि, inetd पासून sshd चा वापर करून लहान की आकारांसह (उदा., 512) शक्य असू शकते.
-के key_gen_time
क्षणिक प्रोटोकॉल आवृत्ती 1 सर्व्हर की किती वारंवार पुनर्जीवित होते हे निर्दिष्ट करते (डीफॉल्ट 3600 सेकंद किंवा एक तास). किल्ली पुन्हा पुन्हा प्रेरणा देण्याची प्रेरणा हे असे आहे की की कुठे कुठेही साठवले जात नाही, आणि सुमारे एक तासानंतर मशीन मंदावलेली किंवा शारीरिकदृष्ट्या जप्त करण्यात आल्यास कूटप्रश्तरित होणाऱ्या संप्रेषणाचे डिक्रिप्ट करण्याकरता मुख्य पुनर्प्राप्त करणे अशक्य आहे. शून्य चे मूल्य दर्शविते की कि कधीही पुन्हांरले जाणार नाही.
-o पर्याय
कॉन्फिगरेशन फाईलमध्ये वापरलेल्या फॉरमॅटमध्ये पर्याय देण्यासाठी वापरले जाऊ शकते. हे पर्याय निर्दिष्ट करण्यासाठी उपयुक्त आहे ज्यासाठी स्वतंत्र कमांड-लाइन फ्लॅग नाही.
-पी बंदर
पोर्टने कनेक्शन निर्दिष्ट करण्यासाठी पोर्ट निर्दिष्ट करते (डीफॉल्ट 22). एकाधिक पोर्ट पर्यायांना परवानगी आहे. आदेश-ओळ पोर्ट निर्देशीत केल्यावर संरचना फाइलमध्ये निर्देशीत पोर्ट्सकडे दुर्लक्ष केले जाते.
-कडी
शांत मोड काहीही सिस्टम लॉगवर पाठवले नाही. सामान्यत: प्रत्येक कनेक्शनची सुरुवात, प्रमाणीकरण, आणि संपुष्टात आणले जातात.
-टी
चाचणी मोड फक्त कॉन्फिगरेशन फाइलची वैधता आणि कळा पूर्णता तपासा. हे sshd ला अद्ययावत करण्यासाठी उपयुक्त आहे कारण कॉन्फिगरेशन पर्याय बदलू शकतात.
-यू लेन
या पर्यायचा वापर utmp मांडणीमधील शेअर्डचा आकार निर्देशीत करण्यास केला जातो ज्या रिमोट होस्ट नेम समाविष्टीत आहे. जर निराकरण केलेले होस्ट नाव लॅनपेक्षा मोठे असेल तर त्याऐवजी बिंदून चिन्हित मूल्य वापरण्यात येईल. हे मोठ्या होस्ट नावांसह यजमानांना हे फील्ड ओलांडून विशिष्टपणे ओळखले जाऊ देते. निर्देशीत करणे - u0 दर्शविते की फक्त ठळकित दशांश पत्ता utmp फाइलमध्ये टाकायला पाहिजे. - u0 चे वापर sshd ला DNS विनंती करण्यापासून रोखण्यासाठी केला जाऊ शकतो जोपर्यंत प्रमाणीकरण पद्धती किंवा संरचनाकरिता आवश्यक नाही DNS ची आवश्यकता असलेल्या प्रमाणीकरण पद्धतीमध्ये RhostsAuthentication RhostsRSAAuthentication होस्टबज्डअटिफिकेशन आणि एक कळ फाइलमधील = pattern-list पर्याय वापरून. कॉन्फिगरेशन पर्यायांसाठी DNS आवश्यक आहे ज्यामध्ये AllowUsers किंवा DenyUsers मधील USER @ HOST नमुन्यात वापर करणे समाविष्ट आहे
-डी
जेव्हा हा पर्याय दर्शवला जातो तेव्हा sshd वेगळे होणार नाही आणि डिमन होऊ शकत नाही यामुळे sshd ची देखरेख सुलभ होते
-4
फक्त IPv4 पत्ते वापरण्यासाठी sshd सक्ती करा
-6
फक्त IPv6 पत्ते वापरण्यासाठी sshd सक्ती करा
व्यूहरचना फाइल
sshd द्वारे संरचना माहिती वाचते / etc / ssh / sshd_config (किंवा फाइलसह निर्देशीत फाइल - f ला आदेश ओळवर). फाइल स्वरूपन आणि संरचना पर्याय sshd_config5 मध्ये वर्णन केले आहेत.
लॉगिन प्रक्रिया
जेव्हा वापरकर्ता यशस्वीरित्या लॉग इन करतो, sshd खालील गोष्टी करतो:
- लॉगिन tty वर असल्यास, व आदेश निर्देशीत न केल्यास, शेवटचेवेळी लॉगईन वेळ व / etc / motd (जोपर्यंत कॉन्फिगरेशन फाइल किंवा $ HOME / .hushlogin द्वारे SX फायली पहात नाही तोपर्यंत) मुद्रित करते.
- लॉगिन एक tty वर असल्यास, प्रवेश लॉग इन वेळ.
- चेक / etc / nologin अस्तित्वात असल्यास, सामुग्री छपाई करतो व (रूट नसल्यास) सोडतो.
- सामान्य वापरकर्ता विशेषाधिकार सह चालविण्यासाठी बदल.
- मुलभूत वातावरण तयार करते.
- $ HOME / .ssh / environment हे जर अस्तित्वात असेल आणि वापरकर्त्यांना त्यांच्या पर्यावरण बदलायला परवानगी आहे. Sshd_config5 मध्ये PermitUser पर्यावरण पर्याय पहा.
- वापरकर्त्याच्या मुख्य निर्देशिकेत बदल.
- $ HOME / .ssh / rc अस्तित्वात असल्यास, त्यास चालवते; else जर / etc / ssh / sshrc अस्तित्वात असेल तरच ती चालते; अन्यथा xauth चालते `` आरसी '' फाइल मानक इनपुटमध्ये X11 ऑथेंटिकेशन प्रोटोकॉल आणि कुकी दिली आहेत.
- वापरकर्त्याचे शेल किंवा आदेश चालविते
अधिकृत_कीज फाइल स्वरूप
$ HOME / .ssh / authorized_keys ही डीफॉल्ट फाइल आहे जी सार्वजनिक की यादी दर्शविते जी प्रोटोकॉल आवृत्ती 1 मध्ये RSA प्रमाणीकरण आणि प्रोटोकॉल आवृत्तीमध्ये सार्वजनिक की प्रमाणीकरण (पब्किआअटिकेशन) साठी परवानगी आहे. अधिकृत केएफाइल वैकल्पिक फाइल निर्दिष्ट करण्यासाठी वापरली जाऊ शकते.
फाइलच्या प्रत्येक ओळमध्ये एक कळ (रिक्त ओळी आणि `# 'ने सुरू होणाऱ्या ओळी यांस टिप्पण्या म्हणून दुर्लक्ष केले जाते) समाविष्ट केले आहे. प्रत्येक आरएसए सार्वजनिक की मध्ये खाली दिलेल्या फील्ड असतात: स्पेसद्वारे विभक्त केलेले: पर्याय, बिट्स, एक्सपोनंट, मापांक, टिप्पणी. प्रत्येक प्रोटोकॉल आवृत्ती 2 पब्लिक की मध्ये हे समाविष्ट होते: पर्याय, कीटाइप, बेस 64 एन्कोडेड की, टिप्पणी. पर्याय फील्ड वैकल्पिक आहे; त्याची उपस्थिती रेषा क्रमांकाने सुरू होते की नाही हे ठरते (पर्याय फील्ड नंबर सह प्रारंभ होत नाही) बिट, एक्सपोनंट, मापांक आणि टिप्पणी फील्ड प्रोटोकॉल आवृत्ती 1 साठी आरएसए की देतात; टिप्पणी फील्ड काहीहीसाठी वापरली जात नाही (परंतु वापरकर्त्याला की ओळखण्यासाठी सोयीची असेल). प्रोटोकॉल आवृत्ती 2 साठी कीप्रकार `` ssh-dss '' किंवा `` ssh-rsa '' आहे
लक्षात घ्या की या फाईलमधील ओळी बहुधा काही शंभर बाइट आहेत (सार्वजनिक की एन्कोडिंगच्या आकारामुळे). आपण त्यात टाइप करू इच्छित नाही; त्याऐवजी, identity.pub id_dsa.pub किंवा id_rsa.pub फाईल कॉपी करा आणि त्यास संपादित करा.
sshd किमान RSA की मापांक प्रोटोकॉल 1 करीता माप आकार आणि 768 बिट्सच्या प्रोटोकॉल 2 किज्ला लागू करतो.
पर्याय (उपस्थिती असल्यास) स्वल्पविरामाने विभक्त केलेले पर्याय तपशील असतात. दुहेरी अवतरण चिन्हात वगळता, कोणत्याही जागेला परवानगी नाही खालील पर्याय तपशील समर्थित आहेत (लक्षात ठेवा की पर्याय कीवर्ड केस-असंवेदनशील आहेत):
= पॅटर्न-यादीमधून
स्पष्ट करते की सार्वजनिक की प्रमाणीकरणाव्यतिरिक्त, स्वल्पविराम-विभक्त केलेल्या नमुन्यांची सूचीमध्ये दूरस्थ होस्टचे प्रमाणभूत नाव उपस्थित असणे आवश्यक आहे (`* 'आणि`?' वाइल्डकार्ड म्हणून सर्व्ह करा). सूचीमध्ये `! 'सह प्रिफिक्सद्वारे नकारलेल्या नमुन्यांची देखील समाविष्ट असू शकते ; जर कॅनॉनिक होस्ट नेम नकारलेल्या नमुन्याशी जुळत असेल तर कि स्वीकारली जात नाही. या पर्यायाचा उद्देश पर्यायीपणे सुरक्षा वाढविणे आहे: सार्वजनिक की प्रमाणीकरण स्वतःच नेटवर्क किंवा नाव सर्व्हरवर किंवा कोणत्याही गोष्टीवर (परंतु की) विश्वास ठेवत नाही; तथापि, जर कोणीतरी एखादी व्यक्ती चाबी चोरून घेत असेल तर, की घुसखोर जगातील कोणत्याही ठिकाणाहून लॉग इन करण्याची परवानगी देतो. हा अतिरिक्त पर्याय चोरलेल्या की अधिक कठीण बनवते (नाव सर्व्हर आणि / किंवा रूटर फक्त की व्यतिरिक्त तडजोड केली गेली पाहिजे).
आदेश = आदेश
जेव्हा हे की प्रमाणीकरणासाठी वापरली जाते तेव्हा आदेश कार्यवाही करतो. उपयोजकाद्वारे पुरवलेला आदेश (असल्यास) दुर्लक्षीत केला जातो. क्लाएंट पीटीसाठी विनंती केल्यास pty वर चालते; अन्यथा तो एक tty न चालवला आहे. एखादा 8-बिट स्वच्छ चॅनेल आवश्यक असल्यास, त्याने pty ची विनंती न करणे आवश्यक आहे किंवा नॉन-पीटीटी निर्दिष्ट करणे आवश्यक आहे त्यास त्यासमध्ये बॅकस्लॅशसह उद्धृत केले जाईल. हे पर्याय फक्त विशिष्ट कार्य करण्यास विशिष्ट सार्वजनिक की प्रतिबंधित करण्यास उपयोगी असू शकतो. उदाहरणार्थ अशी एक कि असू शकते जी रिमोट बॅकअपला परवानगी देते परंतु दुसरे काहीही नाही लक्षात ठेवा ग्राहक स्पष्टपणे प्रतिबंधित नसल्यास TCP / IP आणि / किंवा X11 अग्रेषित करणे निर्दिष्ट करू शकतात. लक्षात ठेवा हा पर्याय शेल, आदेश किंवा उपप्रणाली एक्जिक्युशन लागू होतो.
पर्यावरण = NAME = मूल्य
या कळचा वापर करून लॉगइन करतेवेळी स्ट्रिंग वातावरणमध्ये समाविष्ट करणे निर्देशीत करते. पर्यावरण वेरियेबल्सने हे पर्याय इतर मुलभूत पर्यावरण मूल्यांकरीता अधिलिखित केले. या प्रकारच्या अनेक पर्यायांना परवानगी आहे पर्यावरण प्रक्रिया डीफॉल्टनुसार अक्षम केली जाते आणि PermitUser पर्यावरण पर्यावरणाद्वारे नियंत्रित केली जाते. UseLogin सक्षम असल्यास हे पर्याय स्वयंचलितपणे अक्षम केले जातात
no-port-forwarding
हे की प्रमाणीकरणासाठी वापरली जाते तेव्हा टीसीपी / आयपी अग्रेषण फोर्ब्ड. क्लाएंटने कोणतीही पोर्ट अग्रेषित करण्याची विनंती त्रुटी परत करेल. हे कदाचित वापरले जाऊ शकते, उदा., कमांड पर्यायाच्या संबंधात.
नो-X11-अग्रेषण
हे की प्रमाणीकरणासाठी वापरली जात असताना फॉरबॅड X11 फॉरवर्डिंग. ग्राहकाद्वारे कोणतीही X11 अग्रेषित विनंती त्रुटी परत देईल.
नो एजंट अग्रेषण
हे की प्रमाणीकरणासाठी वापरली जाते तेव्हा प्रमाणीकरण एजंट अग्रेषण Forbids
नो-पीटी
Tty वाटप रोखते (पीटी वाटप करण्याची विनंती अयशस्वी होईल)
permitopen = host: port
स्थानिक `` ssh-L ' पोर्ट अग्रेषण मर्यादित करा जेणेकरुन ते फक्त निर्दिष्ट होस्ट आणि पोर्टशी जोडता येईल. IPv6 पत्ते एका वैकल्पिक वाक्यरचनासह निर्दिष्ट केले जाऊ शकतात: host / port एकाधिक परमिट पर्याय वापरून स्वल्पविरामाने वेगळे केले जाऊ शकते. निर्दिष्ट होस्टनावेवर कोणताही पॅटर्न जुळणी केली जात नाही, ती शाब्दिक डोमेन किंवा पत्ते असणे आवश्यक आहे.
उदाहरणे
1024 33 12121 ... 312314325 ylo@foo.bar
पासून = "*. niksula.hut.fi,! pc.niksula.hut.fi" 1024 35 23 ... 2334 ylo @ निकसूला
कमांड = "डंप / होम", नो-पीटी, नो-पोर्ट-फॉरवर्डिंग 1024 33 23 ... 2323 बॅकअप. alt.fi
permitopen = "10.2.1.55:80", परमिटोपेन = "10.2.1.56:25" 1024 33 23 ... 2323
Ssh_Known_Hosts फाइल स्वरूप
/ Etc / ssh / ssh_ aware_hosts व $ HOME / .ssh / known_hosts फाइल्स् मध्ये सर्व ज्ञात होस्टसाठी होस्ट पब्लिक कीज आहेत. वैश्विक फाइल प्रशासकाद्वारे तयार करावी (वैकल्पिक), आणि प्रति-वापरकर्ता फाईल स्वयंचलितपणे चालू ठेवली जाते: जेव्हा वापरकर्ता अज्ञात होस्टशी कनेक्ट करतो तेव्हा प्रति-वापरकर्ता फाईलमध्ये त्याची की जोडली जाते
या फाइलीमधील प्रत्येक ओळी मध्ये खालील फील्ड आहेत: hostnames, bits, exponent, modulus, comment. फील्ड रिक्त स्थानांद्वारे विभक्त केलेले आहेत
यजमाननावे एक स्वल्पविराम-विभाजित नमुन्यांची सूची आहेत ('*' आणि '?' वाइल्डकार्ड म्हणून कार्य करा); प्रत्येक नमुना, त्याउलट, अधिकृत होस्ट नेम (क्लायंट प्रमाणित करताना) किंवा वापरकर्ता-पुरवलेल्या नावाविरूद्ध (सर्व्हर प्रमाणित करताना) विरूद्ध जुळविले जाते. एक नमुना '!' नमुना दर्शविण्याकरीता: जर यजमान नेम नकारलेल्या पॅटर्नशी जुळत असेल, तर त्याला ओळीवर दुसरा नमुना जुळत असला तरीही (त्या ओळीने) स्वीकारले जात नाही.
बिट्स, एक्सपोनंट, आणि मॉड्यूलस आरएसए होस्ट कीमधून थेट घेतले जातात; ते मिळवता येतात, उदा., /etc/ssh/ssh_host_key.pub कडून पर्यायी टिप्पणी फील्ड ओळीच्या समाप्तीपर्यंतच चालू असते, आणि ती वापरली जात नाही.
`# 'आणि रिक्त ओळीपासून सुरू होणाऱ्या ओळी टिप्पण्या म्हणून दुर्लक्षित केल्या आहेत
यजमान प्रमाणिकरण करत असताना, जुळणारी ओळ चांगली असेल तर प्रमाणीकरण स्वीकारले जाते. अशाप्रकारे त्याच नावासह अनेक ओळी किंवा वेगळी होस्ट की असणे आवश्यक आहे (परंतु शिफारसित नाही). हे अनिवार्यपणे घडते जेव्हा विविध डोमेनवरील होस्ट नावांचे लहान फाइल्स फाइलमध्ये ठेवले जातात. फायलींवर विवादित माहिती असणे शक्य आहे; प्रमाणीकरण स्वीकारले जाते जर वैध माहिती एखाद्या फाईलमधून आढळू शकते.
लक्षात घ्या की या फायलीमधील ओळी साधारणपणे लक्षावधी वर्ण असतात आणि आपण निश्चितपणे यजमान की वापर करुन हाताने टाइप करू इच्छित नसतो. त्याऐवजी, स्क्रिप्टद्वारे किंवा /etc/ssh/ssh_host_key.pub करून आणि समोर यजमान नावे समाविष्ट करून त्यांना व्युत्पन्न करा.
उदाहरणे
क्लिननेट, ..., 130.233.208.41 1024 37 15 9 ... 93 बंदिन्ते Hut.fi cvs.openbsd.org, 199.185.137.3 एसएस-आरएसए एएएए 1234 ..... =तसेच पहा
scp (1), sftp (1), ssh (1), ssh-add1, ssh-agent1, ssh-keygen1, login.conf5, moduli (5), sshd_config5, sftp-server8
टी. य्ललेन टी. केव्हिनें एम. सारिनिन टी. रिन्ने एस लेहटिनन "एसएसएच प्रोटोकॉल आर्किटेक्चर" ड्राफ्ट- ietf-secsh-architecture-12.txt जानेवारी 2002 प्रगतीपथावर काम
एम. फ्रिडल एन. प्रोवोस वा. ए. सिम्पसन "डीएसपी-हेलमन ग्रुप एक्सचेंज फॉर एसएसएच ट्रान्सपोर्ट लेयर प्रोटोकॉल" मसुदा- ietf-secsh-dh-group-exchange-02.txt जानेवारी 2002 प्रगतीपथावर काम
महत्वाचे: आपल्या कॉम्प्यूटरवर आज्ञा कशी वापरली जाते हे पाहण्यासाठी man कमांड ( % man ) वापरा.