Ssh कुंजी होस्ट द्वारा स्वीकार की जाती है, लेकिन क्लाइंट डिस्कनेक्ट हो जाता है

Question

नमस्कार,

फेडोरा 23 स्थापना के बाद मुझे एसएसएच के साथ एक समस्या है।

जब मैं अपने दूरस्थ होस्ट को निजी कुंजी के साथ कनेक्ट नहीं करना चाहता था तो मेरे मेजबान को कुंजी मिल गई:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

लेकिन जैसा कि आप देख रहे हैं कि मेरे ग्राहक इसे स्वयं काट रहे हैं

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

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

क्या तुम्हारे पास कोई विचार है ?

/ Etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

धन्यवाद

संपादित करें: मैं एक पासवर्ड से जुड़ सकता हूं

Comments

क्या आपने इस प्रश्नोत्तर को सर्वरफोल पर जांचा था ? हो सकता है कि यह आपकी छाया में एक त्रुटि हो ।conf

— हेनरिक

क्या आपको ऑडिट में कोई SELinux इनकार या SECCOMP संदेश दिखाई देता है? ausearch -m SECCOMPया ausearch -m AVC? हाल ही में कुछ बदलाव हुए थे जो कुछ सेटअप को प्रभावित कर सकते थे।

— जकूजी

हेलो, आपके सभी उत्तरों के लिए धन्यवाद, लेकिन मुझे पता नहीं चला कि क्या हुआ। मैं f22 को डाउनग्रेड करता हूं और अब यह काम करता है। आपका दिन शुभ हो

— Preovaleo

sshd में कोई लॉग?

— न्यूट्रिनस

यहां जो मुख्य चीज गायब है वह सर्वर से लॉग है। क्लाइंट लॉग कभी पूरी कहानी नहीं बता सकता। यदि आप प्रासंगिक सर्वर लॉग जोड़ते हैं, तो उत्तर प्राप्त करने की संभावना में काफी वृद्धि होगी।

— जेनी डी

Answer 1

सबसे पहले, सार्वजनिक कुंजी आधारित प्रमाणीकरण को सेटअप या कॉन्फ़िगर करने के तरीके के बारे में कई, बहुत अच्छी तरह से लिखे गए विस्तृत डॉक्यूमेंट ऑनलाइन उपलब्ध हैं। कृपया उनमें से किसी एक पर एक नज़र डालें और देखें कि क्या आपने सही तरीके से सब कुछ का पालन किया है। यहाँ एक है। इसलिए मैं फिर से दोहराने नहीं जा रहा हूं।

बहुत ही मूल अवधारणा है ( यहां से कॉपी की गई ):

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

अब आपके द्वारा पोस्ट किए गए डीबग लॉग से:

• ऐसा लगता है कि दो अलग-अलग उपयोगकर्ता शामिल हैं। /home/theo/.ssh/authorized_keysऔर /home/tbouge/.ssh/id_rsa। क्या आप एक उपयोगकर्ता के रूप में दूसरे उपयोगकर्ता के घर निर्देशिका में प्रवेश करने की कोशिश कर रहे हैं?
• त्रुटि का Postponed publickey for theo..अर्थ है कि अनचाहे प्रमाणीकरण विधि को पॉवेल कुंजी विधि से पहले आज़माया गया है। SSH एक के बाद एक, हर ऑटैटिगेशन मेथड को सक्षम करने की कोशिश करेगा। आपके मामले में आपने GSSAPIAuthentication yesसक्षम किया है कि आप क्या उपयोग नहीं कर रहे हैं। आप इसे सुरक्षित रूप से अक्षम कर सकते हैं GSSAPIAuthentication no।
• debug2: we did not send a packet, disable methodयह शायद सबसे महत्वपूर्ण है कि यह निजी कुंजी फ़ाइल (या तो फ़ाइल अनुमति या नाम समस्या) को संसाधित नहीं कर सकता है। SSH स्थानीय और दूरस्थ कंप्यूटर दोनों में निर्देशिका और फ़ाइल अनुमतियों के बारे में बहुत संवेदनशील है। ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys)। इसलिए, सुनिश्चित करें कि आपका सही ढंग से सेट है। इसे देखें: /unix/131886/ssh-public-key-wont-send-to-server

• तीसरी त्रुटि के लिए:, Permission denied (public key).जाँच करने के लिए कुछ चीज़ें हैं।

  • गलत उपयोगकर्ता नाम
  • गलत की-जोड़ी

  • गलत लक्ष्य मेजबान

    • यहाँ अधिक विवरण हैं: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance ।

निम्नलिखित भाग थोड़ा भ्रामक है:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

इसे बेहतर ढंग से समझने के लिए, डिजिटल तरीके से यहाँ बताए गए तरीके से ऑथेंटिकेशन प्रोसेस की प्रक्रिया से गुज़रें :

1. क्लाइंट कुंजी जोड़ी के लिए एक आईडी भेजकर शुरू करता है जिसे वह सर्वर के साथ प्रमाणित करना चाहता है।
2. सर्वर उस खाते की अधिकृत_की फ़ाइल की जाँच करता है जिसे ग्राहक कुंजी आईडी के लिए लॉग इन करने का प्रयास कर रहा है।
3. यदि फ़ाइल में मेल आईडी के साथ एक सार्वजनिक कुंजी मिलती है, तो सर्वर एक यादृच्छिक संख्या उत्पन्न करता है और संख्या को एन्क्रिप्ट करने के लिए सार्वजनिक कुंजी का उपयोग करता है।
4. सर्वर क्लाइंट को यह एन्क्रिप्टेड संदेश भेजता है।
5. यदि ग्राहक के पास वास्तव में संबद्ध निजी कुंजी है, तो वह मूल संख्या का खुलासा करते हुए, उस कुंजी का उपयोग करके संदेश को डिक्रिप्ट कर सकेगा।
6. क्लाइंट डिक्रिप्टेड संख्या को साझा सत्र कुंजी के साथ जोड़ती है जिसका उपयोग संचार को एन्क्रिप्ट करने के लिए किया जा रहा है, और इस मूल्य के एमडी 5 हैश की गणना करता है।
7. क्लाइंट तब इस एमडी 5 हैश को एन्क्रिप्टेड नंबर संदेश के जवाब के रूप में सर्वर पर वापस भेजता है।
8. सर्वर उसी साझा सत्र कुंजी और मूल संख्या का उपयोग करता है जिसे उसने क्लाइंट को MD5 मान की गणना करने के लिए भेजा था। यह अपनी गणना की तुलना उस ग्राहक से करता है जिसे क्लाइंट ने वापस भेजा है। यदि ये दोनों मान मेल खाते हैं, तो यह साबित होता है कि ग्राहक निजी कुंजी के कब्जे में था और ग्राहक प्रमाणित है।

आपके मामले में, जैसा कि आप देख सकते हैं, दूरस्थ कंप्यूटर ने केवल आपका स्वीकार किया है public key, उस कुंजी के साथ पैकेट को एन्क्रिप्ट किया है और इसे क्लाइंट कंप्यूटर पर वापस भेज दिया है। अब क्लाइंट कंप्यूटर को यह साबित करने की आवश्यकता है कि उसका अधिकार है private key। केवल सही निजी_के साथ यह हटाए गए संदेश को डिक्रिप्ट कर सकता है और एक उत्तर भेज सकता है। इस स्थिति में, क्लाइंट ऐसा करने में विफल हो रहा है और प्रमाणीकरण प्रक्रिया सफलता के बिना समाप्त हो गई है।

मुझे उम्मीद है कि इससे आपको मुद्दों को समझने और उन्हें हल करने में मदद मिलेगी।

Answer 2

क्या आपकी ssh फाइलों पर विशेषाधिकार सही हैं?

.ssh फ़ोल्डर -> 700

सार्वजनिक कुंजी -> 644

निजी कुंजी -> 600

उपयोगकर्ता और समूह की भी जाँच करें

Comments

आपके उत्तर के लिए धन्यवाद, लेकिन मैं पहले से ही है कि जाँच करें।

— प्रीवेलो

Answer 3

आप कहते हैं कि आपके पास एक विंडोज़ मशीन पर एक ही कुंजी है; क्या आप सुनिश्चित हैं कि आपके लिनक्स मशीन पर आपके पास मौजूद निजी कुंजी फ़ाइल सही है? शायद निजी कुंजी एक पोटीन प्रारूप में है जिसे ssh आसानी से समझ नहीं पाता है। किसी भी मामले में, यदि मैं गलत या अमान्य निजी कुंजी फ़ाइल डालता हूं, तो मुझे वही त्रुटि मिलती है जो आपके पास है।

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

Comments

आपके उत्तर के लिए धन्यवाद, लेकिन हाँ निजी कुंजी अच्छी है (मजेदार तथ्य: 1 घंटे यह जानने के लिए कि इसे पोटीन में कैसे उपयोग किया जाए)।

— प्रीवैलो

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

— कानून

Answer 4

आपकी समस्या बहुत आम है और यह भी स्पष्ट है कि मैंने कहा है।

 Permission denied (publickey).

क्या इससे आपको कोई मतलब है? मेरे लिए यह मेरे लिए बहुत मायने रखता है।

यदि आप लागू मोड में selinux runnin है, तो क्या आप सर्वर की तरफ देख सकते हैं? अगर मुझे नहीं बताया जाए कि सेलिनक्स किस मोड पर चल रहा है।

इसके अलावा, यदि आप एक और प्रयास कर सकते हैं और उस प्रयास के ऑडिट लॉग पर कब्जा कर सकते हैं और यहां पोस्ट करें तो यह हमें निश्चित रूप से बताएगा कि क्यों:

  tail -f /var/log/audit/audit.log  (and try to attempt)

यह अनुमति समस्या है जो स्पष्ट है लेकिन अनुमति फ़ाइल नहीं है :-)

Comments

+1 इसे RHEL7.1 सेटअप पर भी देखें। कृपया विस्तार करें audit2allow:)

— kubanczyk

Answer 5

ऐसा लगता है कि समस्या (मेरे मामले में ...) कुंजी के प्रकार के कारण थी।

मैंने अभी इसे स्थानीय ~/.ssh/configफ़ाइल (फेडोरा 23 क्लाइंट मशीन) में निम्नलिखित जोड़कर हल किया है :

PubkeyAcceptedKeyTypes=+ssh-dss

हालाँकि मैंने उस लाइन को सर्वर और क्लाइंट कॉन्फ़िगर फ़ाइल दोनों में जोड़ा है, केवल क्लाइंट पक्ष ने अंतर बनाया है। ध्यान दें कि 600पठन फ़ाइल को पढ़ने के लिए अनुमतियों का होना आवश्यक है।

Comments

यह मामला नहीं है। प्रश्न में है, कि कुंजी आरएसए है।

— जकूजी

@ जाकुजे हां, ऐसा लगता है, मैंने गौर नहीं किया। खैर, शायद यह अन्य लोगों की मदद करता है क्योंकि मुझे कल अपग्रेड करने के बाद सटीक समस्या थी।

— जेरोन

@jeroen, डिफ़ॉल्ट रूप से यह rsaकुंजी का उपयोग करता है । फेडोरा रेफ को यहां देखें , जब तक कि इसे अनुकूलित न किया जाए। बेशक कोई भी चुन सकता है कि किस प्रकार की कुंजी को कॉन्फ़िगर और उपयोग करना है।

— हीरा

@ जेरोइन आगे के परीक्षण में मैं इसकी सिफारिश नहीं करता; सूक्ति-कीरिंग-डेमन $ HOME / .sh / id_ecdsa फाइलें नहीं उठाता है, दुर्भाग्य से, इसलिए उन कुंजियों को अनलॉक नहीं किया जाएगा और सत्र के ssh- एजेंट को स्वतः लॉगिन पर जोड़ा जाएगा। वैसे भी, मैंने अपने सर्वर को F23 में अपग्रेड किया है, और RSA कुंजियों का उपयोग करके इसके और शेष F22 क्लाइंट (दोनों दिशा में) के बीच कोई समस्या नहीं है। हालांकि ECSDA कुंजी मेरे एक लैपटॉप के लिए एक वर्कअराउंड प्रदान करता है, जिसे इसकी आवश्यकता होती है (जहां RSA कुंजियों का उपयोग करने का कोई भी प्रयास विफल रहता है), रूट समस्या कुछ और प्रतीत होती है।

— FeRD

उपयोगी उत्तर के लिए धन्यवाद। ध्यान दें कि आपको सर्वर पर समान परिवर्तन करने की आवश्यकता होगी, अगर सर्वर को ओपनएसएसएच 7.0 या नए (जैसे अगर यह फेडोरा 23 या उच्चतर में अपग्रेड किया गया है) में अपग्रेड किया गया है। सुपरसर्वर . com/q/1016989/93541 देखें ।

— डीडब्ल्यू

Answer 6

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

मुद्दा, जैसा कि यह पता चला है, एसएसएच के साथ (मेरे लिए) बिल्कुल नहीं था, लेकिन पीएएम मेरी कुंजी को कैसे कॉन्फ़िगर कर रहा था। कॉन्फ़िगरेशन /etc/pam.dपुराना था (हालांकि यह फेडोरा 22 के माध्यम से ठीक से काम कर रहा था), और इसके परिणामस्वरूप मेरी चाबियों को लेने के लिए लॉगिन [अब] पर सही चीजें नहीं हो रही थीं $HOME/.ssh/। इस कमांड को चलाना:

# sudo authconfig --updateall

/etc/pam.d कॉन्फ़िगरेशन को ठीक से पुनर्निर्माण करें। अगले रिबूट पर, मैंने लॉग इन करने के बाद, पहली बार मैंने अपने सर्वर से बाहर जाने की कोशिश की, एक संवाद बॉक्स ने मुझे मेरी ssh कुंजी ( $HOME/.ssh/id_rsa) के लिए अपना पासफ़्रेज़ दर्ज करने के लिए कहा । मैंने ऐसा किया, "लॉगिन पर स्वचालित रूप से अनलॉक करें" बॉक्स, और वॉइला की जांच की! लैपटॉप से ​​बाहर निकालने की मेरी क्षमता बहाल हो गई।

पृष्ठभूमि

सुराग जो मुझे इसे हल करने के लिए ले गया था जब मैं एक बाहरी स्रोत से आरएसए कुंजी आयात करता था। (एक USB कुंजी मैं चारों ओर ले जाने के लिए, मेरे घर नेटवर्क के लिए मेरे "दूरस्थ पहुंच" कुंजी के साथ। मैं PasswordAuth बंद मेरी जावक का सामना करना पड़ सर्वर साल के लिए पहले एक घुसपैठ के बाद बदल गया।) के बाद ssh-addआईएनजी कि RSA कुंजी, एक में बैठे विपरीत $HOME/.ssh/id_rsa, यह दूरस्थ सर्वर द्वारा समस्या के बिना स्वीकार किया गया था।

फिर मैं समाप्त करने के लिए क्या अतिरेक करना चाहिए था, समाप्त कर ssh-addदिया $HOME/.ssh/id_rsa। मैंने देखा है कि के बाद मुझे लगता है कि कुछ किया था, ssh-add -lनिहित दो एक ही कुंजी के लिए प्रविष्टियों:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

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

मुझे विश्वास है कि वास्तव में यही हो रहा था, और PAM SSH एजेंट को "खराब कुंजी" दे रहा था जिसे पासफ़्रेज़ के साथ अनलॉक नहीं किया गया था। इसलिए, जब ssh ने कुंजी के साथ प्रमाणित करने का प्रयास किया, तो उसमें वास्तव में कुंजी जोड़े का निजी आधा हिस्सा (खुला) नहीं था, और इसलिए प्रमाणीकरण विफल हो गया।

कि अंतिम बिट अनुमान है, लेकिन अगर किसी को भी ssh कीज़ की समस्या है, जिसे दूरस्थ होस्ट द्वारा स्वीकार नहीं किया जा रहा है (जहाँ वे इस्तेमाल किया जा रहा था) F23 में अपग्रेड होने के बाद, /etc/pam.d/डायरेक्ट्री का उपयोग करके पुनर्निर्माण करना authconfigएक समाधान के रूप में प्रयास करने के लायक है।

Answer 7

उपयोगकर्ता होम निर्देशिका अनुमतियों की जाँच करें। यह महत्वपूर्ण है। 755 होना चाहिए। 700 या 770 काम नहीं करेगा।

Answer 8

अपने में ssh_config, uncommenting और / या जोड़ने / हटाने के / या तो करने के लिए जोड़कर कोशिश Cipher, Ciphersया MACsलाइन (रों)।

यह मेरे लिए प्रकट होता है जो sshdकिसी प्रकार के विशेष सिफर की तलाश करता है जिसे अनुरोध में शामिल नहीं किया जा रहा है, जिसे आपके द्वारा कॉन्फ़िगर करके जोड़ा जा सकता है ssh_config।

... और मुझे लगता है कि आप किसी भी मौका द्वारा दूरस्थ सर्वर पर PubkeyAuthenticationसेट नहीं हैं no, क्योंकि यह निश्चित रूप से विफल होने का कारण होगा।