सवाल keytab फ़ाइल krb5.keytab पढ़ने में त्रुटि


मैंने एसईएलएस 11.2 और CentOS 6.3 दोनों पर इन केर्बेरोस कीटैब त्रुटि संदेशों को देखा है:

sshd[31442]: pam_krb5[31442]: error reading keytab 'FILE: / etc/ krb5. keytab'

/etc/krb5.keytab हमारे मेजबानों पर मौजूद नहीं है, और जो कि मैं कीटैब फ़ाइल के बारे में समझता हूं, हमें इसकी आवश्यकता नहीं है। प्रति यह केर्बेरोज keytab परिचय:

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

ऐसा कुछ ऐसा लगता है जिसकी हमें आवश्यकता नहीं है और शायद यह नहीं है कि यह सुरक्षा के लिए बेहतर है।

मैं इस त्रुटि को हमारे सिस्टम लॉग में पॉप-अप करने से कैसे रोक सकता हूं? यहां मेरा krb5.conf है यदि यह उपयोगी है:

banjer@myhost:~> cat /etc/krb5.conf
# This file managed by Puppet
#
[libdefaults]
        default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
        default_realm = FOO.EXAMPLE.COM
        dns_lookup_kdc = true
        clockskew = 300

[logging]
        default = SYSLOG:NOTICE:DAEMON
        kdc = FILE:/var/log/kdc.log
        kadmind = FILE:/var/log/kadmind.log

[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        retain_after_close = false
        minimum_uid = 0
        debug = false
        banner = "Enter your current"
}

अगर आपको किसी अन्य कॉन्फ़िगरेशन को देखने की ज़रूरत है तो मुझे बताएं। धन्यवाद।

संपादित करें

यह संदेश दिखाता है /var/log/secure जब भी एक गैर रूट उपयोगकर्ता एसएसएच या कंसोल के माध्यम से लॉग इन करता है। ऐसा लगता है कि केवल पासवर्ड-आधारित प्रमाणीकरण के साथ होता है। यदि मैं किसी सर्वर पर कुंजी-आधारित एसएसएच करता हूं, तो मुझे त्रुटि दिखाई नहीं देती है। अगर मैं रूट के साथ लॉग इन करता हूं, तो मुझे त्रुटि दिखाई नहीं देती है। हमारे लिनक्स सर्वर सक्रिय निर्देशिका के खिलाफ प्रमाणित करते हैं, इसलिए यह उपयोगकर्ता को प्रमाणीकृत करने के लिए उपयोग किए जाने वाले पीएएम, सांबा, केर्बेरोस और विनबिंड का एक हार्दिक मिश्रण है।


5
2017-11-08 14:21


मूल


क्या यह तब होता है जब आप sshd को पुनरारंभ करते हैं या जब आप ssh पर लॉगिन करने का प्रयास करते हैं? जब आप कंसोल से लॉग इन करते हैं तो क्या आप संदेश भी देखते हैं? - chutz
@chutz मैंने अपने प्रश्न के लिए कुछ और जानकारी जोड़ा। - Banjer


जवाब:


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

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

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

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


4
2018-04-22 20:03





कीटैब सत्यापन को अक्षम करने के लिए और इसलिए इन लॉग संदेशों को दबाएं, जोड़ें no_validate आपके पीएएम सेटिंग्स के लिए विकल्प। उदाहरण के लिए:

auth        sufficient    pam_krb5.so use_first_pass no_validate

मेरे CentOS 6 सर्वर पर, मैंने कहीं भी यह परिवर्तन किया है pam_krb5.so इन दो फाइलों में संदर्भित किया जा रहा है:

/etc/pam.d/password-auth-ac
/etc/pam.d/system-auth-ac

मुझे यकीन है कि एसएलएस समान है, लेकिन हम उस ओएस को चरणबद्ध कर रहे हैं, इसलिए मैं वहां परीक्षण करने की योजना नहीं बना रहा हूं।


1
2017-07-17 13:42





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


1
2018-04-22 18:40





यह एक पुराना हो सकता है, लेकिन मुझे एक ही समस्या थी और संदेश से छुटकारा पाना चाहता था। मैंने आर्कलिंक्स से इन निर्देशों का पालन किया और इसे हल किया।

https://wiki.archlinux.org/index.php/Active_Directory_Integration#Creating_a_machine_key_tab_file

बस इसमें टाइप किया गया:

net ads keytab create -U administrator

हालांकि, यह आपके सेटअप पर निर्भर हो सकता है।


1
2017-10-26 07:37





जैसा कि @ रायन-फिशर ने अपने जवाब में उल्लेख किया है, होस्ट को प्रीथ के लिए टीजीटी पुनर्प्राप्त करने में सक्षम होने के लिए एक कीटैब फ़ाइल की आवश्यकता है।

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

अब, आपको यह सुनिश्चित करने के लिए क्या करना है /etc/krb5.keytab प्रिंसिपल के लिए चाबियाँ शामिल हैं host/domain.name.of.host मशीन के लिए मान लें कि रिवर्स डीएनएस सही ढंग से स्थापित है, फिर आप एक वैध टीजीटी मानते हुए पासवर्ड टाइप किए बिना एसएसएच का उपयोग करके लॉग इन करने में सक्षम होंगे।


0
2017-11-22 02:32



पहला वाक्य सादा गलत है। मेजबान टीजीटी प्राप्त नहीं करता है। उपयोगकर्ता एक टीजीटी प्राप्त करता है। प्रीथ के लिए भी एक टीजीटी का उपयोग नहीं किया जाता है। इसके बजाय, एक टीजीटी प्राप्त करने के लिए पूर्व प्रमाणीकरण की आवश्यकता हो सकती है। देख kerberos.org/software/tutorial.html - Ryan