क्या यूनिक्स मामले में उपयोगकर्ता संवेदनशील है?


20

है ssh abc@servernameसे अलग ssh Abc@servername? क्या यूनिक्स में उपयोगकर्ता नाम का मामला है?

मेरा उपयोगकर्ता LDAP के माध्यम से प्रमाणित होता है।


3
लिनक्स में लगभग सब कुछ केस-संवेदी है। अर्थ: cdजैसा है वैसा नहीं है CD... केवल उन्हें वास्तव में बनाने का यही मतलब है कि आपकी .bashrcफ़ाइल में उपनाम सेट करना है ..
ryekayo

1
मुझे लगता है कि जो LDAP विशेषता का उपयोग आप उपयोगकर्ता नाम के लिए करता है पर निर्भर करता है। यदि यह RFC 4519 से यूआईडी है , तो यह असंवेदनशील है, लेकिन प्रमाणीकरण कार्यान्वयन अभी भी इसके ऊपर मामला महत्व लगा सकते हैं। यह इस बात पर भी निर्भर करता है कि LDAP के साथ प्रमाणीकरण कैसे किया जाता है।
स्टीफन चेजलस

1
बस अपने उपयोगकर्ता नाम के साथ लॉगिन करने की कोशिश कर रहा है यह आपके लिए मात्र सेकंड में जवाब दिया होगा।
मोनिका

जवाबों:


14

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

क्या उन्हें मामला संवेदनशील माना जाएगा, तो उन्हें निर्दिष्ट करने के लिए उपयोग किए जाने वाले मानक पर निर्भर करता है।

होस्टनाम और डोमेन नाम DNS मानक द्वारा स्पष्ट रूप से असंवेदनशील हैं (देखें RFC4343 )।

स्थानीय बैकएंड (/ etc / passwd) या एक यूनिक्स स्टाइल वन (NIS) पर संग्रहीत उपयोगकर्ता नाम POSIX मानक द्वारा असंवेदनशील नहीं हैं ।

LDAP या एक सक्रिय निर्देशिका बैकएंड में संग्रहीत उपयोगकर्ता नाम उपयोग किए गए विशेषता स्कीमा परिभाषा का पालन करेंगे, uidऔर cnजो अक्सर उपयोगकर्ता नाम को संग्रहीत कर रहे हैं उनके पास एक अलग स्कीमा गुण होता है, पूर्व के लिए असंवेदनशील लेकिन बाद के लिए संवेदनशील मामला। इसका मतलब है कि दोनों Abcऔर abcया मेल नहीं खा सकते abcLDAP सर्वर कॉन्फ़िगरेशन के आधार पर की प्रविष्टि।

इस असंगतता के कारण, मैं केवल उपयोगकर्ता नाम और होस्ट / डोमेन नाम दोनों के लिए लोअरकेस का उपयोग करने की सलाह दूंगा और फिर ssh ABC@SERVERNAME.DOMAIN.COMकिसी भी तरह असभ्य होने से बचूंगा।


1
इसलिए, जिस तरह से मैंने पोसिक्स मानक को पढ़ा है , क्योंकि यह मामला-संवेदी या असंवेदनशील के रूप में निर्दिष्ट नहीं है और संपूर्ण पोर्टेबल फ़ाइल नाम वर्ण सेट उपलब्ध है (जिसमें ऊपरी और निचले मामले दोनों शामिल हैं), यह कार्यान्वयन-निर्भर होगा। क्या वो सही है? कहा जा रहा है, क्या कोई मानक सम्मेलन है?
डग आर।

1
@DougR। जहां तक ​​POSIX का सवाल है, उपयोगकर्ता नाम केस डिपेंडेंट हैं। मामला असंवेदनशीलता अन्यथा निर्दिष्ट किया गया होता। पोर्टेबल फ़ाइल नाम वर्ण सेट का संदर्भ देते समय केस संवेदनशीलता का अर्थ है।
jlliagre

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

5

हाँ यह मामला संवेदनशील है। मैं तकनीकी जानकारी लाने में सक्षम नहीं हूं, मैंने अभी इसका परीक्षण किया है, और सोच रहा हूं कि आपने (?) क्यों नहीं किया?

मेरी स्थानीय मशीन लिनक्स टकसाल है जैसा कि आप देख सकते हैं:

# cat /etc/*release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.2
DISTRIB_CODENAME=rafaela
DISTRIB_DESCRIPTION="Linux Mint 17.2 Rafaela"
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
cat: /etc/upstream-release: Is a directory

और मैंने इस तरह CentOS सर्वर से जुड़ने की कोशिश की है:

(गलत) अपरकेस उपयोगकर्ता नाम का उपयोग करना:

8D prova # ssh Root@agora-server
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password: 

· सही उपयोगकर्ता नाम का उपयोग करना:

8D prova # ssh root@agora-server
root@agora-server's password: 
Last login: Fri Oct  2 01:50:13 2015 from 192.168.0.31
[root@agora-server ~]# 

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

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

3

स्थानीय खातों के मामले में उपयोगकर्ता नाम संवेदनशील है। जब आप LDAP का उपयोग करते हैं, तो यह निर्भर करता है। मैंने ऐसे मामलों को देखा है जहां उपयोगकर्ता नाम संवेदनशील है (एलडीएपी से जुड़े एक जेडएफएस उपकरण पर) और ऐसे मामले जिनमें विंडोज एडी से जुड़े सोलारिस एलडीएपी क्लाइंट की तरह कोई फर्क नहीं पड़ता।

आपको यह देखने की कोशिश करनी चाहिए कि आपका सिस्टम एलडीएपी जारी करके सही तरीके से उपयोग कर रहा है या नहीं getent passwd <username>। इस आदेश का उपयोग करके आपको निर्दिष्ट उपयोगकर्ता के लिए उपयोगकर्ता नाम, होम निर्देशिका और शेल के साथ एक रिकॉर्ड देना चाहिए। यदि आप ऐसा रिकॉर्ड नहीं देखते हैं, तो LDAP सही तरीके से कॉन्फ़िगर नहीं किया गया है।

कई जगह हैं जहां आपको LDAP को कॉन्फ़िगर करना चाहिए और एक जगह है:

/etc/nsswitch.conf

passwd: files ldap
group:  files ldap

आपको यह भी जांचना होगा कि क्या PAM सही तरीके से कॉन्फ़िगर किया गया है और शायद सबसे महत्वपूर्ण कदम यह सत्यापित करना है कि LDAP क्लाइंट कॉन्फ़िगर किया गया है और काम कर रहा है या नहीं। ldapsearchयह जाँचने के लिए एक टूल आज़माएं कि क्या LDAP को क्वेर किया जा सकता है।

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


1

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

कुछ उदाहरण निम्न हैं:

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

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

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


0

उपयोगकर्ता नाम निश्चित रूप से संवेदनशील हैं। आप समान नामों वाले दो उपयोगकर्ताओं को जोड़कर इसे आसानी से परख सकते हैं:

~ # useradd foobar
~ # useradd fooBar
~ # grep ^foo /etc/passwd
foobar:x:1001:1001::/home/foobar:/bin/sh
fooBar:x:1002:1002::/home/fooBar:/bin/sh

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.