केवल विशिष्ट उपयोगकर्ताओं को एक पोर्ट पर ssh के माध्यम से लॉगिन करने की अनुमति देना और अन्य को दूसरे पोर्ट के माध्यम से लॉगिन करना

13

मेरे पास निम्नलिखित उपयोग का मामला है:

उपयोगकर्ताओं को सुरक्षित, विश्वसनीय नेटवर्क से लॉगिन करने की अनुमति देने की आवश्यकता है
और फिर एक युगल (केवल दो) मोबाइल उपयोगकर्ताओं को लिनक्स सेंटोस मशीन पर दूरस्थ रूप से लॉगिन करने की अनुमति देता है।

मैं sshd को विभिन्न बंदरगाहों पर चला सकता हूँ जैसे:

अंदर से यह 22 पर चलने के लिए ठीक है क्योंकि मैं उन्हें अन्य बंदरगाहों पर कनेक्ट नहीं करना चाहता (स्क्रिप्ट को गड़बड़ करता है)।
बाहरी मोबाइल उपयोगकर्ताओं के लिए, मैं एक अलग पोर्ट पर sshd चलाऊंगा, पोर्ट X (बढ़ी हुई सुरक्षा - यह एक छोटा कार्यालय प्रकार का सेटअप है)।

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

हालाँकि, मैं sshd प्रलेखन में इस तरह के किसी भी विन्यास को खोजने में असमर्थ हूँ। यदि इस तरह का कोई समाधान नहीं है, तो क्या पोर्ट एक्स पर जब भी कोई sshd लॉगिन पूरा करता है, उसे चलाने के लिए शेल स्क्रिप्ट को ट्रिगर करना कम से कम संभव है? मैं iptables दस्तावेज़ीकरण को देख रहा था कि यह देखने के लिए कि sshd लॉगिन है या नहीं, लेकिन कुछ भी नहीं आ सका।

इनपुट्स की सराहना की

centos sshd

— दून
स्रोत

12

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

यदि आप ऐसी प्रणाली पर सुरक्षा sshd_configको व्यवस्थित करना चाहते हैं जो दूरस्थ इंटरनेट-आधारित इनबाउंड SSH की अनुमति दे रही है, तो अपने उपयोगकर्ताओं को @Anthon के रूप में इंगित करने पर नियंत्रण करें , और फिर PAM में सीधे सुरक्षा को लागू करें।

दो समूह बनाएं, lusersऔर rusers। rusersसमूह में दूरस्थ मोबाइल उपयोगकर्ता जोड़ें । उन उपयोगकर्ताओं तक पहुँच की अनुमति देने के लिए pam_succeed_if.so PAM मॉड्यूल का उपयोग करें। Ssh के लिए अपने pam config में लाइनें जोड़ें:

account     sufficient  pam_succeed_if.so user ingroup lusers
account     sufficient  pam_succeed_if.so user ingroup rusers

कुछ pam_succeed_if.so मॉड्यूल आपको थोड़े अलग वाक्यविन्यास का उपयोग करने की आवश्यकता हो सकती है, जैसे group = lusers।

फिर, न केवल sshdउन उपयोगकर्ताओं को सीमित कर रहा है जो कनेक्ट कर सकते हैं, लेकिन बग के अंदर होने की स्थिति में sshd, आपके पास अभी भी सुरक्षा है जो PAM आधारित प्रतिबंधों की पेशकश करता है।

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

इन sshd_config:

2 सेटिंग्स बदलें:

ChallengeResponseAuthentication yes

तथा

PasswordAuthentication yes

सेवा:

ChallengeResponseAuthentication no

तथा

PasswordAuthentication no

इसलिए, डिफ़ॉल्ट को अब केवल कुंजी प्रमाणीकरण की अनुमति है। फिर स्थानीय उपयोगकर्ताओं के लिए आप स्थानीय उपयोगकर्ताओं के matchलिए डिफ़ॉल्ट बदलने के लिए कॉन्फ़िगरेशन सेटिंग को उपयोगकर्ता कर सकते हैं । अपने स्थानीय निजी नेटवर्क को 192.168.1.0/24 मानते हुए, इसमें जोड़ें sshd_config:

Match Address 192.168.1.0/24
PasswordAuthentication yes

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

अतिरिक्त लाभ के रूप में, आपको केवल एक ही प्रबंधन करना होगा sshd_config, और आपको केवल एक ही बंदरगाह पर ssh चलाना होगा, जो आपके प्रबंधन को आसान बनाता है।

संपादित करें 2017-01-21 - authorized_keysफाइलों के उपयोग को सीमित करना ।

यदि आप यह सुनिश्चित करना चाहते हैं कि उपयोगकर्ता केवल ssh कुंजी को स्वयं उत्पन्न नहीं कर सकते हैं, और इसे authorized_keysलॉगिन करने के लिए एक फ़ाइल के साथ उपयोग कर सकते हैं, तो आप यह नियंत्रित कर सकते हैं कि sshd के लिए एक विशिष्ट स्थान सेट करके अधिकृत कुंजी की तलाश करेंगे।

में /etc/ssh/sshd_config, बदलें:

AuthorizedKeysFile  %h/ssh/authorized_keys

कुछ इस तरह से:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

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

— टिम कैनेडी
स्रोत

2

मैं यह नहीं देखता कि आपका उत्तर स्थानीय उपयोगकर्ताओं से दूरस्थ उपयोगकर्ताओं को कैसे अलग करता है। यदि कोई lusersसमूह में है, लेकिन समूह में नहीं है, तो rusersएक कीपर बनाता है और उन्हें अपडेट करता है ~/.ssh/authorized_keys, तो वे रिमोट से लॉग इन कर पाएंगे।

— रिचर्ड हैनसेन

8

आप अपने साथ कुछ इस तरह जोड़ सकते हैं /etc/ssh/sshd_config:

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

ऊपर मान लिया गया है की अनुमति दी है कि दूरदराज के उपयोगकर्ताओं नाम हैं mobileuser1और mobileuser2, और कहा कि अपने विश्वसनीय नेटवर्क सबनेट मास्क 255.0.0.0 साथ 10.0.0.0 है।

यह दो मोबाइल उपयोगकर्ताओं को कहीं से भी और सभी को विश्वसनीय नेटवर्क से लॉग इन करने की अनुमति देता है। कोई भी उपयोगकर्ता जो उन पैटर्नों से मेल नहीं खाता (जैसे कि fooरिमोट से उपयोगकर्ता लॉगिंग) एक्सेस से वंचित रहेगा।

— रिचर्ड हैनसेन
स्रोत

वह टुकड़ा जो मुझे अपने उत्तर में याद आ रहा था। मुझे लगता है कि अगर हमने आपका जवाब मेरे साथ जोड़ दिया, तो यह एक बहुत मजबूत समाधान है।

— टिम कैनेडी

2

आप दो ssh डेमॉन और दो sshd_configफाइल शुरू करके ऐसा कर सकते हैं । अपने मौजूदा एक (उदाहरण के लिए /etc/ssh/sshd_config /etc/ssh/sshd_alt_configऔर manपृष्ठ के लिए वैकल्पिक कॉन्फ़िगरेशन सेटअप में) से कॉपी करें sshd_config:

बंदरगाह

Specifies the port number that sshd(8) listens on.  The default
is 22.  Multiple options of this type are permitted.  See also
ListenAddress

AllowUsers

This keyword can be followed by a list of user name patterns,
separated by spaces.  If specified, login is allowed only for
user names that match one of the patterns.  Only user names are
valid; a numerical user ID is not recognized.  By default, login
is allowed for all users.  If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.  The
allow/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

आप शायद एक अलग फ़ाइल में वैकल्पिक ssh लॉग रखना चाहते हैं, और उदाहरण के लिए उस फ़ाइल में जो लिखा है उसका पालन करें।

— Anthon
स्रोत