আমি কেন পাবলিক কী প্রমাণীকরণ সহ এসএসএস সহ একটি পাসওয়ার্ড প্রম্পট পাচ্ছি?

Question

আমি এখানে পাওয়া URL টি থেকে কাজ করছি:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

আমার ssh ক্লায়েন্টটি উবুন্টু 64 বিট 11.10 ডেস্কটপ এবং আমার সার্ভারটি সেন্টোস 6.2 64 বিট। আমি নির্দেশাবলী অনুসরণ করেছি। আমি এখনও ssh এ একটি পাসওয়ার্ড প্রম্পট পাই।

আমি নিশ্চিত যে এর পরে কী করব।

Comments

আপনি কমান্ডটি আউটপুট দিয়ে যাচ্ছেন -v পতাকা সহ ssh? এই পেস্টবিন.com

— রব

আপনার .ssh ফোল্ডারটি নিশ্চিত করুনchmod 700

— রব

ধরে নিচ্ছি যে আপনি সার্ভারে রুট অ্যাক্সেস পেয়েছেন, /var/log/auth.logলগইন কেন ব্যর্থ হচ্ছে তা আপনাকে বলবে।

— উটাহ জারহেড

@ উটাহ জারহেড: সেন্টোস সার্ভারে এটি সম্ভবত রয়েছে /var/log/secure।

— ডেনিস উইলিয়ামসন

আকর্ষণীয়, chmod 0700উত্তর ছিল, কিন্তু আমি যখন ssh -vক্লায়েন্টের পক্ষ থেকে এটি কীটি গ্রহণ করা হয়নি কেন এটি সম্পর্কিত কোনও ত্রুটি নির্দেশ করে না, কেবল এটি বলেছিল যে আমার ক্লায়েন্ট একটি পাবলিক কী প্রেরণ করলেও এটি পরবর্তী পাসওয়ার্ড চেষ্টা করছে। তারা কীভাবে আমাদের সার্ভার থেকে কোনও ত্রুটি সম্পর্কিত তথ্য না দিয়ে সমস্যাগুলি নির্ণয়ের প্রত্যাশা করবে?

— void.pointer

Answer 1

~/.sshডিরেক্টরিতে এবং এর সামগ্রীর অনুমতি যথাযথ কিনা তা নিশ্চিত করুন । আমি যখন প্রথম আমার ssh কী লেখকটিকে সেট আপ করি তখন আমার ~/.sshফোল্ডারটি সঠিকভাবে সেট আপ করা হয়নি এবং এটি আমার দিকে চিত্কার করে।

• আপনার হোম ডিরেক্টরি ~, আপনার ~/.sshডিরেক্টরি এবং ~/.ssh/authorized_keysদূরবর্তী মেশিনে থাকা ফাইলটি কেবল আপনার দ্বারা লিখিত হতে হবে: rwx------এবং rwxr-xr-xভাল, তবে rwxrwx---কোনও ভাল নয় ¹ এমনকি আপনি যদি আপনার গ্রুপের একমাত্র ব্যবহারকারী হন (আপনি যদি সংখ্যার পদ্ধতিগুলি পছন্দ করেন: 700বা 755, না 775) ।
  যদি ~/.sshবা authorized_keysএকটি প্রতীকী লিঙ্ক হয় তবে ক্যানোনিকাল পাথ (প্রতীকী লিঙ্কগুলি প্রসারিত সহ) পরীক্ষা করা হয়েছে ।
• আপনার ~/.ssh/authorized_keysফাইলটি (রিমোট মেশিনে) অবশ্যই পঠনযোগ্য (কমপক্ষে 400) হতে হবে তবে আপনি যদি এটিতে আরও কী যুক্ত করেন তবে আপনার এটি লেখারও উপযুক্ত (600) হতে হবে।
• আপনার ব্যক্তিগত কী ফাইলটি (স্থানীয় মেশিনে) কেবল আপনার দ্বারা পঠনযোগ্য এবং লিখিত হতে হবে: rw-------যেমন 600।
• এছাড়াও, যদি সেলইনাক্স কার্যকর করার জন্য সেট করা থাকে তবে আপনার চালনার দরকার হতে পারে restorecon -R -v ~/.ssh(উদাহরণস্বরূপ উবুন্টু বাগ 965663 এবং ডিবিয়ান বাগ রিপোর্ট # 658675 ; এটি সেন্টোস 6 এ প্যাচ করা হয়েছে )।

Some _{কিছু বিতরণ (ডেবিয়ান এবং ডেরিভেটিভস) বাদে যা আপনার গ্রুপের একমাত্র ব্যবহারকারী হলে গ্রুপ রচনার অনুমতি দেওয়ার জন্য কোডটি প্যাচ করেছে।}

Comments

পুনরুদ্ধারকে নির্দেশ করার জন্য আপনাকে অনেক ধন্যবাদ। আমি কিছুক্ষণের জন্য এই সমস্যাটিতে অবাক হয়ে আমার মাথার চুলকানি করছি।

— রিচার্ড ব্যারেল

অদ্ভুতভাবে যথেষ্ট, একটি বন্ধু তার ভিপিএসে পাবকি লেখার কাজ করার জন্য একটি অ্যাকাউন্ট প্রস্তুত করে আমার সমস্যা হয়েছিল। আমি ভেবেছিলাম সমস্ত অনুমতি সঠিক ছিল, তবে এটি মনে রাখা গুরুত্বপূর্ণ যে এটি /home/USERহতে হবে 700বা755

— রব

এছাড়াও মালিক এবং গ্রুপ সেটিংস পরীক্ষা করে দেখুন, আমি কোনও অনুমোদিত_কিজ ফাইল অনুলিপি করার জন্য আরএসওয়াইএনসি ব্যবহার করেছি এবং লক্ষ্য করিনি যে মালিক / গোষ্ঠীটি রুটের পরিবর্তে 1000 এ সেট করা আছে!

— নাক

এছাড়াও, কীটি দিয়ে কী ঘটে তা দেখতে আপনার ssh কমান্ড -v যুক্ত করুন। ssh -v user@host।

— tedder42

chmod -R 700 ~/.sshএই উত্তরের সীমাবদ্ধতাগুলি পূরণ করার জন্য আমার পক্ষে কাজ করেছেন (RHEL 7)

— স্কটিসিয়াস

Answer 2

আপনার যদি সার্ভারে রুট অ্যাক্সেস থাকে, তবে সার্ভারের মতো কিছু সরবরাহ /usr/sbin/sshd -d -p 2222করে (sshd এক্সিকিউটেবলের সম্পূর্ণ পথ প্রয়োজন, which sshdসহায়তা করতে পারে) এবং এর সাথে ক্লায়েন্টের সাথে সংযোগ স্থাপনের মাধ্যমে এই জাতীয় সমস্যাগুলি সমাধানের সহজ উপায় হ'ল ডিবাগ মোডে sshd চালানো ssh -p 2222 user@host। এটি এসএসএইচ ডেমনকে অগ্রভাগে থাকতে বাধ্য করবে এবং প্রতিটি সংযোগ সম্পর্কে ডিবাগ তথ্য প্রদর্শন করবে। এরকম কিছু সন্ধান করুন

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

যদি বিকল্প পোর্ট ব্যবহার করা সম্ভব না হয় তবে আপনি অস্থায়ীভাবে এসএসএইচ ডেমন থামাতে পারেন এবং এটি একটি ডিবাগ মোডের সাথে প্রতিস্থাপন করতে পারেন। এসএসএইচ ডেমন থামানো বিদ্যমান সংযোগগুলিকে হত্যা করে না তাই এটি দূরবর্তী টার্মিনালের মাধ্যমে এটি করা সম্ভব, তবে কিছুটা ঝুঁকিপূর্ণ - যদি সংযোগটি কোনওরকমভাবে ভেঙে যায় এমন সময়ে যখন ডিবাগ প্রতিস্থাপন চলমান না থাকে, আপনি মেশিন থেকে লক আউট হয়ে গেছেন if যতক্ষণ না আপনি এটি পুনরায় চালু করতে পারেন। প্রয়োজনীয় আদেশগুলি:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(আপনার লিনাক্স বিতরণের উপর নির্ভর করে প্রথম / শেষ লাইনটি তার পরিবর্তে systemctl stop sshd.service/ হতে পারে systemctl start sshd.service))

Comments

আমি কেবল এটি চেষ্টা করেছি ... এবং আমি যখন দৌড়াব তখন এটি ঠিকঠাক কাজ করে sshd -d, তবে একবার আসার পরে ব্যর্থ হয় service sshd start। আমি নিশ্চিত যে এটি সহজ, তবে আমি লিনাক্স গুরু নই। কোন চিন্তা?

— এন রোহলার

রেফারেন্সের জন্য, এই পোস্টটি সেলইনাক্স সমাধানটি ব্যাখ্যা করে যা আমার সমস্যার সমাধান করেছে।

— এন রোহলার

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

— ub3rst4r

দুর্দান্ত পরামর্শ, আমার ব্যবহারকারীর ফোল্ডারটি ভুল অনুমতি নিয়ে ছিল।

— জিডিএফবারবোসা

ধন্যবাদ. সব কারণেই, আমার ব্যবহারকারীর লগ ইন করার অনুমতি ছিল না কারণ ব্যবহারকারী তৈরিতে উত্তরযোগ্য (/ বিন / zsh) দ্বারা নির্দিষ্ট শেলটি বিদ্যমান ছিল না। আমি কখনই অনুমান করতাম না।

— চিশকু

Answer 3

আপনার বাড়ির দির এনক্রিপ্ট করা আছে? যদি তা হয় তবে আপনার প্রথম ssh সেশনের জন্য আপনাকে একটি পাসওয়ার্ড সরবরাহ করতে হবে। একই সার্ভারে দ্বিতীয় ssh অধিবেশন প্রমানের কী নিয়ে কাজ করছে। যদি এটি হয় তবে authorized_keysআপনি একটি এনক্রিপ্ট করা দির কাছে যেতে পারেন এবং পথটি পরিবর্তন করতে পারেন ~/.ssh/config।

আমি যা করতে পেরেছি তা হ'ল /etc/ssh/usernameসঠিক অনুমতি সহ ব্যবহারকারীর নামে মালিকানাধীন একটি ফোল্ডার তৈরি করা এবং authorized_keysফাইলটি সেখানে রেখে দেওয়া। তারপরে অথরাইজডকিজফাইলে নির্দেশিকা এতে পরিবর্তন করে /etc/ssh/config:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

অনুমতিগুলির সাথে আপস না করে একাধিক ব্যবহারকারীকে এই এসএসএস অ্যাক্সেসের অনুমতি দেয়।

Comments

এতে উবুন্টু ডক: হেল্প.বুন্টু.com

— ফ্যাব ভি।

এই উত্তরটি মুখ্য এবং এটি আমাকে সহায়তা করেছে - যে কেউ যদি এই সমস্যাটি নিয়ে ভাবছেন তবে আপনি আপনার auth.log এ "pam_ecryptfs: পাসফ্রেজ ফাইল মোড়ানো" দেখতে পাবেন; হোমিডির এনক্রিপ্ট করা ছিল তা মনে করার জন্য আমাকে অনুরোধ করার মতো কোনওরকম যথেষ্ট ছিল না। এছাড়াও আপনি প্রথম লগন একটি পাসওয়ার্ড জিজ্ঞাসা করতে পারেন, পরবর্তী সেশনগুলি না করে (যেহেতু এটি অন্যান্য সেশনগুলি খোলার সময় ডিক্রিপ্ট করা থাকে)।

— প্রশান্তবাদী

পবিত্র বোকা আমি এই সমস্যাটি সমাধান করার জন্য দীর্ঘকালীনভাবে অনুসন্ধান করেছি, আপনাকে এতটা ধন্যবাদ জানাই!

— এইচ 3।

Answer 4

রিমোট মেশিনে কীগুলি অনুলিপি করার পরে সেগুলি আপনার ভিতরে রাখার পরে authorized_keysআপনাকে এই জাতীয় কিছু করতে হবে:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Comments

আসলে না আপনি না। কী এজেন্ট ব্যবহার না করে ssh স্বয়ংক্রিয়ভাবে ~ / .ssh / id_rsa (বা id_dsa) ব্যবহার করে।

— প্যাট্রিক

যদি কেউ ~ / .ssh / কনফিগারেশনে (যেমন হোস্ট * .mydomain.org ... আইডেন্টিটি ফাইলে। / .Ssh / কিছু_সিলিয়েট_ইউজ.পব - এসএসএস-অ্যাড ~ / .ssh / some_limited_use.pub)।

— 89c3b1b8-b1ae-11e6-b842-48d705

এটি একটি কী যুক্ত করার পরে পাসওয়ার্ড প্রম্পট পাওয়ার সাথে আমার সমস্যার সমাধান করেছে। 89c3b1b8-b1ae-11e6-b842-48d705 হিসাবে উল্লেখ করা হয়েছে যে, এই কমান্ডগুলি ম্যানুয়ালি চালানোর কারণ কী ফাইলের একটি অ-মানক নাম ছিল।

— 40 Лисаков

মন্তব্যে উপরে উল্লিখিত হিসাবে, আপনি যদি ডিফল্ট কী ছাড়াও কোনও কী ব্যবহার করেন তবে এটি ডিফল্টরূপে ssh এজেন্টে যুক্ত করা হয় না। সুতরাং আপনি যে চাবিটি ব্যবহার করতে চান তা অবশ্যই এজেন্টের কীচেইনে রয়েছে তা পরীক্ষা করে দেখুন:ssh-add -L

— জেমস

Answer 5

এই নিম্নলিখিত আদেশগুলি চেষ্টা করুন

1. ssh-keygen

   আপনি প্রম্পট না পাওয়া পর্যন্ত এন্টার কী টিপুন

2. ssh-copy-id -i root@ip_address

   (এটি একবার হোস্ট সিস্টেমের পাসওয়ার্ড জানতে চাইবে)

3. ssh root@ip_address

   এখন আপনার কোনও পাসওয়ার্ড ছাড়াই লগইন করতে সক্ষম হওয়া উচিত

Comments

কোন সার্ভারে?

— অমলগোভিনাস

@ অমলগোভিনাস স্পষ্টতই আপনি এটি ক্লায়েন্টের উপর চালাচ্ছেন, আপনি যে মেশিনটি সংযুক্ত করছেন তা নয় - আপনি সার্ভারে আপনার ব্যক্তিগত কীটির অনুলিপি চান না! :)

— নেভেলিস

দয়া করে মনে রাখবেন যে সাধারণত, দূরবর্তী রুট লগইনগুলিকে অনুমতি দেওয়া কোনও প্রস্তাবিত সুরক্ষা অনুশীলন নয় is

— আরিফেল

Answer 6

আমি যখন চ্যালেঞ্জের মুখোমুখি হই তখন যখন দূরবর্তী হোম ডিরেক্টরিতে সঠিক সুযোগ সুবিধা না থাকে। আমার ক্ষেত্রে ব্যবহারকারী দলে কিছু লোকাল অ্যাক্সেসের জন্য হোম ডিরটি 777 এ পরিবর্তন করেছে । মেশিনটি আর আর ssh কীগুলির সাথে সংযোগ করতে পারে না। আমি অনুমতিটি 744 এ পরিবর্তন করেছি এবং এটি আবার কাজ শুরু করে।

Comments

আমাদেরও এই সমস্যা ছিল - হোম

— ডায়ারগুলিতে

আমার অনুমতি ছিল to77 এ সেট করা এবং এটি উপেক্ষা করা হয়েছে, ধন্যবাদ !!!

— কা_লিন

একই অবস্থা. ধন্যবাদ। কিছুক্ষণের জন্য আমার মাথা আঁচড়ে যাচ্ছিল, ডব্লিউটিএফ হচ্ছিল।

— মার্সিন

হ্যাঁ আরও বিস্তারিত তথ্যের

— টিম

এটি সেই লোকদের পক্ষে উত্তর হতে পারে যারা মূল প্রজন্মটি সঠিকভাবে করেছেন এখনও এখনও একটি পাসওয়ার্ডের জন্য অনুরোধ করা হচ্ছে।

— ফারজি

Answer 7

রেডহ্যাট / সেন্টোস on এ থাকা সেলইনাক্সের পাবকি প্রমাণীকরণের সাথে একটি সমস্যা রয়েছে , সম্ভবত কিছু ফাইল যখন সেলিনাক্স তৈরি করা হয় তখন তার এসিএলগুলি সঠিকভাবে সেট করে না।

রুট ব্যবহারকারীর জন্য নিজেই সেলিনাক্স এসিএলগুলি ঠিক করতে:

restorecon -R -v /root/.ssh

Comments

উইন্ডোজে ওপেনশাহ ক্লায়েন্ট ব্যবহার করে আমি ইস্যু ছাড়াই ssh root@mymachineএকটি সেন্টোস 6 এ সক্ষম হয়েছি mymachine, তবে আমার একটি নিম্ন-বেসরকারী ব্যবহারকারী রয়েছে যা আমি ব্যবহার করতে পছন্দ করি তবে ssh regularUser@mymachineতবুও আমাকে পাসওয়ার্ডের জন্য অনুরোধ জানায়। চিন্তা ভাবনা আছে?

— গ্রোস্টাভ

Answer 8

আমরা একই সমস্যায় পড়েছি এবং উত্তরের পদক্ষেপগুলি অনুসরণ করেছি। তবে এটি এখনও আমাদের কাজ করে নি। আমাদের সমস্যাটি হ'ল লগইনটি একটি ক্লায়েন্টের কাছ থেকে কাজ করেছিল তবে অন্যের কাছ থেকে নয় (.ssh ডিরেক্টরিটি এনএফএস মাউন্ট করা ছিল এবং উভয় ক্লায়েন্ট একই কী ব্যবহার করেছিল)।

সুতরাং আমাদের আরও এক ধাপ এগিয়ে যেতে হয়েছিল। ভার্জোজ মোডে ssh কমান্ড চালিয়ে আপনি প্রচুর তথ্য পাবেন।

ssh -vv user@host

আমরা যা আবিষ্কার করেছি তা হ'ল ডিফল্ট কী (id_rsa) গৃহীত হয়নি এবং পরিবর্তে ssh ক্লায়েন্ট ক্লায়েন্টের হোস্টনামের সাথে মিলে একটি কী সরবরাহ করেছিল:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

অবশ্যই এটি অন্য কোনও ক্লায়েন্টের কাছ থেকে কাজ করবে না।

সুতরাং আমাদের ক্ষেত্রে সমাধানটি হ'ল ডিফল্ট আরএসএ কীটি ব্যবহারকারীর @ মাইক্লিয়েন্টে থাকা একটিতে স্যুইচ করা। যখন কোনও কী ডিফল্ট হয়, ক্লায়েন্টের নামের জন্য কোনও পরীক্ষা করা হয় না।

তারপরে আমরা দৌড়ে গেলাম অন্য সমস্যার মধ্যে, স্যুইচের পরে। স্পষ্টতই কীগুলি স্থানীয় ssh এজেন্টে ক্যাশে করা হয়েছে এবং আমরা ডিবাগ লগে নিম্নলিখিত ত্রুটিটি পেয়েছি:

'Agent admitted failure to sign using the key'

এটি ssh এজেন্টের চাবিগুলি পুনরায় লোড করে সমাধান করা হয়েছিল:

ssh-add

Answer 9

এটি সার্ভারের শেষে এসএসএইচ মিস কনফিগারেশন হবে। সার্ভারের পাশের sshd_config ফাইলটি সম্পাদনা করতে হবে। মধ্যে অবস্থিত /etc/ssh/sshd_config। এই ফাইলটিতে পরিবর্তনশীল পরিবর্তন করুন change

• চ্যালেঞ্জ রিসপনস অরথ্যান্টিকেশন, পাসওয়ার্ডঅথেন্টিফিকেশন, ইউজপ্যামের জন্য 'হ্যাঁ' থেকে 'না'

• PubkeyAuthentication এর জন্য 'না' থেকে 'হ্যাঁ'

Http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/ এর উপর ভিত্তি করে

Comments

প্রশ্নের মতামত হিসাবে / var / লগ / নিরাপদ বা /var/log/auth.log দেখুন check আমার ক্ষেত্রে আমি দেখতে পাচ্ছি "এক্সএক্সএক্সএর ইউজার এক্সএক্সএক্স অনুমোদিত নয় কারণ" মঞ্জুরিপ্রাপ্ত ব্যবহারকারীদের মধ্যে তালিকাভুক্ত নয় "" ইনপুট_সেসরথ_উইকুইস্ট: অবৈধ ব্যবহারকারী এক্সএক্সএক্স [পূর্বসূত্র] "(এবং" রেক্সেক লাইন 35: / var / লগ / বার্তাগুলিতে অবজ্ঞাত বিকল্প সার্ভারকেবিটস ") যদিও আমি কী জানি না এটাই). সমাধানের জন্য vi /etc/ssh/sshd_config, ব্যবহারকারীদের তালিকায় ব্যবহারকারী এক্সএক্সএক্সএক্স যুক্ত করুন, service sshd restart*** খারাপ sshd_config দিয়ে sshd পরিষেবা পুনরায় চালু করা সতর্কতা আপনাকে একটি বাক্স থেকে লক আউট করতে পারে !? ***। কাজ করেছে।

— গাইতে

Answer 10

AuthorizedKeysFileসঠিক অবস্থানটি নির্দেশ করে তা নিশ্চিত করুন , %uব্যবহারকারীর নাম হিসাবে স্থানধারক হিসাবে ব্যবহার করুন :

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

এটি হতে পারে যে আপনার কেবল লাইনটি অসুবিধে করতে হবে:

অনুমোদিত কুকিফাইলে .ssh / অনুমোদিত_কিগুলি ys

মনে রাখবেন যে পরিবর্তনগুলি করার জন্য আপনাকে অবশ্যই ssh পরিষেবাটি পুনরায় লোড করতে হবে:

service sshd reload

Answer 11

দুটি মন্তব্য: এটি মূল ফাইলটি ওভাররাইট করবে। আমি তৈরি করা সর্বজনীন কীটি অনুলিপি করে কিছু করব:

cat your_public_key.pub >> .ssh/authorized_keys

আপনি কীগুলি প্রাক-বিদ্যমান তালিকার তালিকায় ব্যবহার করতে চান এটি এতে যুক্ত হবে। এছাড়াও, কিছু সিস্টেম ফাইল ব্যবহার করে authorized_keys2, তাই কেবলমাত্র ক্ষেত্রে authorized_keysএবং এর মধ্যে একটি হার্ড লিঙ্ককে নির্দেশ করা ভাল ধারণা authorized_keys2।

Comments

হ্যাঁ, আমি এটি ওভাররাইট সম্পর্কেও লক্ষ্য করেছি, তবে আমার কোনও কিছু নেই, তাই এটি কোনও ব্যাপার নয়। আমি অনুমোদিত_কিস 2 তে একটি সিমিলিংক তৈরি করেছি তবে তাতে কোনও লাভ হয়নি।

— থম

এছাড়াও, ফাইল / ডিরেক্টরি অনুমতি পরীক্ষা করে দেখুন। আপনার প্রদত্ত ওয়েবসাইটে সেগুলি বর্ণনা করা হয়।

— Wojtek Rzepala

আপনার। / .ssh dir অবশ্যই 700 টি হতে হবে আপনার প্রাইভেট কী ফাইলটি 600 হতে হবে আপনার পাবলিক কী ফাইলটি অবশ্যই 644 আপনার লেখক ফাইল (রিমোটে) হতে হবে 644

— রব

@ রব যে সমস্যা ছিল। আপনি যদি উত্তর হিসাবে পোস্ট করেন তবে আমি এটি গ্রহণ করব।

— থম

Answer 12

আমার সমাধানটি ছিল যে অ্যাকাউন্টটি লক হয়ে গেছে। বার্তাটি / var / লগ / নিরাপদে পাওয়া গেছে: ব্যবহারকারীর অনুমতি নেই কারণ অ্যাকাউন্ট লক করা আছে সমাধান: ব্যবহারকারীকে একটি নতুন পাসওয়ার্ড দিন।

Comments

আমি পাসওয়ার্ড ক্ষেত্রের পরিবর্তন করে এটি সংশোধন করা /etc/shadowথেকে এই ব্যবহারকারীর জন্য !করতে *। এরপরে পাসওয়ার্ড প্রমাণীকরণ এখনও অসম্ভব তবে ব্যবহারকারী আর লকড নেই।

— ব্যবহারকারী3132194

Answer 13

আমি একই ধরণের সমস্যায় পড়েছি এবং ডিবাগ মোডটি ব্যবহার করে পদক্ষেপগুলি অনুসরণ করেছি।

/usr/sbin/sshd -d

এটি নিম্নলিখিত ফলাফল দেখিয়েছে

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

এটা সত্যিই বিভ্রান্তিকর ছিল

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

এটি দেখায় যে রুট ডিরেক্টরিটিতে প্রত্যেকের জন্য অনুমতি রয়েছে। আমরা এটি পরিবর্তন করেছি যাতে অন্যের অনুমতি না হয়।

[root@sys-135 ~]# chmod 750 /root

কী প্রমাণীকরণ কাজ শুরু।

Comments

আমার একই সমস্যা আছে। গতকাল, আমি rsync -av ./root/ root@THE_HOST:/rootআমার স্থানীয় ওয়ার্কিং ডিরেক্টরি থেকে কিছু ফাইল আপলোড করার জন্য জারি করেছি, তারপরে, এই সমস্যাটি ঘটেছিল (বাস্তবে, প্রথমে আমি এটি লক্ষ্য করিনি the পরের দিন সকালে অন্যান্য হোস্টগুলিতে ক্রোন চাকরি ব্যর্থ হওয়ার পরে, আমি কারণটি খনন করতে শুরু করেছি) । rsync -av ./root/ root@THE_HOST:/rootকমান্ড মালিক এবং অনুমতি পরিবর্তিত /rootদূরবর্তী হোস্ট নির্দেশিকা। অনুমতি স্থির, সমস্যা সমাধান।

— লিউইয়ান 研

Failed publickey for root from 135.250.24.32 port 54553 ssh2আমি কোনও হোস্টে পাবকি যুক্ত করতে ভুলে গেলে আমি একই বার্তা এবং ইস্যু পাই authorized_keys। আমার মত এই মন্তব্যটি যুক্ত করার পরে, আমি সাধারণত আমার ভুলটি বুঝতে পারি ডিবাগ এবং সমস্ত অনুমতি প্লাস কনফিগারেশন ফাইলগুলি পরীক্ষা করার পরে #: o <

— tuk0z

Answer 14

/ ইত্যাদি / সেলিনাক্স / কনফিগারেশন ফাইলটিতে SELUX পরিবর্তিত পাসওয়ার্ডহীন ssh কাজ সফলভাবে কার্যকর করা থেকে অক্ষম করা হয়েছে।

আগে আমি এটি এক উপায়ে করতে সক্ষম হয়েছি। এখন উভয় দিক থেকেই আমি পাসওয়ার্ডহীন এসএসএস করতে সক্ষম।

Answer 15

একটি জিনিস যা আমার ভুল ছিল তা হ'ল সার্ভার সিস্টেমে আমার হোম ডিরেক্টরিতে মালিকানা। সার্ভার সিস্টেমটি ডিফল্ট হিসাবে সেট করা হয়েছিল: ডিফল্ট তাই আমি:

chown -R root:root /root

এবং এটা কাজ করে. আর একটি সস্তার কাজ হ'ল স্ট্রাইকডমডস অক্ষম করা: স্ট্রিটমোড নং। sshd_config এ। কী এক্সচেঞ্জ এবং সংযোগ প্রোটোকলগুলি ভাল কিনা এটি আপনাকে অন্ততপক্ষে বলবে। তারপরে আপনি খারাপ অনুমতিগুলি শিকার করতে পারেন।

Comments

আমিও. / Var / লগ / সুরক্ষিত বার্তাগুলি দেখুন। আমি একটি বার্তা দেখেছি: "প্রমাণীকরণ অস্বীকার করেছে: খারাপ মালিকানা বা ডিরেক্টরির জন্য পদ্ধতি" (OME হোম)। নিশ্চিত হয়ে নিন যে এখানে to হোম বা গ্রুপে অন্যের লেখার অ্যাক্সেস নেই। সার্ভারে আমার অননুমোদিত রুট অ্যাক্সেস না থাকলে আমি কখনই এটি

— পেতাম না

Answer 16

আমার জন্য, সমাধানটি ওয়াজটেক রাজেপালার বিপরীতে ছিল : আমি এখনও খেয়াল করিনি যে আমি এখনও ব্যবহার করছি authorized_keys2, যা অবমূল্যায়ন করা হয়েছে । আমার ssh সেটআপটি সার্ভার আপডেট হওয়ার পরে সম্ভবত কিছু সময়ে কাজ করা বন্ধ করে দিয়েছে। পুনঃনামকরণ .ssh/authorized_keys2হিসাবে .ssh/authorized_keysসমস্যা স্থির।

ডি আহা!

Comments

এটি / etc / ssh / sshd_config এ একটি কনফিগারেশন বিকল্পও রয়েছে, যদিও আমি মনে করি এটির মতো নামকরণ করেছি আপনার মতো।

— রিক স্মিথ 21 ই

Answer 17

অতীতে আমি কয়েকটি টিউটোরিয়াল পেয়েছিলাম যা কীভাবে একটি এসএস পাসওয়ার্ড-কম সেটআপ অর্জন করতে পারে তা বর্ণনা করে তবে কয়েকটি দুঃখজনকভাবে ভুল।
আবার শুরু করা যাক, এবং প্রতিটি পদক্ষেপ পরীক্ষা করুন:

1. ক্লায়েন্ট থেকে - উত্পন্ন কী: ssh-keygen -t rsa
   সরকারী এবং ব্যক্তিগত কী ( id_rsa.pubএবং id_rsa) ~/.ssh/ডিরেক্টরিতে স্বয়ংক্রিয়ভাবে সংরক্ষণ করা হবে ।
   আপনি যদি খালি পাসফ্রেজ ব্যবহার করেন তবে সেটআপ সহজ হবে। আপনি যদি এটি করতে রাজি না হন তবে এখনও এই গাইডটি অনুসরণ করুন তবে নীচের বুলেট পয়েন্টটিও দেখুন।
   
   
2. ক্লায়েন্টের কাছ থেকে - সার্ভারে সর্বজনীন কী অনুলিপি করুন : ssh-copy-id user@server
   ক্লায়েন্টের সর্বজনীন কী সার্ভারের অবস্থানে অনুলিপি করা হবে ~/.ssh/authorized_keys।
   
   
3. ক্লায়েন্ট থেকে - সার্ভারে সংযুক্ত:ssh user@server
   
   

এখন, যদি এটি এখনও বর্ণিত 3 টি পদক্ষেপের পরে কাজ না করে তবে আসুন নিম্নলিখিত বিষয়গুলি চেষ্টা করুন:

• ক্লায়েন্ট এবং সার্ভার মেশিনে ~/sshফোল্ডার অনুমতি পরীক্ষা করুন ।
• পরীক্ষা করে দেখুন /etc/ssh/sshd_configযে সার্ভার তা নিশ্চিত করতে RSAAuthentication, PubkeyAuthenticationএবং UsePAMবিকল্প নিষ্ক্রিয় করা হয়েছে করা হয় না, তারা ডিফল্ট সক্ষম করতে পারেন yes।
• আপনি একটি পাসফ্রেজ এন্টার করেন, তাহলে আপনার ক্লায়েন্ট কী জেনারেট করার সময়, তাহলে আপনি চেষ্টা করতে পারেন ssh-agent& ssh-addআপনার সেশনে পাসওয়ার্ড কম সংযোগ অর্জন করা।
• বিষয়বস্তু চেক /var/log/auth.logউপর সার্ভার সমস্যা কেন কী প্রমাণীকরণ এ সব এড়িয়ে যাওয়া হবে কি খুঁজে পেতে।

Comments

পদক্ষেপগুলি তালিকাভুক্ত করার জন্য ধন্যবাদ! আমি "ssh-copy-id ব্যবহারকারী @ সার্ভার" পেয়েছি এবং বুঝতে পেরেছি যে আমি মূলত ভুল পাবলিক কীতে অনুলিপি করেছি।

— মত্তাভাটার

Answer 18

পুটিটিওয়াই কোনও উবুন্টু 16.04 মেশিনে সংযোগ করার ক্ষেত্রে আমার ঠিক একই সমস্যা ছিল। এটি বিস্ময়কর ছিল কারণ পটিটির ওয়াইএসসিপি প্রোগ্রাম একই কী (এবং একই কীটি অন্য হোস্টের সাথে সংযোগ স্থাপনের জন্য পিটিটিওয়াইতে কাজ করেছিল) দিয়ে দুর্দান্ত কাজ করছিল।

@ উটাহ জারহেডের মূল্যবান মন্তব্যের জন্য ধন্যবাদ, আমি আমার /var/log/auth.log ফাইলটি যাচাই করে নীচের বিষয়গুলি খুঁজে পেয়েছি:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

দেখা যাচ্ছে যে ওপেনএসএসএইচের নতুন সংস্করণগুলি ডিএসএ কীগুলি ডিফল্টরূপে গ্রহণ করে না। একবার আমি কোনও ডিএসএ থেকে আরএসএ কীতে স্যুইচ করেছি, এটি দুর্দান্ত কাজ করেছে।

আরেকটি পদ্ধতির: এই প্রশ্নটি কীভাবে ডিএসএ কীগুলি গ্রহণ করতে এসএসএইচ সার্ভারটি কনফিগার করতে হবে তা আলোচনা করে: https://superuser.com = 1

Answer 19

এই পদক্ষেপগুলি আপনাকে সাহায্য করবে। আমি এটি অনেকগুলি 64 বিট উবুন্টু 10.04 মেশিনের মধ্যে নিয়মিত ব্যবহার করি।

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

আপনি কিছু প্রম্পট সহ এটি কোনও স্ক্রিপ্টে রাখতে পারেন এবং এটি হিসাবে অনুরোধ করতে পারেন

script_name username remote_machine

Comments

ইতিমধ্যে উপস্থিত রয়েছে ssh-copy-idযা শেষ দুটি পদক্ষেপ স্বয়ংক্রিয়ভাবে করে।

— জোফেল

@ জোফেল মনে রাখবেন যে অনেক সিস্টেমে ssh-copy-id এর অস্তিত্ব নেই। @ শ্রীহর্ষার পরে আপনারও mkdirসেখানে যোগ করা উচিত এবং বিটিডব্লিউ আপনার সাথে এতটা ভারবস হওয়ার chmod 700 .sshদরকার নেই ~/.ssh, ঠিক .sshযেহেতু হোম ডিরেক্টরিতে কমান্ডগুলি কার্যকর করা যায়

— জানোস

Answer 20

Ssh এর সাথে আমারও একই সমস্যা ছিল। আমার ক্ষেত্রে সমস্যাটি হ'ল আমি হ্যাডোপ ক্লৌডেরা ইনস্টল করেছি (সেন্টোস on এর আরপিএম থেকে) এবং এটি হোম ডিরেক্টরি সহ ইউজার এইচডিএফ তৈরি করেছে

/var/lib/hadoop-hdfs(মান নয় /home/hdfs)

আমি পরিবর্তন / etc / passwd /var/lib/hadoop-hdfsকরতে /home/hdfs, নতুন অবস্থানে home ডিরেক্টরিতে সরানো এবং এখন আমি পাবলিক কী প্রমাণীকরণের সাথে সংযোগ করতে পারেন।

Answer 21

আমার ঠিক এই একই সমস্যা ছিল, এবং আমার জন্য সমাধানটি সেট UsePAMকরা ছিল no। দেখুন, এমনকি PasswordAuthenticationসেট করা noসত্ত্বেও, আপনি এখনও পাবেন keyboard-interactiveএবং আমার ক্ষেত্রে আমার স্থানীয় এসএস প্রোগ্রামটি কোনও কারণে ডিফল্ট রেখে দিয়েছে।

একই পরিস্থিতি সহ যে কাউকে সহায়তা করার জন্য অতিরিক্ত ব্যাকগ্রাউন্ড: আমি হোস্ট ড্রপবার থেকে চলমান একটি ওপেনএসএসএইচে সংযোগ করছি। সঙ্গে PasswordAuthenticationএবং UsePAMউভয় সেট noদূরবর্তী মেশিনে, আমি নিম্নলিখিত বার্তা যদি আমি লিখতে পাবেন ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

পরিচয় ফাইল সরবরাহ করে -i, সবকিছু প্রত্যাশার মতো কাজ করে।

এখানে আরও কিছু তথ্য থাকতে পারে।

Answer 22

অনুমতিগুলি যাচাই করার পরে এবং এখানে তালিকাভুক্ত আরও কয়েকটি সমাধানের চেষ্টা করার পরে, আমি অবশেষে সার্ভারের ssh ডিরেক্টরিটি সরিয়ে ফেললাম, আমার সার্বজনীন কীটি আবার সেটআপ করুন।

সার্ভার কমান্ড:

# rm -rf ~/.ssh

স্থানীয় আদেশগুলি:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Answer 23

সার্ভারে:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

এটা ছিল directory permission issue। এটি সার্ভারে ছিল 777, তাই I changed it back to 700। সার্ভারে অনুলিপি করার পরেও এটি fixedআমার সমস্যা ।ssh password less login failure$USER/.ssh/id_rsa.pub$USER/.ssh/authorized_keys

Comments

এছাড়াও দেখুন ডেভেরেটেট.আর্টিকেলস

— ওলুমাইড

Answer 24

তবুও অন্য কোনো বিকল্প @Jagadish এর একটি বৈচিত্র হয় উত্তর হবে: straceSSH ডেমন।

এর উল্লেখযোগ্য সুবিধা রয়েছে যে আমাদের এসএসডি বন্ধ করার দরকার নেই, কিছু খারাপভাবে চলে গেলে সম্পূর্ণ লকআউট কী হতে পারে।

প্রথমত, আমরা মূল sshd প্রক্রিয়াটির পিড খুঁজে পাই। এখানে আমরা একটি নির্বাহ দ্বারা দেখতে পারেন pstree -pa|less।

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

পিডটি 633 জেনে যাওয়ার পরে, আমরা straceএটির শিশুদের অনুসরণ করতে পারি:

strace -p 633 -s 4096 -f -o sux

ফলে হতে হবে সবকিছু কি এই sshd কমান্ড, এবং তার সন্তান প্রসেস করেছি, নামে ফাইলে strace-ED হতে হবে suxস্থানীয় ডিরেক্টরির মধ্যে।

তারপরে সমস্যাটি পুনরুত্পাদন করুন।

এটিতে কার্নেল কল লগের একটি বৃহত তালিকা থাকবে যা আমাদের জন্য বেশিরভাগ ক্ষেত্রেই বোধগম্য / অপ্রাসঙ্গিক তবে সর্বত্র নয়। আমার ক্ষেত্রে, গুরুত্বপূর্ণ বিষয়টি ছিল:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

এটির অর্থ ছিল, এসএসডিডি ইউজার সিকা ম্যাসেজটি লগ করার চেষ্টা করেছিল যে অ্যাকাউন্ট লক করা আছে - এটি কেবল পারেনি, কারণ লগিং এর জন্য পর্যাপ্ত ভার্বোজ নয় । তবে আমরা ইতিমধ্যে জানি, অ্যাকাউন্টটি লক হওয়ার কারণে পাব্বিকে প্রত্যাখ্যান করা হয়েছিল।

এটি এখনও কোনও সমাধান নয় - এখন আমাদের গুগল প্রয়োজন, এসএসডি ক্ষেত্রে "লক করা অ্যাকাউন্ট" অর্থ কী। এটি সম্ভবত কিছু তুচ্ছ /etc/passwd, /etc/shadowউইজার্ডারি হবে তবে গুরুত্বপূর্ণ কাজটি করা হয়েছে - সমস্যাটি রহস্যজনক নয়, তবে সহজেই ডিবাজেযোগ্য / গুগলযোগ্য।

Answer 25

আমার ক্ষেত্রে আমার কাছে সমস্ত অনুমতি ছিল এবং এমনকি --vvv পতাকা সহ ssh চালানোর পরেও আমি সমস্যাটি কী তা বুঝতে পারি না।

তাই আমি রিমোট হোস্টে নতুন শংসাপত্র তৈরি করেছি

ssh-keygen -t rsa -C "[e-mail]"

এবং স্থানীয় মেশিনে উত্পন্ন কীগুলি অনুলিপি করে এবং দূরবর্তী হোস্টে public / .ssh / अधिकृत_keys এ নতুন পাবলিক কী যুক্ত করেছে

cat id_rsa.pub >> authorized_keys

রিমোট হোস্ট মেশিন সংযোগ থেকে উত্পন্ন কীগুলি ব্যবহার করা এখন কাজ করে। সুতরাং যদি অন্য সমাধানগুলি ব্যর্থ হয় তবে এটি চেষ্টা করার অন্য জিনিস।

Answer 26

আমার পরিস্থিতিটি ছিল যে আমার কাছে একটি এনএএস সার্ভার রয়েছে যার উপর আমি একটি backupbotপ্রাথমিক অ্যাকাউন্ট তৈরি করার পরে একটি ব্যবহারকারী তৈরি করেছি, যা প্রাথমিকভাবে backupbotব্যবহারকারী তৈরি করতে লগ ইন করতে সক্ষম হয়েছিল । বিব্রতকর sudo vim /etc/ssh/sshd_configএবং backupbotব্যবহারকারী তৈরি করার পরে vim, কমপক্ষে উবুন্টু ১.0.০৪-এ তৈরি করতে পারে এবং আপনার ~/.vimrcকনফিগারেশনের উপর ভিত্তি করে , আপনার ভিএম সেশনের সম্পাদনা থেকে একটি সোয়াপ ফাইল বাকী থাকে /etc/ssh/sshd_config।

/etc/ssh/.sshd_config.swpউপস্থিত রয়েছে কিনা তা পরীক্ষা করে দেখুন এবং এটি এটি মুছে ফেললে এবং sshdডিমনটি পুনরায় চালু করে :

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

এটি ম্যাজিকভাবে আমার সমস্যা সমাধান করেছে। আমি এর আগে আমার সমস্ত অনুমতি এবং এমনকি সরকারী এবং ব্যক্তিগত কীগুলির আরএসএ আঙুলের ছাপগুলি পরীক্ষা করেছিলাম। এটি বিস্ময়কর এবং সম্ভবত একটি বাগ সহ sshdবিশেষত এই সংস্করণ:

ওপেনএসএসএইচ_7.4 পি 1 উবুন্টু -10, ওপেনএসএসএল 1.0.2 জি 1 মার্চ 2016