এসএসএইচ-কী প্রমাণীকরণ ব্যর্থ

Question

আমি সেন্টোস সার্ভারে প্রবেশ করার চেষ্টা করছি যার উপর আমার কোনও নিয়ন্ত্রণ নেই .. অ্যাডমিন সার্ভারে আমার সর্বজনীন কী যুক্ত করেছে এবং দোষটি আমার সাথে রয়েছে বলে জোর দিয়েছিল তবে আমি কী ভুল তা বুঝতে পারি না।

.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

Idsাকনাগুলি থেকে, দেখে মনে হচ্ছে কীটি প্রেরণ করা হয়েছে, তবে কোনও প্রতিক্রিয়া পাওয়া যায় নি। -আপনি কি রুট হিসাবে লগ ইন করার কথা বলছেন, বা আপনি টাইম হিসাবে লগ ইন করবেন এবং তারপরে sudo ব্যবহার করবেন? কখনও কখনও রুট হিসাবে ssh লগইন অক্ষম করা হয়। .এসএসএইচ ডিরেক্টরিটি নিজেই কি অনুমতি পাবে? -আপনি কি সঠিক সার্ভার আছে? ডিএনএস কি সঠিকভাবে সমাধান হচ্ছে? -আপনি কীগুলি আবার তৈরি করতে পারেন এবং তারপরে অনুমোদিত_কিগুলি ফাইলে নতুন পাবলিক কী ম্যানুয়ালি অনুলিপি করতে ssh-copy-id ব্যবহার করতে পারেন। সেক্ষেত্রে কীটি কোনওভাবে দূষিত হয়ে পড়ে।

— কাইল এইচ

সাহায্য করার চেষ্টা করার জন্য ধন্যবাদ! আমার .ssh ফোল্ডারে অনুমতিগুলি হ'ল: drwx ------ 2 টিম টাইম 4096 Okt 20 22:13 .ssh। রুট হিসাবে লগইন করা সঠিক - আমি আমার কম্পিউটারটি পুনরায় ফর্ম্যাট করার আগে এটি কয়েক সপ্তাহ আগে আসলে কাজ করেছিল। অ্যাডমিনটি বলেছে যে সে নতুন কীগুলি সঠিকভাবে যুক্ত করেছে তবে আমি জানি না যে এই মুহুর্তে এটি আমার ভুল হতে পারে

— টিম

@ কিলিএইচ যেমন উল্লেখ করেছেন, আপনি কি লগের মাধ্যমে সেন্টারস ssh tim@10.0.12.28সার্ভার ডোমেন ইন্টিগ্রেটেড (AD, IPA, ...) হতে পারে উল্লেখ করেছেন তেমন চেষ্টা করেছেন ? আপনার কোন ব্যবহারকারী ব্যবহার করার কথা রয়েছে তা আপনাকে খুঁজে বের করতে হবে। প্রশাসককে জিজ্ঞাসা করুন। আমরা উদাহরণস্বরূপ আইপিএ ব্যবহার করছি তাই আমরা ব্যবহারকারীদের তাদের আইপিএ ডোমেন অ্যাকাউন্ট এবং কী জুটির সাথে নির্দিষ্ট সার্ভারের সাথে সংযোগ স্থাপন করতে সক্ষম করি এবং প্রয়োজনে তারা সুডো করতে পারে। কোনও রুট অ্যাক্সেস নেই :)

— জিনা

Answer 1

এটি সাধারণত বেশিরভাগ এসএসএইচ অনুমোদিত অনুমোদনের সমস্যাগুলি সার্ভার সাইডে সমাধান করবে , ধরে নিয়েই কেউ অনুমতিতে অতিরিক্ত পরিবর্তন করেনি।

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

যদি আপনার প্রশাসক রুট হিসাবে .ssh / ডিরেক্টরি বা .ssh / অনুমোদিত_keys ফাইল তৈরি করে (যা এটি সাধারণত কীভাবে সম্পাদিত হয়) তবে অন্য কোনও ব্যবহারকারীর (রুট হলেও!) মালিকানাধীন ফাইলটি অনুমোদিত নয়।

ইউটিরিফাই (অস্বীকৃতি: সহ-প্রতিষ্ঠাতা) স্বয়ংক্রিয়ভাবে এটি ঠিক একইভাবে করে .. https://github.com/userify/shim/blob/master/shim.py#L285

Comments

যদি এটি সমস্যা হয় তবে ক্লায়েন্টটি সার্ভারে কীটি প্রথমে প্রেরণ করার চেষ্টা করবে না; প্রশ্নে দেওয়া লগটি স্পষ্ট যে এটি করে।

— চার্লস ডাফি

এটি সার্ভারের পাশের সমস্যাটিকে সংশোধন করে। আপনি সঠিক যে ক্লায়েন্ট পক্ষ ঠিক আছে।

— জেমিসন বেকার 16

এটি অবশেষে আমার সমস্যার সমাধান করে। আমার সার্বজনীন / ব্যক্তিগত কীগুলি কেন গৃহীত হচ্ছে না তা জানার চেষ্টা করে ঘন্টা ব্যয় করল।

— ড্যানিয়েল হ্যারিস

অন্য একজন ব্যবহারকারী পরামর্শ দিয়েছিলেন sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Rযা টাইপিংয়ের সময় সাশ্রয় করবে, তবে কোনও নবজাতকের পক্ষে এটি বোঝা আরও শক্ত হতে পারে

— জ্যামিসন বেকার

Answer 2

আমার দুটি সার্ভারে ঠিক একই সমস্যা ছিল: একটি লিনাক্স ডিবিয়ান প্রসারিত এবং একটি এনএএস-এ চলছে (সিনোলজি ডিএস 715)

দেখা গেল যে উভয় ক্ষেত্রেই সার্ভারে হোম ডিরেক্টরি অনুমতিগুলি ভুল ছিল

সার্ভারে auth.log খুব সহায়ক ছিল

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

লিনাক্সে, এতে রাইটিং / গ্রুপ বিট ছিল (drwxrwxr - x), সুতরাং আমাকে কমপক্ষে গ্রুপে লেখাটি মুছে ফেলতে হয়েছিল (chmod gw ~ /) এবং তারপরে এটি কাজ করেছিল

সিনোলজিতে, যে কারণেই হোক না কেন, একটি স্টিকি বিট ছিল

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 ব্যবহার করার সময় এবং আমি আত্মবিশ্বাসী অন্যান্য লিনাক্স ওএসের এসএসডি ব্যবহার করার ক্ষেত্রেও প্রযোজ্য। রুট অ্যাক্সেসের সাথে, কেন প্রমাণীকরণ ব্যর্থ হতে পারে সে সম্পর্কে আপনি আরও নির্ধারণ করতে পারেন। এটা করতে:

1. Sshd- এর জন্য লগিং সক্ষম করুন: vi /etc/ssh/sshd_config
2. অবিচ্ছিন্ন লগিংয়ের আওতায়:

SyslogFacility AUTH LogLevel INFO

1. লগলভেল আইএনএফও-কে লগলভেল ডিবাগ-এ পরিবর্তন করুন
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

এই পদক্ষেপগুলি ব্যবহার করে আমি সমস্যাটি নিশ্চিত করতে সক্ষম হয়েছি অনুমোদিত_কিগুলি ফাইলে অনুমতি ছিল। আমার ব্যবহারকারীর অনুমোদিত কী ফাইলটিতে chmod 644 এ সেট করে, সমস্যাটি স্থির করা হয়েছিল।

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), .ssh rwx ------ (0700) এর ভিতরে ss সেই ফোল্ডারে হ'ল ------ - (0600)। সুতরাং, আপনার অনুমতিগুলি ভাল এবং এটি কঠোর হোস্ট চেকিং পাস করা উচিত। আপনার / ইত্যাদি / ssh_config ফাইলে কী আছে? ~ / .Ssh / কনফিগারেশনে কিছু আছে? আমার কোনও কারণে ত্রুটি না থাকা সত্ত্বেও এক কারণে বা অন্য কোনও কারণে কাজ করা হয়নি এর জন্য ssh কী তৈরি হয়েছিল। আপনি কীগুলি কী পুনরায় জেনারেট করতে ssh-keygen ব্যবহার করার চেষ্টা করতে পারেন, পাসওয়ার্ড প্রমাণীকরণ চালু আছে এমন রিমোট সার্ভারে আপনার পাব কীটি অনুলিপি করতে ssh-copy-id?

— কাইল এইচ

দুর্ভাগ্যক্রমে আমার সার্ভারে অ্যাক্সেস নেই তবে সোমবার আবার প্রশাসককে আমার পাব কীটি সার্ভারে অনুলিপি করার চেষ্টা করব .. আমি কনফিগার ফাইলগুলির বিষয়বস্তুগুলি পেস্টবিনে অনুলিপি করেছি: পেস্টবিন. com/ eইএভিএমসিভিটি - আপনার জন্য আবার ধন্যবাদ সাহায্যের!

— টিম

আপনাকে স্বাগতম. আমি সাহায্য করতে পেরে খুশি! আমি সমস্যা সমাধান এবং বিশেষত অন্যকে লিনাক্সের সাহায্যে উপভোগ করি। আপনার ssh- কনফিগারেশনে একটি বিজোড় লাইন রয়েছে যা এটি যেখানে রয়েছে সেখানে সমস্যা দেখা দিতে পারে। আইপি 10.0.12.28 কি?

— কাইল এইচ

@ কাইলএইচ ঠিক আছে .. এটি প্রায় অবশ্যই সমস্যা। আমি অন্য একটি উত্তর যুক্ত করেছি যা দেখায় যে এটি কীভাবে রুট অ্যাক্সেসের সাথে ঠিক করা যায়। আপনি যদি নিজের বাড়ির ডায়ারটি নিয়ন্ত্রণ করেন, আপনি সম্ভবত এটি নিজেরাই ঠিক করতে পারেন, তবে অবশ্যই আপনাকে লগ ইন করতে সক্ষম হতে হবে :)

— জ্যামিসন বেকার

Answer 5

কেবলমাত্র যদি কেউ এই উত্তরে হোঁচট খায় - সুপারিশগুলির কোনওই আমার দৃশ্যে কাজ করেনি। শেষ পর্যন্ত সমস্যাটি হ'ল আমি পাসওয়ার্ড সেট না করে একটি অ্যাকাউন্ট তৈরি করেছিলাম। একবার আমি পাসওয়ার্ডটি ব্যবহার করে সেট করেছিলাম usermod -p "my password" usernameএবং জোর করে অ্যাকাউন্টটি আনলক করে দিয়েছিলাম usermod -U usernameসমস্ত কিছু পীচি।

Comments

আপনার উত্তরটি আমাকে আমার আলাদা, তবে ব্যবহারকারী-সম্পর্কিত, লগ ইন করার চেষ্টা করার ক্ষেত্রে আমি যে হোম ডিরেক্টরিটি দিয়েছিলাম তাতে যে লগ ইন করছিলাম তার চেয়ে বেশি ঘৃণিত হয়েছিল ... ঠিক আছে, ধন্যবাদ!

— ব্রেট জমির

Answer 6

আমারও একই সমস্যা হয়েছে , যেখানে ~/.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সমস্যার সমাধান করে।

আমি যা বুঝি তা থেকে: যখন ক্লায়েন্টের পাশে কোনও সার্বজনীন কী উপস্থিত থাকে, এসএসএইচ 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- একটি আরএসএ কী দিয়ে প্রমাণীকরণ ব্যর্থ হয়েছে ।

— ডেভিড টোনহোফার 22:46

Answer 7

আমরা এই সমস্যার মুখোমুখি হয়েছি। .Ssh ফাইলগুলিতে অনুমতি এবং মালিকানা সবই সঠিক ছিল। ইন / ভার / লগ / বার্তাগুলি আমরা পেয়েছি:

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

সুতরাং, বিকাশকারী ভিএম এর সমাধান যেখানে আমরা সুরক্ষা সম্পর্কে যত্ন করি না সে সেলিনাক্স অক্ষম করে। সম্পাদনা / ইত্যাদি / সিসকনফিগ / সেলিনাক্স এবং SELINUX = অক্ষম করুন এবং পুনরায় বুট করুন।

Answer 8

শুধু যদি এটি কাউকে বাঁচায়। আমি আমার উবুন্টু 18.04 মেশিন থেকে 2 সেন্টস 7 সার্ভারে একটি কী অনুলিপি করার চেষ্টা করছিলাম। আমি ssh-copy-idতাদের স্থানান্তর করতাম। একজন কাজ করেছে, কেউ করেনি। সুতরাং আমি ডিবাগিং সমস্ত অনুমতি দিয়ে গিয়েছিলাম এবং কিছুই পাই নি found সুতরাং অবশেষে আমি /etc/ssh/sshd_configউভয় সার্ভারে ফাইলটি টানলাম এবং সেগুলির মধ্য দিয়ে লাইন ধাপে ধাপে। অবশেষে আমি এটি পেয়েছি, সম্ভবত এমন কিছু যা আমি চাকরিতে নামার অনেক আগে থেকেই পরিবর্তন করেছে।

একজন পড়ুন: AuthorizedKeysFile .ssh/authorized_keys

এবং অন্যটি পড়ুন: AuthorizedKeysFile ~/.ssh/authorized_keysএটি সার্ভারে ছিল যা আমার চাবি গ্রহণ করছে না। স্পষ্টতই দুটি ফাইলের মধ্যে সন্ধান করা এবং মন্তব্যটি লক্ষ্য করে যে ডিফল্ট অনুসন্ধান নিদর্শনগুলিতে ~/অগ্রণীটিকে আমি সরিয়েছি এবং এসএসডি পুনরায় চালু করার অন্তর্ভুক্ত নেই । সমস্যা সমাধান.

Answer 9

এছাড়াও এই সমস্যার মুখোমুখি। setroubleshoot আমার পরিবেশে কাজ করে বলে মনে হচ্ছে না তাই / var / লগ / বার্তাগুলিতে এরকম লগ রেকর্ড নেই। সেলইনক্স অক্ষম করা আমার পক্ষে বিকল্প ছিল না, তাই আমিও করেছি

restorecon -Rv ~/.ssh

এর পরে আরএসএ কী করে লগইন ঠিকঠাক কাজ করেছে।

Answer 10

আমার ক্ষেত্রে কারণ একটি customly সেট বিকল্প ছিল AuthorizedKeysFileফাইলে /etc/ssh/sshd_config। এটি অন্য ব্যবহারকারীর হোম দির ( /home/webmaster/.ssh/authorized_keys) এ সেট করা হয়েছিল , সুতরাং আমি যে ব্যবহারকারীকে লগ ইন করার চেষ্টা করছিলাম তার সেই ফাইল / ডিরেক্টরিতে অ্যাক্সেস ছিল না।

এটিকে পরিবর্তন করে এবং এসএসএস-সার্ভার ( service ssh restart) পুনরায় চালু করার পরে সবকিছু স্বাভাবিক অবস্থায় ফিরে আসে। আমি এখন আমার ব্যক্তিগত কী দ্বারা লগ ইন করতে পারি।

Answer 11

আমাদের ক্ষেত্রে সমস্যাগুলি এই বিষয়টির সাথে সম্পর্কিত ছিল যে আমাদের ফায়ারওয়াল এবং নাটিংয়ের নিয়ম সঠিকভাবে সেটআপ করা হয়নি।

পোর্ট 22, ভুল সার্ভারে পরিচালিত হচ্ছিল যেখানে আমাদের কী এবং ব্যবহারকারী স্বীকৃত ছিল না।

কেউ যদি এই জায়গায় পৌঁছে। tcpdump এবং টেলনেট আপনার বন্ধু হতে পারে

[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 সংস্করণ ব্যবহার করে তবে ট্র্যাফিকটি গন্তব্যে আসলেই আসছেন কিনা তা দেখতে আপনাকে গন্তব্যে একটি প্যাকড ট্রেস ব্যবহার করে দেখতে হবে।

এসএসএস প্রচুর ট্র্যাফিক তৈরি করতে পারে যা tcpdump তৈরি করে যা আপনার সন্ধান করছেন তা খুঁজে পাওয়া শক্ত করে।

এটি আমাকে সাহায্য করেছিল

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

আপনার বর্তমান কম্পিউটার @ [মাইলোকালিপ] নয় একটি 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".

এমনকি যদি আপনি সহজেই এই পদ্ধতিতে ডিবাগ করতে রিমোট সার্ভার কনফিগারেশনটি পরিবর্তন করতে না পারেন তবে একই দূরবর্তী সার্ভারের অর -রুট অ্যাকাউন্টে এসএসটি ফাইলগুলি ব্যবহার করার জন্য কেউ একই পরিমাণে একই ক্লায়েন্ট-সাইড কনফিগারেশনটি প্রমাণ করতে পারে ।

Answer 13

আমি দেখতে পাচ্ছি যে কেন সুরক্ষা মানুষকে বিরক্ত করতে পারে। আমি ssh won't use my keyআবার সমস্যা ছিল । আমি রিমোট সার্ভারে লগ ইন করে এটি চালিয়েছি

/usr/sbin/sshd -sDp 23456

এবং তারপরে আমার ডেস্কটপ থেকে (সার্ভারে যাওয়ার চেষ্টা করছে)

ssh -vvvv server -p 23456

সার্ভারে আমি পেয়েছি Authentication refused: bad ownership or modes for directory /

কিছু নতুন সিসাদমিন অনুমতি এবং মালিকানা সম্পর্কে গণ্ডগোল করেছিলেন, যা আমি এটি দিয়ে স্থির করেছি:

chmod 0755 / ; chown root:root /

(আমি প্রয়োজনে chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubঅভ্যস্ত কিন্তু এসএসডি চেকিং / রুট অনুমতিগুলি সন্ধান করা আমার জন্য নতুন)

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
....

User ব্যবহারকারীর জন্য পরিবর্তিত / ইত্যাদি / পাসডাব্লুডি ফাইল

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

Answer 15

সেন্টোস on এ আমার এই সমস্যাটি ছিল had আমি একটি নিয়মিত ডেবিয়ান-ভিত্তিক লিনাক্স ব্যবহারকারী তাই আমি জল থেকে বাইরে মাছ ছিল। আমি লক্ষ্য করেছি যে কয়েকটি সার্ভারে এটি কাজ করেছিল এবং কেবল একটিতে এটি কার্যকর হয়নি। অডিট.লগটি দরকারী কিছুই বলে নি এবং নিরাপদ.লগও কিছু দেয়নি। আমি দেখতে পেলাম যে প্রকৃত পার্থক্য ছিল ফাইল এবং ডিরেক্টরিগুলির মধ্যে যেগুলি কাজ করেছিল এবং যেগুলি করেনি তার মধ্যে কিছু সুরক্ষা প্রসঙ্গ পার্থক্য। এর সাথে সুরক্ষা পান

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/