SSH सर्वर को सख्त कैसे करें?

Question

मुझे यह सुनिश्चित करने के लिए क्या उपाय करना चाहिए / लेना चाहिए कि मेरे SSH सर्वर के चारों ओर की सुरक्षा पूरी तरह से अभेद्य है?

यह शुरू से ही सामुदायिक विकी होगा, ताकि लोग यह देख सकें कि लोग अपने सर्वर को सुरक्षित करने के लिए क्या करते हैं।

Comments

निरपेक्ष अभेद्यता के लिए बॉक्स को बंद करने की आवश्यकता होती है।

— Thorbjørn Ravn Andersen

यदि आपके पास वेक-ऑन-लैन है तो क्या होगा?

— रिबास

समस्या LAN भाग की होगी ... वेक-ऑन-लैन पैकेज रूट नहीं किए गए हैं, इसलिए आपको WOL पैकेज भेजने के लिए LAN के अंदर एक मशीन का उपयोग करना होगा ...

— LassePoulsen

मुख्य प्रमाणीकरण के लिए आप सिफर को उन सिफरों तक सीमित कर सकते हैं जिनकी आपको वास्तव में आवश्यकता है।

Answer 1

पासवर्ड के बजाय प्रमाणीकरण के लिए सार्वजनिक / निजी कुंजी जोड़े का उपयोग करें।

1. सर्वर तक पहुँचने के लिए आवश्यक हर कंप्यूटर के लिए एक पासफ़्रेज़-संरक्षित SSH कुंजी बनाएँ:

   ssh-keygen

2. अनुमत कंप्यूटर से सार्वजनिक-कुंजी SSH पहुँच की अनुमति दें:

   ~/.ssh/id_rsa.pubप्रत्येक कंप्यूटर से सामग्री ~/.ssh/authorized_keysको सर्वर पर अलग-अलग लाइनों में कॉपी करें, या ssh-copy-id [server IP address]प्रत्येक कंप्यूटर पर चलाएं जिस पर आप पहुंच प्रदान कर रहे हैं (आपको प्रॉम्प्ट पर सर्वर पासवर्ड दर्ज करना होगा)।

3. पासवर्ड SSH को अक्षम करें:

   खोलें /etc/ssh/sshd_config, जो रेखा कहती है, उसे ढूंढें #PasswordAuthentication yesऔर उसे बदल दें PasswordAuthentication no। परिवर्तन लागू करने के लिए SSH सर्वर डेमॉन को पुनरारंभ करें ( sudo service ssh restart)।

अब, सर्वर में SSH का एकमात्र संभव तरीका एक पंक्ति से मेल खाने वाली कुंजी का उपयोग करना है ~/.ssh/authorized_keys। इस पद्धति का उपयोग करते हुए, मैं जानवर बल के हमलों की परवाह नहीं करता, क्योंकि अगर वे मेरे पासवर्ड का अनुमान लगाते हैं, तो भी इसे अस्वीकार कर दिया जाएगा। आज की तकनीक के साथ सार्वजनिक / निजी कुंजी जोड़ी को भंग करना असंभव है।

Comments

-1: आम तौर पर एक्सेस व्यक्ति को नहीं कंप्यूटर को दी जाती है, सर्वर से कनेक्ट होने वाले प्रत्येक संभावित क्लाइंट कंप्यूटर के लिए एक कुंजी बनाना अनुचित है। आपका अंतिम कथन सही नहीं है, आपके प्रति निश्चिंतता और क्योंकि आपने निजी कुंजी के लिए पासफ़्रेज़ निर्धारित करने का सुझाव नहीं दिया था जिसमें किसी भी क्लाइंट सिस्टम का एक्सेस / समझौता करना स्वतः SSH सर्वर तक पहुँच प्रदान करेगा। SSH कुंजी प्रमाणीकरण की अनुशंसा की जाती है, लेकिन निजी कुंजी को ठीक से संरक्षित किया जाना चाहिए और इसका उपयोग व्यक्तिगत आधार पर किया जाना चाहिए, न कि वितरित फैशन में।

— जोहो पिंटो

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

— आसा आयर्स

"असंभव" शायद यह थोड़ा अधिक है।

— Thorbjørn Ravn Andersen

यही कारण है कि मैं "असंभव" कहता हूं। किसी के पास कंप्यूटर नहीं है यह उपवास इस छोटे से कई या बहुत समय से करता है। "एक कंप्यूटर की कल्पना करें जो रेत के एक दाने का आकार है जो कुछ एन्क्रिप्ट किए गए डेटा के खिलाफ कुंजियों का परीक्षण कर सकता है। इसके अलावा कल्पना करें कि यह इसे पार करने में लगने वाले समय में एक कुंजी का परीक्षण कर सकता है। फिर इन कंप्यूटरों के एक क्लस्टर पर विचार करें। इतने सारे कि अगर आप उनके साथ पृथ्वी को कवर करते हैं, तो वे पूरे ग्रह को 1 मीटर की ऊंचाई तक कवर करेंगे। कंप्यूटर का क्लस्टर 1,000 वर्षों में औसतन 128-बिट कुंजी को क्रैक करेगा। "

— आसा आयर्स

@ ThorbjørnRavnAndersen "असंभव" वास्तव में यह अतिरंजित नहीं है, जब तक आप एक मजबूत कुंजी का उपयोग नहीं करते हैं। मुझे अभी कोई उद्धरण नहीं मिल सकता है, लेकिन वर्तमान प्रमुख लंबाई के साथ, जानवर बल के हमले "जब तक कि कंप्यूटर पदार्थ के अलावा किसी अन्य चीज से बने होते हैं और अंतरिक्ष के अलावा किसी अन्य चीज पर कब्जा नहीं करते हैं"

— मैक्सिमिलियन लूमिस्टर

Answer 2

मै सुझाव दूंगा:

• Brute बल लॉगिन प्रयासों को रोकने के लिए fail2ban का उपयोग करना ।

• SSH के माध्यम से रूट के रूप में लॉगिंग को अक्षम करना। इसका मतलब है कि एक हमलावर को उपयोगकर्ता नाम और पासवर्ड दोनों का पता लगाना पड़ता है और हमले को और अधिक कठिन बना देता है।

  PermitRootLogin noअपने में जोड़ें /etc/ssh/sshd_config।

• उन उपयोगकर्ताओं को सीमित करना जो सर्वर पर SSH कर सकते हैं। या तो समूह या केवल विशिष्ट उपयोगकर्ताओं द्वारा।

  सर्वर पर SSH कौन कर सकता है, इसे जोड़ें AllowGroups group1 group2या AllowUsers user1 user2सीमित करें।

Comments

AllowUsers और AllowGroups एक अल्पविराम को स्वीकार नहीं करता , परिसीमक के रूप में। सुनिश्चित करें कि आप इसे दूरस्थ रूप से आज़माएँ नहीं। मैं गलत तरीके से ऐसा करते हुए अपने NAS को बंद करवाता रहता हूं।

— आर्टलेस शोर

sshdमशीन से बाहर अपने आप को लॉक करने से बचने के लिए, अपने एसडीएस को पुनरारंभ करने से पहले हमेशा अपने कॉन्फ़िगरेशन को सही करें। देखें इस ब्लॉग जानकारी के लिए - बस चलाने के sshd -Tमुख्य पुन: प्रारंभ करने से पहले एक config परिवर्तन के बाद sshd। इसके अलावा, SSH सत्र को मशीन पर तब खोलें जब आप कॉन्फिगरेशन को बदलते हैं, और इसे तब तक बंद न करें जब तक कि आपने कॉन्फ़िगर किए गए कॉन्फिगरेशन का उल्लेख नहीं किया है और हो सकता है कि उसने SSH लॉगिन का परीक्षण किया हो।

— रिचवेल

Answer 3

अन्य उत्तर सुरक्षा प्रदान करते हैं, लेकिन एक चीज है जो आप कर सकते हैं जो आपके लॉग को शांत कर देगा, और यह संभावना कम कर देगा कि आप अपने खाते से लॉक हो जाएंगे:

सर्वर को पोर्ट 22 से दूसरे में ले जाएं। या तो अपने प्रवेश द्वार पर, या सर्वर पर।

यह सुरक्षा में वृद्धि नहीं करता है, लेकिन इसका मतलब यह है कि सभी यादृच्छिक इंटरनेट स्कैनर आपको लॉग इन फ़ाइलों को अव्यवस्थित नहीं करेंगे।

Comments

जो लोग अस्पष्टता ( en.wikipedia.org/wiki/Security_through_obscurity ) द्वारा सुरक्षा में विश्वास करते हैं, उनके लिए दूसरे पोर्ट का उपयोग करना बहुत मायने रखता है। हालांकि मैं नहीं ..

— LassePoulsen

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

— बॉबिन

चूंकि आप वेब-फेसिंग ssh सर्वरों के लिए shodan जैसी इंटरनेट सेवाओं की क्वेरी कर सकते हैं, या nmap और बैनर कैप्चर का उपयोग करके डिफ़ॉल्ट पोर्ट को बहुत ज्यादा बेकार कर देते हैं। मैं इसके खिलाफ सलाह दूंगा।

— बजे लोरिस

Shodan सभी 65k पोर्ट को नहीं पकड़ता है, इसलिए उच्च पोर्ट में बदलने की संभावना है कि यह उनके स्कैन से हटा देगा। इसके अलावा यदि आप एक यादृच्छिक उच्च बंदरगाह पर जाते हैं तो हमलावर को 65K टीसीपी स्कैन (बहुत शोर) करने की आवश्यकता होगी ताकि आप उस पर हमला करना शुरू कर सकें। ये दोनों सुरक्षा के दृष्टिकोण से जीत रहे हैं, इसलिए उच्च बंदरगाह पर जाना आम तौर पर एक अच्छी योजना है। एक और यह है कि एक उच्च बंदरगाह पर जाने से आपको यह बेहतर विचार हो सकता है कि कोई व्यक्ति जो आप पर हमला कर रहा है, विशेष रूप से आपके सिस्टम को केवल सामान्य पृष्ठभूमि के इंटरनेट शोर के विपरीत लक्षित कर रहा है

— रॉरी मैककिन

Answer 4

HOTP या TOTP के साथ दो कारक प्रमाणीकरण सक्षम करें । यह 13.10 बजे से उपलब्ध है।

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

सारांश:

1. sudo apt-get install libpam-google-authenticator

2. क्या प्रत्येक उपयोगकर्ता google-authenticatorकमांड चलाता है , जो उत्पन्न ~/.google-authenticatorकरता है और उन्हें अपने दो कारक डिवाइस (जैसे Google प्रमाणक एंड्रॉइड ऐप) कॉन्फ़िगर करने में मदद करता है।

3. संपादित करें /etc/ssh/sshd_configऔर सेट करें:

   ChallengeResponseAuthentication yes
   PasswordAuthentication no
   AuthenticationMethods publickey,keyboard-interactive
   

4. भागो sudo service ssh reloadमें अपने परिवर्तन लेने के लिए /etc/ssh/sshd_config।

5. संपादित करें /etc/pam.d/sshdऔर पंक्ति बदलें:

   @include common-auth
   

   साथ में:

   auth required pam_google_authenticator.so
   

विभिन्न विन्यास विकल्पों पर अधिक जानकारी पिछले वर्ष से मेरा ब्लॉग पोस्ट है: उबंटू पर बेहतर दो कारक ssh प्रमाणीकरण ।

Answer 5

Sshd ब्लॉक क्लाइंट IP बनाएं जो सही लॉगिन जानकारी " DenyHsts " की आपूर्ति करने में विफल रहे हैं, इस काम को काफी प्रभावी ढंग से कर सकते हैं। मैंने इसे अपने सभी लिनक्स बॉक्सों पर स्थापित किया है जो किसी तरह से महान बाहर से पहुंच योग्य हैं।

यह सुनिश्चित करेगा कि SSHD पर बल-हमला प्रभावी नहीं होगा, लेकिन याद रखें (!) इस तरह से आप अपने आप को लॉक कर सकते हैं यदि आप पासवर्ड भूल जाते हैं। यह एक दूरस्थ सर्वर पर एक समस्या हो सकती है, जिसकी आपको एक्सेस नहीं है।

Comments

क्या आईपी पते पर प्रतिबंध लगाने से पहले 10 विफल लॉगिन प्रयास जैसे कुछ विकल्प हैं?

— सायंकालीन

Answer 6

यहां एक आसान काम है: ufw ("सीधी फ़ायरवॉल") स्थापित करें और इसका उपयोग आने वाले कनेक्शनों को सीमित करने के लिए करें।

कमांड प्रॉम्प्ट से, टाइप करें:

$ sudo ufw limit OpenSSH 

यदि ufw स्थापित नहीं है, तो इसे करें और पुनः प्रयास करें:

$ sudo aptitude install ufw 

कई हमलावर आपके SSH सर्वर का उपयोग ब्रूट-फोर्स पासवर्ड के लिए करने का प्रयास करेंगे। यह एक ही आईपी पते से हर 30 सेकंड में केवल 6 कनेक्शन की अनुमति देगा।

Comments

+1 लिमिट का उपयोग करना अच्छा हो सकता है। हालाँकि मुझे इस बात की ओर ध्यान देना चाहिए कि जब मैंने sftp सर्वर में उपयोग किया है तो यह समस्याओं का सामना करता है क्योंकि यह इसके लिए कनेक्शन को सीमित करता है।

— मार्क डेविडसन

@ मार्क - अच्छी बात है, लेकिन क्या यह खराब लिखे गए SFTP क्लाइंट की तरह नहीं है? जब वे सिर्फ और अधिक SSH चैनल खोल सकते हैं तो वे SSH पोर्ट को फिर से कनेक्ट क्यों करेंगे?

— एमपोंटिलो

Answer 7

अगर मुझे कुछ अतिरिक्त सुरक्षा चाहिए या कुछ कॉर्पोरेट नेटवर्क के अंदर गहरी SSH सर्वर तक पहुँचने की आवश्यकता है, तो मैं एक अज्ञात सेवा का उपयोग करके एक अज्ञात सॉफ्टवेयर टोर का उपयोग करके सेटअप कर सकता हूं ।

1. टॉर इंस्टॉल करें और SSH सर्वर को स्वयं सेटअप करें।
2. सुनिश्चित करें कि sshd केवल सुनता है localhost।
3. खोलें /etc/tor/torrc। सेट HiddenServiceDir /var/lib/tor/sshऔर HiddenServicePort 22 127.0.0.1:22।
4. को देखो var/lib/tor/ssh/hostname। जैसा नाम है d6frsudqtx123vxf.onion। यह छिपी हुई सेवा का पता है।

5. $HOME/.ssh/configकुछ लाइनें खोलें और जोड़ें:

   Host myhost
   HostName d6frsudqtx123vxf.onion
   ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
   

इसके अलावा मुझे अपने स्थानीय मेजबान पर टोर की जरूरत है। यदि यह स्थापित है तो मैं प्रवेश कर सकता हूं ssh myhostऔर एसएसएच टोर के माध्यम से एक कनेक्शन खोलता है। दूसरी तरफ SSH सर्वर केवल लोकलहोस्ट पर अपना पोर्ट खोलता है। तो कोई भी इसे "सामान्य इंटरनेट" के माध्यम से जोड़ सकता है।

Comments

उन्नत अस्पष्टता से सुरक्षा, लेकिन बहुत दिलचस्प।

— जोहान्स

Answer 8

इस विषय पर डेबियन प्रशासन लेख है। यह मूल SSH सर्वर कॉन्फ़िगरेशन को कवर करता है और फ़ायरवॉल नियम भी। यह SSH सर्वर को कड़ा करने के लिए भी रुचि का हो सकता है।

वहाँ लेख देखें: SSH को सुरक्षित रखना ।

Comments

थोड़ा देर से, लेकिन कृपया, प्रश्नों का उत्तर देते समय, एक लिंक से महत्वपूर्ण भागों को कॉपी करें, ताकि यदि लिंक का फैसला हो तो जानकारी अभी भी यहां है।

— umpl aplsdn

अच्छा विचार। हालांकि मैं भाग लेने के लिए बहुत कम समय के साथ एक अवधि के माध्यम से हूँ। मेरा उत्तर एक "समुदाय विकि" है, इसलिए यदि आपके पास समय हो तो लिंक जानकारी जोड़ने के लिए स्वतंत्र महसूस करें।

— Huygens

Answer 9

SSH सख्त करने के लिए मेरा दृष्टिकोण है ... जटिल। निम्नलिखित आइटम मेरे सर्वर के किनारे-सबसे सीमा (सर्वर) से स्वयं को सर्वर पर कैसे करते हैं, इसके संदर्भ में हैं।

1. ब्लॉकलिस्ट में ज्ञात सेवा स्कैनर और हस्ताक्षर के साथ आईडीएस / आईपीएस के माध्यम से यातायात के सीमा-स्तर को छानना। मैं अपनी सीमा फ़ायरवॉल के माध्यम से स्नॉर्ट के साथ इसे प्राप्त करता हूं (यह मेरा दृष्टिकोण है, एक pfSense उपकरण)। कभी-कभी, मैं ऐसा नहीं कर सकता, जैसे कि मेरे VPSes के साथ।

2. SSH पोर्ट के फ़ायरवॉल / नेटवर्क फ़िल्टरिंग। मैं स्पष्ट रूप से केवल कुछ सिस्टम को अपने SSH सर्वरों तक पहुँचने की अनुमति देता हूँ। यह या तो मेरे नेटवर्क की सीमा पर एक pfSense फ़ायरवॉल के माध्यम से किया जाता है, या प्रत्येक सर्वर पर फ़ायरवॉल स्पष्ट रूप से कॉन्फ़िगर किया जा रहा है। ऐसे मामले हैं जहां मैं ऐसा नहीं कर सकता, हालांकि (जो लगभग कभी भी ऐसा नहीं होता है, केवल निजी पेन-परीक्षण या सुरक्षा परीक्षण प्रयोगशाला वातावरण को छोड़कर जहां फायरवॉल परीक्षण चीजों की मदद नहीं करेगा)।

3. मेरे pfSense, या एक सीमा फ़ायरवॉल के साथ संयोजन के रूप में आंतरिक नेटवर्क नैट-आईएनजी और इंटरनेट और सिस्टम से अलग, वीपीएन-ओनली एक्सेस टू सर्वर्स । सर्वरों को प्राप्त करने के लिए अपने नेटवर्क में वीपीएन प्राप्त करें, क्योंकि इस तरह का कोई इंटरनेट-फेसिंग पोर्ट नहीं है। यह निश्चित रूप से मेरे सभी VPSes के लिए काम नहीं करता है, लेकिन # 2 के साथ संयोजन के रूप में, मैं उस सर्वर में वीपीएन करके एक VPS 'गेटवे' हो सकता है, और फिर इसे अन्य बॉक्स के लिए IPs की अनुमति देता है। इस तरह, मुझे पता है कि एसएसएच इन - मेरे एक बॉक्स जो कि वीपीएन है, क्या कर सकता है या नहीं कर सकता है। (या, pfSense के पीछे मेरे होम नेटवर्क में, मेरा वीपीएन कनेक्शन, और मैं वीपीएन एक्सेस के साथ अकेला हूं)।

4. जहाँ # 3 करने योग्य नहीं है, fail2ban, 4 विफल प्रयासों के बाद ब्लॉक करने के लिए कॉन्फ़िगर किया गया है और एक घंटे या उससे अधिक के लिए IP को ब्लॉक करना है जो लोगों पर लगातार क्रूरता के साथ हमला कर रहा है, उनके खिलाफ एक सभ्य सुरक्षा है - बस असफल फ़ायरबैन पर असफल एम 2 के साथ, और meh। हालांकि असफल 2 विन्यास कॉन्फ़िगर करना एक दर्द है ...

5. SSH पोर्ट को बदलकर पोर्ट ऑबफैक्शन। हालांकि, यह बिना किसी अतिरिक्त सुरक्षा उपाय के करने के लिए एक अच्छा विचार नहीं है - "सुरक्षा के माध्यम से अस्पष्टता" का मंत्र पहले ही कई मामलों में खंडन किया गया है और विवादित है। मैंने इसे आईडीएस / आईपीएस और नेटवर्क फ़िल्टरिंग के संयोजन में किया है, लेकिन यह अभी भी बहुत खराब है।

6. MANDATORY टू-फैक्टर ऑथेंटिकेशन, डू सिक्योरिटी के टू-फैक्टर ऑथेंटिकेशन सॉल्यूशंस के जरिए । मेरे हर एसएसएच सर्वर में से प्रत्येक ने डुओ को इस पर कॉन्फ़िगर किया है, जैसे कि इसमें प्रवेश करने के लिए, 2FA संकेत होते हैं, और मुझे प्रत्येक पहुंच की पुष्टि करनी होगी। (यह अंतिम उपयोगी विशेषता है - क्योंकि भले ही किसी के पास मेरा पासफ़्रेज़ हो या उसमें विराम हो, वे Duo Poo Plugins को पा नहीं सकते हैं)। यह अनाधिकृत उपयोग से मेरे SSH सर्वर पर सबसे बड़ी सुरक्षा में से एक है - प्रत्येक उपयोगकर्ता लॉगिन MUST Duo में एक कॉन्फ़िगर किए गए उपयोगकर्ता के लिए वापस टाई करता है, और चूंकि मेरे पास प्रतिबंधात्मक सेट है, इसलिए सिस्टम में कोई नया उपयोगकर्ता पंजीकृत नहीं किया जा सकता है।

SSH को सुरक्षित करने के लिए मेरे दो-सेंट। या, कम से कम, दृष्टिकोण पर मेरे विचार।

Answer 10

आप Google प्रमाणक का उपयोग करने के बजाय RedHat से FreeOTP ऐप की जांच कर सकते हैं। कभी-कभी ऐप को अपडेट करते समय, वे आपको लॉक कर देते हैं! ;-)

यदि आप Yubikey या eToken PASS या NG जैसे अन्य हार्डवेयर टोकन का उपयोग करना चाहते हैं या यदि आपके पास कई उपयोगकर्ता या कई सर्वर हैं, तो आप एक ओपनसोर्स टू फैक्टर ऑथेंटिकेशन बैकएंड का उपयोग करना चाह सकते हैं।

हाल ही में मैंने इस बारे में एक howto लिखा था ।

Answer 11

मैंने हाल ही में ऐसा करने पर एक छोटा ट्यूटोरियल लिखा है। असल में, आपको PKI का उपयोग करने की आवश्यकता है और मेरा ट्यूटोरियल यह भी दिखाता है कि अधिक सुरक्षा के लिए टू-फैक्टर प्रमाणीकरण का उपयोग कैसे करें। यहां तक ​​कि अगर आप उन चीजों में से किसी का उपयोग नहीं करते हैं, तो कमजोर सिफर स्वीट्स और अन्य मूल बातें हटाकर सर्वर को सुरक्षित करने के बारे में कुछ tidbits भी है। https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

Answer 12

बड़ी संख्या में उपयोगकर्ता / प्रमाणपत्र LDAP एकीकरण पर विचार करते हैं। बड़े संगठन LDAP का उपयोग उपयोगकर्ता क्रेडेंशियल्स और बैज या फोब्स पर संग्रहीत प्रमाणपत्रों के लिए एक रिपॉजिटरी के रूप में करते हैं, चाहे प्रमाण पत्र प्रमाणीकरण या ईमेल पर हस्ताक्षर करने के लिए उपयोग किए जाते हैं। उदाहरणों में OpenLDAP, OpenDJ, सक्रिय निर्देशिका, Oracle Universal निर्देशिका, IBM Directory Server, snareWorks शामिल हैं ...

कंप्यूटर और समूहों को LDAP में केंद्रीय क्रेडेंशियल प्रबंधन देने में भी प्रबंधित किया जा सकता है। इस तरह से मदद डेस्क के पास बड़ी आबादी से निपटने के लिए वन स्टॉप शॉप हो सकती है।

यहाँ सेंटोस एकीकरण का लिंक दिया गया है: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html

Answer 13

आप जियोआईपी डेटाबेस का उपयोग करके मूल देश के आधार पर भी ब्लॉक कर सकते हैं।

मूल रूप से यदि आप अमेरिका में रहते हैं तो रूस में किसी को आपके एसएसएच से जुड़ने का कोई कारण नहीं है, इसलिए वे स्वचालित रूप से अवरुद्ध हो जाएंगे।

स्क्रिप्ट यहां देखी जा सकती है: https://www.axllent.org/docs/view/ssh-geoip/

आप इसमें IPPables कमांड को जोड़ सकते हैं (मैंने अपनी बूंदों के लिए) उन IP से / के लिए सभी ट्रैफ़िक को ऑटो ड्रॉप कर दिया।

Comments

कभी-कभी जियोआईपी डेटाबेस गलत हो सकते हैं - मुझसे पूछा गया था कि मैं कल मास्को में था ... एह नहीं! :)

— शॉन