सार्वजनिक कुंजी प्रमाणीकरण विफल रहता है केवल जब sshd डेमॉन है

Question

मेरा कोई सुराग नहीं है कि यह कैसे होता है। डिस्ट्रो साइंटिफिक लिनक्स 6.1 है और सब कुछ सार्वजनिक कुंजी के माध्यम से प्रमाणीकरण करने के लिए स्थापित किया गया है। फिर भी, जब sshd एक डेमॉन (सेवा sshd प्रारंभ) के रूप में चल रहा है, तो यह सार्वजनिक कुंजी स्वीकार नहीं करता है। (लॉग के इस टुकड़े को प्राप्त करने के लिए, मैंने -dd विकल्प जोड़ने के लिए sshd स्क्रिप्ट को बदल दिया है)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

यदि sshd को डिबग मोड में चलाया जाता है /usr/sbin/sshd -ddd, तो प्रमाणीकरण आकर्षण की तरह काम करता है:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

कोई विचार?? किसी ने भी इस तरह से कुछ भी देखा है?

टिप्पणियाँ:

फ़ाइल अनुमतियां डबल जाँच की गई हैं:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

मुझसे पूछा गया कि क्या sshd "डेमन मोड" में रूट की फाइलों तक पहुँच सकता है। इस सवाल का सबसे करीबी जवाब है:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

यदि sshd रूट के रूप में चल रहा है, तो मुझे नहीं पता कि इसकी अपनी फ़ाइलों को एक्सेस करना कैसे संभव नहीं है। क्या SELinux इसका कारण हो सकता है?

Comments

क्या sshd init स्क्रिप्ट कुछ दिलचस्प करती है? (क्या आपको /etc/init.d/sshd?) होना चाहिए जो आप कमांड लाइन पर नहीं कर रहे हैं? 'सेवा sshd प्रारंभ' के बजाय 'sh -x /etc/init.d/ssh start' आज़माएँ।

— पीटी

Answer 1

हां, SELinux संभावना का कारण है। .sshDir शायद गलत लेबल है। को देखो /var/log/audit/audit.log। इसे लेबल किया जाना चाहिए ssh_home_t। के साथ जाँच करें ls -laZ। restorecon -r -vv /root/.sshजरूरत हो तो चलाएं ।

Comments

हां, SELinux इसका कारण था: टाइप = AVC msg = ऑडिट (1318597097.413: 5447): avc: pid = 19849 कॉम = "sshd" नाम = "अधिकृत" = "inm = dm-0 ino = 262398 scontext = unconfined_u" के लिए {read} से इनकार किया। : system_r: sshd_t: s0-s0: c0.c1023 tcontext = unconfined_u: object_r: admin_home_t: s0 tclass = file यह "restorecon -r -vv /root/.ssh" को चलाने के बाद काम करता है। बहुत बहुत धन्यवाद।

— user666412

धन्यवाद धन्यवाद कमांड लाइन लाइन के लिए धन्यवाद, मैं उम्र के लिए खोजने की कोशिश कर रहा था कि मैं अपने redhat एंटरप्राइज़ के लिए रूट के रूप में ssh क्यों कर सकता था। 6.2 ssh कुंजी प्रमाणीकरण का उपयोग कर सर्वर, लेकिन मैं एक गैर-रूट उपयोगकर्ता के रूप में ssh नहीं कर सका पासवर्ड डाले बिना। "ssh -v" कुछ भी असामान्य नहीं दर्शाता है। मैंने /home/example/.ssh पर फ़ाइल सुरक्षा की जाँच और पुनरावृत्ति की, यह तब तक नहीं हुआ जब तक मैं नहीं भागा "/ usr / sbin / sshd -d" और किसी कारण से जो सामान्य रूप से काम करता था कि मुझे एहसास हुआ कि कुछ और हो रहा है, और एक अलग Google खोज की कोशिश की और यह पाया। इसलिए, लक्षण थे कि मैं रो के रूप में ssh कर सकता हूं

— पॉल एम

मुझे यह पूरे फाइलसिस्टम यानी restorecon -r /YMMV पर करना था।

— इरफी

मैंने यह कोशिश की - लेकिन फिर भी काम नहीं कर रहा है। ऑडिट लॉग में मेरे पास type=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dirयह निश्चित नहीं है कि इसका क्या मतलब है

— येहोसेफ

जवाब में था name="/"- मुझे restorecon -r /@Irfy के सुझाव के अनुसार चलना था।

— येहसेफ

Answer 2

मेरी भी यही समस्या थी। मेरे मामले में, रिस्टोरॉन और चोंक ने काम नहीं किया।

मैं सेलिनक्स को निष्क्रिय नहीं करना चाहता था। बहुत खोजबीन के बाद, मैंने आखिरकार यह समझ लिया क्योंकि मेरे घर की निर्देशिका कहीं और (एनएफएस) से मुहिम शुरू की गई थी। मुझे यह बग रिपोर्ट मिली जिसने मुझे अंदर खींच लिया।

मैं भागा:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

use_nfs_home_dirs की पुष्टि करने के लिए बंद था और फिर:

sudo setsebool -P use_nfs_home_dirs 1

चालू करना।

अब मैं अपनी कुंजी का उपयोग करके और पासवर्ड दर्ज किए बिना अपनी मशीन को भेज सकता हूं। उपयोग के लिए टॉगल करना_होम_नफर्स_बुलियन जो मेरे लिए था।

Answer 3

मार्क वैगनर के जवाब में जोड़ने के लिए, यदि आपका कस्टम होम डायरेक्टरी पाथ (यानी नहीं /home) का उपयोग कर रहे हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि आपने SELinux सुरक्षा संदर्भ सेट किया है। ऐसा करने के लिए, यदि आपके पास उपयोगकर्ता होम निर्देशिकाएं हैं, उदाहरण के लिए /myhome, चलाएँ:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

Comments

यदि आप CentOS पर हैं, तो आपको पाने के लिए इसे चलाना होगा semanage:sudo yum install policycoreutils-python

— sm4rk0

Answer 4

ऐसा लगता है कि आप कनेक्शनों का परीक्षण करते समय विभिन्न कुंजियों का उपयोग करते हैं, 0x7f266e1a8840 बनाम 0x7f85527ef230। 'Ssh -v example.com' का उपयोग करके sshd को डेमॉन और डिबग मोड में जोड़ने का प्रयास करें और स्ट्रिंग के आसपास ssh द्वारा उपयोग की जाने वाली कुंजियों की तलाश करें "RSA सार्वजनिक कुंजी की पेशकश"।

Comments

हाँ, id_rsa और id_dsa थे। DSA कुंजी चली गई है और मैं परीक्षण को फिर से करूँगा।

— user666412

debug3: mm_answer_keyallowed: key 0xFFFFFFFFFFहर बार sshd को एक नया कनेक्शन प्राप्त होने के समय में उल्लिखित मूल्य बदल जाएगा। इसे कन्फर्म करने के लिए, एक सर्वर ढूंढें जहाँ SSH काम करता है, sshd LOGLEVEL को डीबग 3 में क्रैंक करें, sshd को पुनरारंभ करें, रन करें tail -f /var/log/secure |grep mm_answer_keyallowedऔर फिर कुछ समय में लॉग करें, प्रत्येक कनेक्शन के बीच कुछ सेकंड (या मिनट) प्रतीक्षा करें। आप देखेंगे कि मूल्य हर बार बदलता है। और वास्तव में यह मेरे लिए एक काउंटर की तरह दिखता है।

— स्टीफन लासिवस्की