লিনাক্স এসএসএস: প্রাইভেট কী-তে পড়ার অধিকার না দিয়ে জন-কী প্রমাণীকরণের অনুমতি দিন

Question

আমার লিনাক্স সার্ভারে লগ ইন করা ব্যবহারকারীদের একটি নির্দিষ্ট দূরবর্তী মেশিনে একটি ডিফল্ট অ্যাকাউন্টের সাথে সংযোগ করতে সক্ষম হওয়া উচিত। রিমোট মেশিনে প্রমাণীকরণ পাবলিক কী ব্যবহার করে, তাই সার্ভারে সংশ্লিষ্ট ব্যক্তিগত কী উপলব্ধ।

আমি চাই না যে সার্ভার ব্যবহারকারীরা প্রকৃতপক্ষে কীটি পড়তে সক্ষম হন। মূলত, সার্ভারটিতে তাদের অ্যাক্সেস রয়েছে এ বিষয়টি সত্য যে তাদের এসএসএস ডান করতে দেয় এবং সার্ভার থেকে এগুলি সরিয়ে ফেলা দূরবর্তী মেশিনের সাথে সংযোগও বঞ্চিত করা উচিত।

আমি কীভাবে ব্যবহারকারীদের ব্যক্তিগত কীতে পঠন অ্যাক্সেস না দিয়ে কোনও এসএসএস সংযোগ খুলতে দিতে পারি?

আমার চিন্তাভাবনা এতক্ষণে: স্পষ্টতই ssh এক্সিকিউটেবল অবশ্যই প্রাইভেট কীটি পড়তে সক্ষম হবে, সুতরাং এটি সার্ভারে অন্য কোনও ব্যবহারকারীর অধীনে চলতে হবে যার অধিকার রয়েছে। একবার ssh সংযোগটি প্রতিষ্ঠিত হয়ে গেলে আমি এটির পরে ব্যবহারকারীর কাছে এটি "ফরোয়ার্ড" করতে পারি যাতে সে কমান্ড সন্নিবেশ করতে পারে এবং দূরবর্তী মেশিনের সাথে ইন্টারেক্ট করতে পারে।

• এই একটি ভাল পন্থা?
• আমার কীভাবে এগিয়ে নেওয়া উচিত?
• ব্যবহারকারী কীভাবে সংযোগটি শুরু করতে পারেন (যা কী দ্বারা অধিকারগুলি পড়েছে এমন ব্যবহারকারীর দ্বারা ssh এর সম্পাদন)?
• কোন সুরক্ষা ফাঁক আছে? - যদি ব্যবহারকারীরা অন্য ব্যবহারকারী হিসাবে কোনও এসএসএস কার্যকর করতে পারে, তবে তারা কি অন্য ব্যবহারকারী যা করতে পারে (ব্যক্তিগত কীটি সহ,) যা কিছু করতে পারে তা করতে পারে?

Comments

এটা তোলে সদৃশ মনে করা হয় stackoverflow.com/questions/9286622/protecting-ssh-keys

— wenzul

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

@ আন্দ্রেডানিয়েল ভালভাবেই সম্ভবত তারা অন্য একটি, সম্পূর্ণ অপ্রস্তুত কম্পিউটারে লগইন করতে পারে যা সার্ভার থেকে পাসওয়ার্ডহীন লগইন গ্রহণ করতে কনফিগার করা হয়েছে। এই কারণেই আমি এটির মতো একটি সেটআপ রাখতে ভাবতে পারি; যদি এটি না হয় তবে আমি এটি কি তা সম্পর্কে আগ্রহী। (সত্যিই এটি গুরুত্বপূর্ণ নয়))

— ডেভিড জেড

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

আপনি যদি এইভাবে এটি লক করতে চান, আমি ধরে নিই যে আপনি ব্যবহারকারীদের ~/.ssh/authorized_keysফাইলগুলিতে নতুন পাবলিক কী যুক্ত করা থেকে বঞ্চিত করার ব্যবস্থা নিয়েছেন ?

— এমপোনটিলো

Answer 1

এর অন্যতম কারণ sudoবিদ্যমান। কেবলমাত্র পূর্ব-অনুমোদিত কমান্ড-লাইন বিকল্প এবং সর্বাধিক সুস্পষ্ট পরিস্থিতি সমাধানের সাথে আপনার ব্যবহারকারীদের 1 টি একক কমান্ড চালানোর অনুমতি দিন। যেমন

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

সেট আপ করে sudoযাতে গোষ্ঠীর সমস্ত সদস্যরা usersচালানোর সময় তাদের নিজস্ব পাসওয়ার্ড (বা কিছু_উইড অ্যাকাউন্টের) প্রবেশ না করেই কিছু_উইড হিসাবে ব্যবহারকারী হিসাবে ssh কমান্ড চালাতে পারে:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

NOPASSWD:রিমোট-হোস্টে লগ ইন করার আগে ব্যবহারকারীরা তাদের নিজস্ব পাসওয়ার্ড প্রবেশ করতে বাধ্য করার বিকল্পটি সরান ।
আপনার ব্যবহারকারীদের সুবিধার্থে একটি উপাধি বা র‍্যাপার স্ক্রিপ্টটি সম্ভবত সেট আপ করুন কারণ sudoসঠিক যুক্তি ব্যবহারের বিষয়ে বেশ পছন্দসই।

Comments

একটি যাদুমন্ত্র মত কাজ করে. এটি ওয়েঞ্জুল দ্বারা উল্লিখিত সদৃশটির জন্য প্রস্তাবিত উত্তরও হওয়া উচিত।

— ফিলিপ

Answer 2

এটি হোস্ট-ভিত্তিক প্রমাণীকরণের জন্য ভাল ব্যবহারের ক্ষেত্রে বলে মনে হচ্ছে। এটি প্রমাণীকরণের একটি পদ্ধতি যেখানে এসএসএইচ স্থানীয় মেশিনে স্বতন্ত্র ব্যবহারকারীর কী ব্যবহার করে না (এই ক্ষেত্রে, আপনার সার্ভারটি) প্রমাণীকরণের জন্য; পরিবর্তে, এটি হোস্টের ব্যক্তিগত কী ব্যবহার করে, এটি সঞ্চিত /etc/ssh/এবং যা কেবল পাঠযোগ্য root।

এটি সেট আপ করার জন্য, আপনাকে .shostsব্যবহারকারীর হোম ডিরেক্টরিতে রিমোট মেশিনে নামক একটি ফাইল তৈরি করতে হবে যা আপনি লোকে হিসাবে প্রবেশ করতে চান (লগ ইন নয় ~/.ssh)। ফাইলটিতে বিষয়বস্তু থাকা উচিত

server-hostname +

server-hostnameআপনার সার্ভারের নাম কোথায় এবং +এটি একটি আক্ষরিক প্লাস চিহ্ন যা "যে কোনও ব্যবহারকারী" এর অর্থ ওয়াইল্ডকার্ড হিসাবে কাজ করে।

আপনাকে এটিও নিশ্চিত করতে হবে যে দূরবর্তী মেশিনটি সার্ভারের হোস্ট কীটি যাচাই করতে পারে, যার অর্থ সার্ভারের হোস্ট কীটি হয় /etc/ssh/ssh_known_hostsবা ~/.ssh/known_hostsদূরবর্তী মেশিনে তালিকাভুক্ত হওয়া দরকার । যদি ইতিমধ্যে এটি না হয় তবে আপনি রিমোট মেশিনে লগ ইন করে এটি চালিয়ে যেতে পারেন

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

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

আপনি কিছু ব্যবহারকারীকে দূরবর্তী মেশিনে অ্যাক্সেসের অনুমতি দেওয়া বা অস্বীকার করার মতো জিনিসগুলি সহজেই করতে পারেন। ম্যান পৃষ্ঠাগুলি sshএবং hosts.equivবিশদ জন্য দেখুন।

এই সেটআপটির সাথে একটি সমস্যা হ'ল যে ব্যবহারকারীরা দূরবর্তী মেশিনে লগইন করেন তারা পরিবর্তন করতে পারেন .shosts। তারা কিছুই করতে পারে না যা এটির মাধ্যমে তারা অন্য ব্যবহারকারী হিসাবে দূরবর্তী মেশিনে লগইন করতে পারে, তবে তারা তাদের নিজস্ব বা অন্যের দূরবর্তী মেশিনে প্রবেশ বন্ধ করে দিতে পারে। যদি এটি উদ্বেগের বিষয় হয় তবে আপনি .shostsকেবল rootবা কোনও কিছু দ্বারা লিখিতভাবে সক্ষম করতে সক্ষম হবেন - এটি কাজ করে কিনা তা সম্পর্কে আমি নিশ্চিত নই, তবে আপনি এটি চেষ্টা করে দেখতে পারেন। (অন্যান্য পদ্ধতির মতো পদ্ধতিগুলিও sudoএকই ঝুঁকির পক্ষে সংবেদনশীল, যেহেতু কোনও ব্যবহারকারী সর্বদা মুছতে পারে ~/.ssh/authorized_keys))

Comments

+1 টি; আমি মনে করি যে এই বিকল্পটি টার্মিনাল ব্যতীত এসএসএইচ বৈশিষ্ট্য যেমন পোর্ট ফরওয়ার্ডিং, সুরক্ষিত অনুলিপি ইত্যাদির ব্যবহার প্রয়োজন, এমনকি বিকল্প এসএসএইচ ক্লায়েন্টেরও কাজ করা উচিত। sudoবিকল্প যদিও একটি লক-ডাউন পরিবেশের জন্য ভালো হতে পারে, ...

— mpontillo