SSH- कुंजी प्रमाणीकरण विफल रहता है

Question

मैं एक CentOS सर्वर में ssh करने की कोशिश कर रहा हूं, जिस पर मेरा कोई नियंत्रण नहीं है .. व्यवस्थापक ने सर्वर में मेरी सार्वजनिक कुंजी जोड़ दी है और मेरे साथ हुई गलती पर जोर देता है, लेकिन मैं यह पता नहीं लगा सकता कि क्या गलत है।

कॉन्फ़िगर करें .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

मेरी कुंजी-फाइलों पर अनुमति:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

कनेक्शन लॉग, जिसका मैं कोई मतलब नहीं कर सकता:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: [e-mail],[e-mail],[e-mail],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [e-mail],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [e-mail],[e-mail],[e-mail],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[e-mail],[e-mail],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [e-mail],aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],[e-mail],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [e-mail],aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],[e-mail],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[e-mail],zlib
debug2: compression stoc: none,[e-mail],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [e-mail],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[e-mail],[e-mail],[e-mail],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[e-mail],[e-mail],[e-mail],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: MACs ctos: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-md5,hmac-sha1,[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-md5,hmac-sha1,[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[e-mail]
debug2: compression stoc: none,[e-mail]
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: [e-mail]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [e-mail] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [e-mail] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Comments

पलकों से, ऐसा लगता है कि कुंजी भेजी गई है, लेकिन कभी कोई प्रतिक्रिया नहीं मिली। क्या आप रूट के रूप में लॉग इन करने वाले हैं, या आप टिम के रूप में लॉग इन करते हैं और फिर sudo का उपयोग करते हैं? कभी-कभी ssh लॉगिन रूट के रूप में अक्षम होता है। -शादी निर्देशिका की अनुमति क्या है? -क्या आपके पास सही सर्वर है? क्या डीएन ठीक से हल कर रहे हैं? -आप फिर से कुंजी बना सकते हैं, और उसके बाद ssh-copy-id का उपयोग करके नई सार्वजनिक कुंजी को अधिकृत_की फाइल में कॉपी कर सकते हैं। बस मामले में कुंजी किसी तरह भ्रष्ट हो गई।

— काइल एच

सहायता का प्रयास करने के लिए धन्यवाद! मेरे .ssh फ़ोल्डर पर अनुमतियाँ हैं: drwx ------ 2 टिम टिम 4096 Okt 20 22:13 .ssh। Loggin इन रूट सही है - इससे पहले कि मैं अपने कंप्यूटर में सुधार करने से पहले कुछ हफ़्ते पहले काम करता था। व्यवस्थापक का कहना है कि उसने नई कुंजियों को सही ढंग से जोड़ा है, लेकिन मैं वास्तव में नहीं जानता कि इस बिंदु पर मेरी गलती कैसे हो सकती है

— टिम

जैसा कि @KyleH ने उल्लेख किया है, क्या आपने ssh tim@10.0.12.28लॉग के रूप में केर्बोस का उल्लेख करने की कोशिश की है CentOS सर्वर डोमेन इंटीग्रेटेड (AD, IPA, ...) हो सकता है। आपको यह पता लगाना होगा कि आप किस उपयोगकर्ता का उपयोग करने वाले हैं। व्यवस्थापक से पूछें। हम उदाहरण के लिए IPA का उपयोग कर रहे हैं, इसलिए हम उपयोगकर्ताओं को अपने IPA डोमेन खाते और मुख्य जोड़ी के साथ कुछ सर्वर से कनेक्ट करने में सक्षम बनाते हैं और यदि आवश्यक हो तो वे sudo कर सकते हैं। रूट एक्सेस नहीं :)

— Zina

Answer 1

यह आमतौर पर सर्वर की ओर से अधिकांश एसएसएच अधिकृत कुंजी अनुमति मुद्दों को हल करेगा , यह मानते हुए कि किसी ने अनुमतियों में अतिरिक्त परिवर्तन नहीं किया है।

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

यदि आपके व्यवस्थापक ने .ssh / निर्देशिका या .shsh / अधिकृत_की फ़ाइल को रूट के रूप में बनाया है (जो कि आमतौर पर यह कैसे पूरा किया जाता है), तो किसी अन्य उपयोगकर्ता (भले ही रूट!) के पास फ़ाइल हो।

उपयोगकर्ता नाम (अस्वीकरण: सह-संस्थापक) स्वचालित रूप से ठीक इसी तरह से करता है .. https://github.com/userify/shim/blob/master/shim.py#L285

Comments

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

— चार्ल्स डफी

यह सर्वर साइड समस्या को ठीक करता है। आप सही हैं कि ग्राहक पक्ष ठीक है।

— जेमिसन बेकर

इससे आखिरकार मेरी समस्या हल हो गई। यह जानने की कोशिश कर रहे हैं कि मेरी सार्वजनिक / निजी कुंजी स्वीकार क्यों नहीं की जा रही है।

— डैनियल हैरिस

एक अन्य उपयोगकर्ता ने सुझाव दिया sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Rकि टाइपिंग का समय बच जाएगा, लेकिन एक नौसिखिया को समझने के लिए कठिन हो सकता है

— जेमिसन बेकर

Answer 2

मुझे दो सर्वरों पर एक ही समस्या थी: एक लिनक्स जो डेबियन स्ट्रेच पर चल रहा है और एक NAS पर (Synology DS715)

यह पता चला कि दोनों ही मामलों में, सर्वर पर होम निर्देशिका अनुमतियाँ गलत थीं

server.log सर्वर पर बहुत मददगार था

Authentication refused: bad ownership or modes for directory /home/cyril

लिनक्स पर, इसमें राइट / ग्रुप बिट ऑन (drwxrwxr - x) था, इसलिए मुझे कम से कम ग्रुप (chmod gw ~ /) पर लिखना पड़ा और फिर इसने काम किया

Synology पर, जो भी कारण के लिए, एक चिपचिपा सा था

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

मुझे इसके साथ बदलना पड़ा

chmod -t ~/

और मैं तब बिना पासवर्ड के जुड़ सकता था

Comments

इसके लिए धन्यवाद chmod -t... मैंने साथ समाप्त किया:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts

— स्टीफन

Answer 3

CentOS 7 का उपयोग करते समय, और मुझे विश्वास है कि यह अन्य Linux OS के sshd के साथ भी लागू होता है। रूट एक्सेस के साथ, आप यह निर्धारित कर सकते हैं कि प्रमाणीकरण विफल क्यों हो सकता है। यह करने के लिए:

1. Sshd के लिए लॉगिंग सक्षम करें: vi /etc/ssh/sshd_config
2. लॉगिंग असहजता के तहत:

SyslogFacility AUTH LogLevel INFO

1. LogLevel जानकारी को LogLevel DEBUG में बदलें
2. सुरषित और बहार
3. Sshd को पुनरारंभ करें systemctl restart sshd
4. संदेश फ़ाइल देखें tail -l /var/log/messages
5. दूसरे टर्मिनल का उपयोग करके ssh से जुड़ने का प्रयास
6. Ssh से जुड़ने का प्रयास
7. सटीक कारण के लिए प्रमाणीकरण लॉग की समीक्षा करें

उदाहरण के लिए, मैं ऊपर बताई गई कुछ समस्याओं का सामना कर रहा था।

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

इन चरणों का उपयोग करके मैं इस समस्या की पुष्टि करने में सक्षम था, अधिकृत_की फ़ाइल पर अनुमतियाँ थीं। मेरे उपयोगकर्ता की अधिकृत कुंजी फ़ाइल पर 644 में chmod सेट करने से, समस्या ठीक हो गई थी।

Answer 4

ऐसा लगता है कि आपके .sshफ़ोल्डर की अनुमतियां सही तरीके से + पेस्ट नहीं की गईं। क्या आप इसे फिर से जोड़ सकते हैं?

यदि सख्त मोड सक्षम है तो हमें सुनिश्चित करना होगा कि .sshइसकी सही अनुमति है:

• .ssh/ के पास परमिट होना चाहिए 0700/rwx------
• .ssh/*.pub फाइलें होनी चाहिए 644/rw-r--r--
• .ssh/* (अन्य फाइलें .ssh में) 0600/rw-------

चीजें आपको अनुमति-वार कैसे दिखती हैं?

Comments

मेरे होम फोल्डर (टिम) पर अनुमतियाँ 755 (drwxr-xr-x) हैं और .ssh फ़ोल्डर पर अनुमतियाँ 700 (drwx) हैं। id_rsa 600 है और .pub फ़ाइल 644 है: / / फिर से धन्यवाद, आशा है कि जानकारी मदद करती है

— टिम

मैंने कई सर्वरों पर काम किया है। मेरे घर की निर्देशिका drwxr-xr-x (0755) है, .shsh rwx ------ (0700) है, इसके अंदर मेरी पब की -rw-r - r-- (0644) है, और बाकी उस फ़ोल्डर में हैं --rw ------- (0600)। तो, आपकी अनुमतियां अच्छी हैं और इसे स्ट्रिक्ट होस्ट चेकिंग पास करना चाहिए। आपकी / etc / ssh_config फ़ाइल में क्या है? कुछ भी ~ / .ssh / config में? मेरे पास एक कारण के लिए ssh कुंजी निर्माण है या कोई और काम नहीं है भले ही कोई त्रुटि नहीं थी। क्या आप ssh-keygen का उपयोग करके अपनी कुंजी, ssh-copy-id को पुन: प्राप्त करने की कोशिश कर सकते हैं ताकि आपकी पब कुंजी को रिमोट सर्वर पर कॉपी किया जा सके जिसमें पासवर्ड प्रमाणीकरण चालू है?

— काइल एच

दुर्भाग्य से मेरे पास सर्वर तक कोई पहुंच नहीं है, लेकिन मैं कोशिश करूंगा कि मैं अपनी पब की को सर्वर पर फिर से कॉपी करने के लिए एडमिन को सोमवार को भेज दूं। मैंने config फाइल की सामग्री को pastebin पर कॉपी किया: pastebin.com/eEaVMcvt - आपके लिए फिर से धन्यवाद मदद!

— टिम

आपका स्वागत है। मैं मदद करने के लिए खुश हूँ! मुझे समस्या को सुलझाने और लिनक्स के साथ दूसरों की मदद करने में भी मजा आता है। आपके ssh-config में एक विषम रेखा है जो उन समस्याओं का कारण बन सकती है जहां यह है। IP 10.0.12.28 क्या है?

— काइल एच

@ केश सही है .. यह लगभग निश्चित रूप से मुद्दा है। मैंने एक और उत्तर जोड़ा जो दिखाता है कि इसे रूट एक्सेस के साथ कैसे ठीक किया जाए। यदि आप अपने होमडेयर को नियंत्रित करते हैं, तो आप संभवतः इसे स्वयं ठीक कर सकते हैं, लेकिन निश्चित रूप से आपको लॉग इन करने में सक्षम होना होगा:

— जैमिसन बेकर

Answer 5

बस अगर कोई इस जवाब पर अड़ जाता है - मेरे परिदृश्य में किसी भी सिफारिश ने काम नहीं किया। अंत में, समस्या यह थी कि मैंने बिना पासवर्ड सेट के एक खाता बनाया था। एक बार जब मैंने पासवर्ड का उपयोग कर सेट किया usermod -p "my password" usernameऔर फिर जबरन खाता खोल दिया तो usermod -U usernameसब कुछ पेचीदा हो गया।

Comments

आपके उत्तर ने मुझे मेरे अलग, बल्कि उपयोगकर्ता-संबंधित, मेरे लॉग इन करने के प्रयास के मामले को चिह्नित कर दिया, जब मैंने जिस होम डायरेक्टरी को दिया था, वह मेरे द्वारा लॉग इन करने की तुलना में अधिक नेस्टेड था ... ग्रेट को तय करने के लिए, धन्यवाद!

— ब्रेट ज़मीर

Answer 6

मेरे पास एक समान समस्या है , जहां ssh कनेक्शन ~/.ssh/id_rsaअप्रत्याशित रूप से रोकने से पहले कुंजी की कोशिश करता है :

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

मेरे मामले में, यह .sshनिर्देशिका में एक पुरानी सार्वजनिक कुंजी फ़ाइल के आसपास होने के कारण था :

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

निर्देशिका id_rsa.pubसे हटने / हटाने से .sshसमस्या हल हो गई।

मुझे जो समझ में आया है: जब क्लाइंट-साइड पर एक सार्वजनिक कुंजी मौजूद होती है, तो SSH 1 इसके खिलाफ निजी कुंजी को मान्य करता है। यदि यह विफल रहता है, तो यह दूरस्थ रूप से कनेक्ट करने के लिए निजी कुंजी का उपयोग करने का प्रयास नहीं करेगा।

मैंने ओपनश मेलिंग सूची को एक ई-मेल भेजा: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html ।

Comments

Yeaaahhhh। गंभीरता से! मैंने उस पर कभी गौर नहीं किया होगा। openssh-8.0p1-5.fc30.x86_64btw। मेरे पास पहले वाले सर्वर से एक ही नाम के साथ सार्वजनिक कुंजी थी जैसा कि नया चारों ओर पड़ा हुआ है fedora@(baloo).sshkey.pub, जो विकल्प के fedora@(baloo).sshkeyसाथ कमांड लाइन पर पारित हो जाता -iहै। नए सर्वर कुंजी के साथ प्रमाणीकरण विफल हो गया fedora@(baloo).sshkey- एक आरएसए कुंजी।

— डेविड टोनहोफर

Answer 7

हमने इस समस्या का सामना किया। अनुमतियाँ और .sh फ़ाइलों पर स्वामित्व सभी सही थे। हमने / var / log / संदेशों में पाया:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

SO, डेवलपर vm के लिए समाधान जहां हमें सुरक्षा की परवाह नहीं है वह selinux अक्षम है। संपादित करें / etc / sysconfig / selinux और SELINUX = अक्षम और रिबूट बदलें।

Answer 8

बस के मामले में यह भी किसी को बचाता है। मैं अपने Ubuntu 18.04 मशीन से 2 CentOS 7 सर्वर में एक कुंजी को कॉपी करने की कोशिश कर रहा था। मैं ssh-copy-idउनका ट्रांसफर कर देता था। एक काम किया, एक नहीं किया। इसलिए मैंने डिबगिंग की सभी अनुमतियों को देखा और कुछ भी नहीं पाया। इसलिए अंत में मैंने /etc/ssh/sshd_configदोनों सर्वरों पर फ़ाइल खींची और उनके माध्यम से लाइन से कदम बढ़ाया। अंत में मैंने इसे पाया, शायद ऐसा कुछ जो किसी को काम पर आने से बहुत पहले संशोधित किया गया हो।

एक पढ़ा: AuthorizedKeysFile .ssh/authorized_keys

और एक और पढ़ा: AuthorizedKeysFile ~/.ssh/authorized_keysजो सर्वर पर था जो मेरी चाबियाँ स्वीकार नहीं कर रहा था। स्पष्ट रूप से दो फ़ाइलों के बीच देख रहे हैं और टिप्पणी है कि डिफ़ॉल्ट खोज पैटर्न बताता है कि ~/मैं इसे हटा दिया और sdd को फिर से शुरू करने वाले अग्रणी को शामिल नहीं करता है । समस्या सुलझ गयी।

Answer 9

इस समस्या का भी सामना किया। setroubleshoot मेरे वातावरण में काम नहीं करता था इसलिए ऐसे कोई लॉग रिकॉर्ड / var / log / संदेश नहीं थे। SELinux को डिसेबल करना मेरे लिए कोई विकल्प नहीं था, इसलिए मैंने किया

restorecon -Rv ~/.ssh

उसके बाद rsa key द्वारा लॉगिन करना ठीक रहा।

Answer 10

मेरे मामले में कारण AuthorizedKeysFileफ़ाइल में एक कस्टम सेट विकल्प था /etc/ssh/sshd_config। इसे किसी अन्य उपयोगकर्ता के होम डायर ( /home/webmaster/.ssh/authorized_keys) पर सेट किया गया था , इसलिए मैं जिस उपयोगकर्ता को लॉग इन करने का प्रयास कर रहा था, उस फ़ाइल / निर्देशिका तक उसकी कोई पहुँच नहीं थी।

इसे बदलने और ssh-server ( service ssh restart) को पुनः आरंभ करने के बाद सब कुछ सामान्य हो गया। मैं अब अपनी निजी कुंजी से लॉग इन कर सकता हूं।

Answer 11

हमारे मामले में मुद्दे इस तथ्य से संबंधित थे कि हमारे फ़ायरवॉल और नैटिंग नियम सही तरीके से सेटअप नहीं थे।

पोर्ट 22, को गलत सर्वर पर निर्देशित किया जा रहा था, जहां हमारी कुंजी और उपयोगकर्ता को पहचाना नहीं जा रहा था।

अगर कोई इस बिंदु पर पहुंच जाता है। tcpdump और telnet आपका दोस्त हो सकता है

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

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

Ssh बहुत सारे ट्रैफ़िक उत्पन्न कर सकता है जो tcpdump को बाहर निकालने में मुश्किल करता है जिसे आप ढूंढ रहे हैं।

इससे मुझे मदद मिली

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

अपने वर्तमान कंप्यूटर @ [mylocalip] नहीं एक 3 अलग सर्वर से टेलनेट की कोशिश करें। आप यह देखना चाहते हैं कि ट्रैफ़िक वास्तव में आपके सर्वर तक कैसे पहुँचता है।

Answer 12

क्लाइंट-साइड एरर लॉग इस तरह समाप्त होता है:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@x.x.x.x's password:

जब sshd कॉन्फ़िगरेशन फ़ाइल में रूट लॉगिन पर सर्वर-साइड (रिमोट) प्रतिबंध के कारण हो सकता है :

PermitRootLogin: no

लॉगिंग को सक्षम करने के लिए जॉनकैव का सुझाव इस तरह के मुद्दे को डीबग करने में सहायक था। जबकि क्लाइंट-साइड डिबग स्प्यू उल्लेखनीय रूप से अनहेल्दी था, sshd सर्वर की sshd_config फ़ाइल में निम्नलिखित को रखते हुए :

SyslogFacility AUTH
LogLevel DEBUG

सहायक लॉग संदेश का उत्पादन समाप्त:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

उस स्थिति में जहां केवल रूट लॉगिन विफल रहता है, और यह प्रदान करना कि रूट लॉग के लिए केवल कुंजी-आधारित प्रमाणीकरण का उपयोग करना आपकी सुरक्षा नीति द्वारा अनुमत है, sshd_config फ़ाइल में परिवर्तन मदद कर सकता है:

 PermitRootLogin without-password

आपका माइलेज अलग-अलग हो सकता है, हालांकि यह अक्सर मदद करता है, कुछ sshd_config फ़ाइलों में मिली टिप्पणी के अनुसार कुछ अन्य कॉन्फ़िगरेशन अभी भी हस्तक्षेप कर सकते हैं :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

आप आसानी से इस तरह से, एक मई सबूत के लिए एक ही पहचान फ़ाइलों का उपयोग करके कुछ हद तक क्लाइंट साइड विन्यास में डिबग करने के लिए दूरस्थ सर्वर विन्यास बदल सकते हैं यहां तक कि अगर ssh ही दूरस्थ सर्वर पर गैर-रूट खाते में।

Answer 13

मैं देख सकता हूं कि सुरक्षा लोगों को क्यों परेशान कर सकती है। मुझे बस ssh won't use my keyफिर से समस्या थी । मैंने इसे रिमोट सर्वर में लॉग इन करके और रन करके हल किया

/usr/sbin/sshd -sDp 23456

और फिर मेरे डेस्कटॉप से, (सर्वर पर ssh करने की कोशिश कर रहा है)

ssh -vvvv server -p 23456

सर्वर पर मुझे मिला Authentication refused: bad ownership or modes for directory /

कुछ नए sysadmin ने अनुमति और स्वामित्व को गड़बड़ कर दिया था, जिसे मैंने तय किया था:

chmod 0755 / ; chown root:root /

(मुझे इसकी आवश्यकता है chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubलेकिन sshd जाँच / रूट अनुमतियाँ खोजना मेरे लिए एक नया है।) अब मैं एक रूटकिट के लिए जाँच करने जा रहा हूँ और फिर किसी भी तरह से मिटा और फिर से स्थापित करूँगा।

Answer 14

मेरे मामले में मुद्दे गलत शेल निष्पादन के साथ थे।

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

उस उपयोगकर्ता के लिए परिवर्तित / etc / passwd फ़ाइल

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

Answer 15

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

sudo ls -laZ <user-home>/.ssh

निर्देशिका की (मैं sshd_config पर बहुत सारी चूक कर रहा हूं)।

आपको कुछ ssh_home_tऔर user_home_tविशेषताओं को देखना चाहिए । यदि आप नहीं करते हैं, का उपयोग करेंchcon तो लापता विशेषताओं को जोड़ने के कमांड का ।

उदाहरण के लिए

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

मेरे मामले में, मेरा संदेह यह है कि उपयोगकर्ता एक गैर मानक तरीके से बनाया गया था। उनके घर में एक निर्देशिका थी/var/lib ।

: में अधिक जानकारी https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/