सार्वजनिक कुंजी को ~ / .ssh / अधिकृत_की में जोड़ना मुझे अपने आप लॉग इन नहीं करता है

Question

मैंने अधिकृत SS_ कुंजी को public_keys फ़ाइल में जोड़ा है । ssh localhostपासवर्ड मांगे बिना मुझे लॉग इन करना चाहिए।

मैंने ऐसा किया और टाइप करने की कोशिश की ssh localhost, लेकिन यह अभी भी मुझे पासवर्ड टाइप करने के लिए कहता है। वहाँ एक और सेटिंग है कि मैं इसे काम करने के लिए के माध्यम से जाना है?

मैंने अनुमतियाँ बदलने के निर्देशों का पालन किया है:

नीचे परिणाम है अगर मैं करता हूँ ssh -v localhost।

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

फिर यह उपर्युक्त लॉग के बाद एक पासपेस मांगता है। यह बिना पासवर्ड के मुझे लॉग इन क्यों नहीं कर रहा है?

Comments

हालांकि यहां ऐसा नहीं है, यदि आप Google से आ रहे हैं और आप एक एन्क्रिप्टेड होम डायरेक्टरी का उपयोग कर रहे हैं, तो sshd इसे एक्सेस नहीं कर पाएगा, और इसलिए आपकी अधिकृत_की फ़ाइल को पढ़ने में सक्षम नहीं होगा। यहाँ एक समाधान है: Bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/…

— डैनियल

Answer 1

आपको authorized_keysफ़ाइल और फ़ोल्डर / पैरेंट फ़ोल्डर की अनुमतियों को सत्यापित करने की आवश्यकता है जिसमें यह स्थित है।

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

अधिक जानकारी के लिए यह पृष्ठ देखें ।

समूह और अन्य लोगों के लिए लेखन पहुंच को हटाने के लिए आपको अपने घर निर्देशिका की अनुमतियों को बदलने / सत्यापित करने की भी आवश्यकता हो सकती है।

chmod go-w ~

Comments

अच्छी तरह से ऊपर काम में कुछ है, हालांकि "chmod -R go-wrx foobar" नहीं बल्कि नाटकीय है? पुनरावर्ती की आवश्यकता क्यों है?

— जोकिम

दूसरे भाग के लिए, इसे पुनरावर्ती बनाने के लिए यह अनिवार्य नहीं है, बस करना chmod go-wrx foobarपर्याप्त है। यदि आप कुछ समूह या फ़ाइलों तक अन्य पहुंच रखते हैं, तो इसे पुन: गंभीरता से कर सकते हैं, खासकर अगर यह एक वेब निर्देशिका है।

— स्टिंगेयब जुले

जैसा कि ओपनएसएसएच एफएक्यू पर उल्लेख किया गया है, उपयोगकर्ता के घर और एसएसटी निर्देशिका को केवल समूह / अन्य के लिए हटाए जाने की अनुमति लिखने की आवश्यकता होती है (इसलिए chmod go-w $HOME $HOME/.sshयह चाल चलेगा)। इस प्रकार, अनुमतियां दोनों निर्देशिकाओं के लिए 755 के रूप में 'खुली' हो सकती हैं, यदि आप बहुत इच्छुक हैं। : सरल / कम से कम आक्रामक आदेशों पूछे जाने वाले प्रश्न में हैं openssh.org/faq.html#3.14

— davidjb

जब तक मैंने ऐसा नहीं किया मेरे लिए यह काम क्यों नहीं करेगा chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys? 600 काम नहीं किया जहां 644 किया ...

— ficuscr

मुझे इसकी आवश्यकता भी थी sudo chown -R {$USER}:{$USER} ~/.ssh/क्योंकि मैंने authorized_keysफ़ाइल को रूट के रूप में लिखा था ।

— ज़ेन हूपर

Answer 2

SELinux भी अधिकृत_की वजह से काम नहीं कर सकता है। विशेष रूप से रूट के लिए CentOS 6 और 7. हालांकि इसे अक्षम करने की आवश्यकता नहीं है। एक बार जब आप सत्यापित कर लेते हैं कि आपकी अनुमतियां सही हैं, तो आप इसे ठीक कर सकते हैं:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

Comments

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

— ओस्पाल

यहां एक और खुश टूरिस्ट।

— आरएचईएल

9/10 बार, "यह काम क्यों नहीं कर रहा है, यह हमेशा काम करता है" मुद्दा एक सेलिनक्स मुद्दा है।

— एंड्रयू व्हाइट

1and1 (1und1) सर्वर पर मेरे लिए समस्या तय की

— संगीतकार 18

Answer 3

ssh अधिकृत_की सेटिंग करना आसान प्रतीत होता है, लेकिन कुछ ट्रैप्स को छुपाता है जिन्हें मैं जानने की कोशिश कर रहा हूं

- सर्वर -

में / etc / ssh / sshd_configpasswordAuthentication yes सर्वर अस्थायी पासवर्ड पासवर्ड प्रमाणीकरण स्वीकार करने के लिए सेट

- ग्राहक -

cygwin को linux emulation मानते हैं और opensh को install & run करते हैं

1. निजी और सार्वजनिक कुंजी उत्पन्न करें (ग्राहक पक्ष) # ssh-keygen

यहाँ सिर्फ एंटर करने पर आपको DEFAULT 2 फाइलें " id_rsa " और " id_rsa.pub " ~ / .ssh / में मिलती हैं , लेकिन यदि आप एक name_for_the_key देते हैं तो जनरेट की गई फाइलें आपके pwd में सेव हो जाती हैं।

2. जगह your_key.pub लक्ष्य मशीन के लिएssh-copy-id user_name@host_name

यदि आपने डिफ़ॉल्ट कुंजी नहीं बनाई है तो यह गलत होने का पहला कदम है ... आपको इसका उपयोग करना चाहिए

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. लॉगिंग ssh user_name@host_nameकेवल डिफॉल्ट id_rsa के लिए काम करेगी इसलिए यहां आपको 2 ट्रैप की जरूरत हैssh -i path/to/key_name user@host

( ssh -v का उपयोग करें ... विकल्प यह देखने के लिए कि क्या हो रहा है)

अगर सर्वर अभी भी पासवर्ड मांगता है तो आपने smth दिया। पासफ़्रेज़ दर्ज करने के लिए : जब आपने चाबियाँ बनाई हैं (तो यह सामान्य है)

अगर ssh डिफ़ॉल्ट पोर्ट नहीं सुन रहा है तो 22 का उपयोग करना चाहिए ssh -p port_nr

- सेवर -----

4. संशोधित / आदि / ssh / sshd_config है

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(मामला होने पर असहज)

यह ssh को अधिकृत_कीप्स स्वीकार करने और उपयोगकर्ता होम डायरेक्टरी में key_name स्टिंग के लिए .ssh / अधिकृत_कुंजी फ़ाइल में देखने के लिए कहता है।

लक्ष्य मशीन में 5 सेट अनुमतियाँ

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

पास ऑर्ट को भी बंद कर दें

passwordAuthentication no

सभी ssh रूट / व्यवस्थापक /....@ your_domain प्रयासों के लिए गेट बंद करना

6 सुनिश्चित करें कि सभी गैर-रूट होम निर्देशिकाओं का स्वामित्व और समूह स्वामित्व उपयुक्त हो।

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. उत्कृष्ट http://www.fail2ban.org पर विचार करें

8. अतिरिक्त ssh TUNNEL एक MySQL (bind = 127.0.0.1) को एक्सेस करने के लिए गंभीर है

Comments

ध्यान दें कि "सिर्फ 4 सुरक्षा" केवल सुरक्षा के लिए नहीं है! SSH फ़ाइल को अनदेखा करेगा यदि इसमें प्रतिबंधात्मक अनुमति नहीं है।

— नवीन

स्वामित्व सुनिश्चित करना इस सूची के लिए एक बढ़िया अतिरिक्त होगा

— steviejay

मुझे इसके बारे में कोई पता नहीं था ssh-copy-id! वह कदम अकेले ही बहुत अच्छा जवाब देता।

— जेम्स मार्बल

chmod 755 ~ / .ssh 700 के बजाय जो मुझे कहीं और दिख रहा है वह करने के लिए लगता है

— जिम डब्ल्यू का कहना है कि मोनिका

Answer 4

यह भी सुनिश्चित करें कि आपके घर की निर्देशिका दूसरों द्वारा लिखी जाने योग्य नहीं है

chmod g-w,o-w /home/USERNAME

उत्तर यहाँ से चोरी हो जाता है

Comments

करना chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~मेरे लिए काम कर गया । धन्यवाद।

— गबराद

सिर्फ chmod og-w /home/USERNAMEइसके बजाय उपयोग क्यों नहीं ?

— परमवीर सिंह करवाल

Answer 5

हताश यह भी सुनिश्चित कर सकते हैं कि id_rsa.pub पाठ को एक भ्रमित टर्मिनल से बाहर कॉपी करने के कारण अधिकृत_की फ़ाइल में उनके पास अतिरिक्त newlines नहीं है।

Comments

मेरे साथ ठीक ऐसा ही हुआ है! दो टर्मिनल एक ही चौड़ाई के हैं इसलिए यह पता लगाना मुश्किल है कि जब तक मैं अधिकृत संख्या में दो पंक्तियों को देखने के लिए लाइन नंबरों को चालू नहीं करता।

— शॉन

इस। मैंने इसके कारण सिर्फ एक घंटा बर्बाद किया। और यह पहली बार नहीं है। @ bortunac के उत्तर में ssh-copy-id टूल का उल्लेख है, जिसका उपयोग मैं भविष्य में इससे बचने के लिए करूंगा।

— xhhmoore

मुझे इसके बजाय id_rsa.pubउपयोग moreकरने की सामग्री मिली cat, जो कि अदृश्य लाइनब्रेक के कारण घातक थी।

— डैन हैल्बर्ट

Answer 6

उपयोगकर्ता आपका उपयोगकर्ता नाम है

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Comments

रूट के लिए बेहतर:mkdir -p /home/$USER/.ssh && chown -R $USER:$USER /home/$USER/.ssh && sudo -u $USER ssh-keygen -t rsa && touch /home/$USER/.ssh/authorized_keys && touch /home/$USER/.ssh/known_hosts && chmod 700 /home/$USER/.ssh && chmod 600 /home/$USER/.ssh/id* && chmod 644 /home/$USER/.ssh/id*.pub && chmod 644 /home/$USER/.ssh/authorized_keys && chmod 644 /home/$USER/.ssh/known_hosts && vim /home/$USER/.ssh/authorized_keys # paste keys here!

— ओडीसियस

Answer 7

सावधान रहें कि SELinux इस त्रुटि को ट्रिगर कर सकता है, भले ही सभी अनुमतियाँ ठीक लगती हों। इसे अक्षम करने ने मेरे लिए चाल चली (इसे अक्षम करने के बारे में सामान्य अस्वीकरण डालें)।

Comments

आप SELinux को दखल देते हुए देख सकते हैं /var/log/audit/audit.log। restorecon -R -v /root/.sshमेरा विशिष्ट मामला तय किया।

— डेव गुडेल

Answer 8

सार्वजनिक कुंजी को .sh / अधिकृत_कीप में सूचीबद्ध करना आवश्यक है, लेकिन इसे स्वीकार करने के लिए sshd (सर्वर) के लिए पर्याप्त नहीं है। यदि आपकी निजी कुंजी पासफ़्रेज़-संरक्षित है, तो आपको हर बार ssh (क्लाइंट) पासफ़्रेज़ देने की आवश्यकता होगी। या आप ssh-agent का उपयोग कर सकते हैं , या GNOME समकक्ष का ।

आपका अपडेट किया गया ट्रेस पासफ़्रेज़-रक्षित निजी कुंजी के अनुरूप है। Ssh-एजेंट, या उपयोग देखें ssh-keygen -p।

Answer 9

कमांड लिखें:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

ऐसा करने के बाद, सुनिश्चित करें कि आपका डायर ऐसा है:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

Comments

आपका उत्तर स्वीकार किए गए के साथ अलग कैसे है? आपने इसे 3 साल बाद अपने Ctrl + C Ctrl-V कमांड का उपयोग करके लिखा है?

— स्टिंगर

Answer 10

मेरे लिए चाल ने आखिरकार यह सुनिश्चित कर दिया कि मालिक / समूह जड़ नहीं बल्कि उपयोगकर्ता थे:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

Comments

chown: अमान्य उपयोगकर्ता: '/ home/lsa/.ssh/'

— Stepan Yakovenko

Answer 11

"Ssh-add" का प्रयास करें जो मेरे लिए काम किया।

Answer 12

याद करने के लिए एक और टिप। चूंकि v7.0 ओपनएसएसएच डीएसएस / डीएसए ssh कीज़ को डिफ़ॉल्ट रूप से उनकी अंतर्निहित कमजोरी के कारण निष्क्रिय कर देता है । इसलिए यदि आपके पास OpenSSH v7.0 + है, तो सुनिश्चित करें कि आपकी कुंजी नहीं है ssh-dss।

यदि आप DSA कुंजी के साथ फंस गए हैं, तो आप अपनी लाइनों sshd_configऔर ~/.ssh/configफ़ाइलों को इस तरह से अद्यतन करके स्थानीय रूप से समर्थन को फिर से सक्षम कर सकते हैं :PubkeyAcceptedKeyTypes=+ssh-dss

Answer 13

मेरे मामले में मुझे अपनी authorized_keysफ़ाइल डालने की आवश्यकता थी.openssh ।

यह स्थान /etc/ssh/sshd_configविकल्प के तहत निर्दिष्ट किया गया है AuthorizedKeysFile %h/.ssh/authorized_keys।

Comments

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

— क़ुइनिल

Answer 14

सुनिश्चित करें कि लक्ष्य उपयोगकर्ता के पास एक पासवर्ड सेट है। passwd usernameएक सेट करने के लिए चलाएँ । पासवर्ड SSH लॉगिन अक्षम होने पर भी मेरे लिए यह आवश्यक था।

Answer 15

यह मेरी समस्या का हल करता है

ssh- एजेंट बैश

ssh-ऐड

Comments

कृपया बताएं कि यह क्या करता है।

— lyuboslav kanev

Ssh- एजेंट आपकी ssh कुंजियाँ संग्रहीत करता है..आदेश bash अपने शेल का एक नया उदाहरण शुरू करता है। और ssh-add आपकी कुंजियों को अनलॉक करता है और उन्हें लोड करता है

— Julian

Answer 16

एक और मुद्दा आपको ध्यान रखना होगा। यदि आपकी जनरेट की गई फ़ाइल डिफ़ॉल्ट नहीं है id_rsa और id_rsa.pub

आपको .ssh / config फाइल बनानी होगी और मैन्युअल रूप से परिभाषित करना होगा कि आप किस आईडी फाइल को कनेक्शन के साथ उपयोग करने जा रहे हैं।

उदाहरण यहाँ है:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

Comments

IdentityFile की निजी कुंजी होनी चाहिए

— Ken H

@ हाँ हाँ ज़रूर। टाइपो है। उसके लिए खेद है।

— कुंथेर

Answer 17

मैंने जारी किया sudo chmod 700 ~/.sshऔरchmod 600 ~/.ssh/authorized_keys और chmod go-w $HOME $HOME/.sshऊपर से है और यह एक CentOS7 बॉक्स पर मेरी समस्या ठीक हो गई है कि मैं साम्बा शेयरों काम कर पाने का प्रयास करते समय पर अनुमतियों में गड़बड़ कर दिया था। धन्यवाद

Answer 18

यह एक समस्या की तरह लगता है। आमतौर पर यह तब होता है जब कुछ फ़ाइल / निर्देशिका की अनुमति सही ढंग से सेट नहीं की जाती है। ज्यादातर मामलों में वे हैं ~/.sshऔर ~/.ssh/*। मेरे मामले में वे हैं/home/xxx ।

आप संशोधित करके sshd के लॉग स्तर को बदल सकते हैं /etc/ssh/sshd_config(खोज LogLevel, इसे सेट करें DEBUG), फिर आउटपुट की जांच करके /var/log/auth.logदेखें कि वास्तव में क्या हुआ था।

Comments

यह स्वीकृत उत्तर के समान दिखता है और संभवतः इस पर टिप्पणी होनी चाहिए, उत्तर नहीं। थोड़ा और प्रतिनिधि के साथ, आप टिप्पणी पोस्ट करने में सक्षम होंगे । तब तक, कृपया उत्तर को वर्कअराउंड के रूप में उपयोग न करें।

— नाथन टग्गी

क्षमा करें, मुझे लगा कि यह इस प्रश्न के सभी प्रकार को हल करने का तरीका है। अब मुझे पता है कि यह कैसे करना है, धन्यवाद।

— जॉय

Answer 19

मेरी समस्या एक संशोधित ऑथराइज्डएसफाइल थी, जब ऑटोमेशन को पॉप्युलेट करने के लिए / etc / ssh / अधिकृत_की को अभी तक नहीं चलाया गया था।

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Answer 20

बस पर देखने के /var/log/auth.log पर सर्वर । क्लाइंट साइड पर -vv के साथ अतिरिक्त वर्बोसिटी सेट करने से मदद नहीं मिलेगी, क्योंकि सर्वर संभावित हमलावर को बहुत अधिक जानकारी देने की संभावना नहीं है।

Answer 21

सुनिश्चित करें कि आपने पूरी सार्वजनिक कुंजी कॉपी कर ली है authorized_keys; कार्य करने के लिए ssh rsaउपसर्ग आवश्यक है।

Comments

ssh-copy-id

— विष्णु

Answer 22

आपको फ़ाइलों के गुणों को सत्यापित करने की आवश्यकता है। आवश्यक संपत्ति का उपयोग आवंटित करने के लिए:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

Answer 23

के /var/log/auth.logलिए सर्वर पर देखोsshd प्रमाणन त्रुटियों।

यदि अन्य सभी विफल होते हैं, तो sshdसर्वर को डिबग मोड में चलाएं :

sudo /usr/sbin/sshd -ddd -p 2200

फिर क्लाइंट से कनेक्ट करें:

ssh user@host -p 2200

मेरे मामले में मुझे अंत में त्रुटि अनुभाग मिला:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

इस जानकारी के साथ मैंने महसूस किया कि मेरा समूह के sshd_configसदस्यों के लिए लॉगिन प्रतिबंधित था ssh। निम्न आदेश इस अनुमति त्रुटि को ठीक करता है:

sudo usermod -a -G ssh NEW_USER

Answer 24

उस नोट पर, सुनिश्चित करें कि आपके पास sshd config है -;

PermitRootLogin without-password

उपरोक्त के रूप में सेट करें, फिर sshd (/etc/init.d/sshd पुनरारंभ) को पुनरारंभ करें

लॉग-आउट करें और लॉग-इन फिर से आज़माएँ!

डिफ़ॉल्ट मुझे विश्वास है -;

PermitRootLogin no

Answer 25

मेरे मामले में यह इसलिए है क्योंकि उपयोगकर्ता का समूह कॉन्फ़िगर फ़ाइल / etc / ssh / sshd_config के AllowGroups में सेट नहीं है। इसे जोड़ने के बाद सबकुछ ठीक हो जाता है।

Answer 26

मेरे पास गैर-मानक स्थान पर होम निर्देशिका है और sshdलॉग में मेरे पास यह रेखा है:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

भले ही सभी अनुमतियां ठीक थीं (अन्य उत्तर देखें)।

मुझे यहाँ एक समाधान मिला है: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7e2c2#p25813191

मेरे विशेष मामले में:

• इसमें एक नई पंक्ति जोड़ी /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • यह नियमित होम निर्देशिकाओं के लिए मूल पंक्ति है:

    /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • यह मेरी नई लाइन है:

    /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• इसके बाद a restorecon -r /data/और sshdपुनरारंभ होता है

Answer 27

मुझे यह समस्या थी और किसी भी अन्य उत्तर ने इसे हल नहीं किया, हालांकि निश्चित रूप से अन्य उत्तर हैं सही।

मेरे मामले में, यह निकला कि /rootनिर्देशिका (उदाहरण के लिए नहीं /root/.ssh) के पास गलत अनुमतियां थीं। मुझे चाहिए था:

chown root.root /root
chmod 700 /root

बेशक, उन अनुमतियों की chmod 770परवाह किए बिना (शायद ) ऐसा कुछ होना चाहिए । हालांकि, यह विशेष रूप से रोका sshdकाम करने से, भले ही /root/.sshऔर /root/.ssh/authorized_keysदोनों सही अनुमतियाँ और मालिकों था।

Answer 28

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