Sshd "UseDNS" বিকল্পটি কী?

Question

আমি জানি এটি কী করে, তবে কেন জানি না । কোন আক্রমণ (গুলি) এটি প্রতিরোধ করে?

এটি কি সমস্ত ধরণের প্রমাণীকরণ পদ্ধতির জন্য প্রাসঙ্গিক? (হোস্টবেসড, পাসওয়ার্ড, পাবলিককি, কীবোর্ড-ইন্টারেক্টিভ ...)

Comments

আমি এখানেও কোরিওজে যোগ করেছি: github.com/coreos/bugs/issues/92

Answer 1

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

সাধারণ কনফিগারেশনে, ডিএনএস কেবল লগিংয়ের জন্য ব্যবহৃত হয়। এটি প্রমাণীকরণের জন্য ব্যবহার করা যেতে পারে, তবে কেবলমাত্র যদি IgnoreRhosts noনির্দিষ্ট করা থাকে sshd_config। এই পুরানো ইনস্টল করে rsh, তুমি কোথায় বলতে পারেন "ব্যবহারকারীর নামক ব্যবহৃত উপযুক্ততার জন্য bobমেশিন নামক darkstarহিসাবে লগ ইন করতে পারেন aliceকোনো পরিচয়পত্র দেখিয়ে" (লিখে darkstar bobমধ্যে ~alice/.rhosts)। এটি কেবলমাত্র নিরাপদ যদি আপনি সমস্ত মেশিনকে বিশ্বাস করেন যে সম্ভবত ssh সার্ভারের সাথে সংযুক্ত হতে পারে। অন্য কথায়, এটি নিরাপদ উপায়ে খুব কমই ব্যবহারযোগ্য।

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

এই বৈশিষ্ট্যটি বন্ধ করার জন্য আর একটি যুক্তি হ'ল প্রতিটি অতিরিক্ত অতিরিক্ত বৈশিষ্ট্য হ'ল একটি অপ্রয়োজনীয় সুরক্ষা ঝুঁকি ।

Comments

সুতরাং, UseDNS কেবল হোস্টবেসড প্রমাণীকরণের জন্যই প্রাসঙ্গিক? আমি যদি হোস্টবেসড লেখক ব্যবহার না করি এবং হোস্টনেম বা আইপি লগগুলিতে প্রদর্শিত হয় সে বিষয়ে আমার যত্ন নেই, UseDNS এর কোনও তফাত নেই?

— user368507

@ ব্যবহারকারী368507 হ্যাঁ, এটিই। UseDNSএমনকি যদি আপনি কী-ভিত্তিক হোস্ট প্রমাণীকরণ ব্যবহার করেন তবে তা কার্যকর নয় , কেবলমাত্র যদি আপনি হোস্টনাম-ভিত্তিক হোস্ট প্রমাণীকরণ (যেমন অত্যন্ত দুর্বল প্রমাণীকরণ) ব্যবহার করেন।

— গিলস

@ গিলস অবশ্যই, যদি আপনি কী-ভিত্তিক এবং হোস্টনাম-ভিত্তিক প্রমাণীকরণ ব্যবহার করেন তবে UseDNSএটি খুব দরকারী এবং সমালোচনামূলক। আপনি কী এবং ভিত্তি করে একটি ম্যাক ঠিকানায় নির্ধারিত হোস্টনামের উপর ভিত্তি করে একটি ব্যবহারকারীর প্রমাণীকরণ করেন।

— কারা ডানিজ

Answer 2

আমি এই সম্পর্কে উবুন্টুতে একটি বাগ রিপোর্টে (পুরানো তবে এখনও স্রোত) যুক্ত করেছি।

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/424371

আমি ডিফল্টটিকে No এ পরিবর্তন করার এবং এটিতে আরও নতুন ডকুমেন্টেশন যুক্ত করার প্রস্তাব দিয়েছি:

# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses.
# Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged.

Comments

আপ আপ আপ ... এটি আরও কার্যকর, কারণ এটিতে আমি খুঁজছিলাম এমন একটি তথ্য রয়েছে।

— 0xC0000022L

একইভাবে যদি UseDNS না হয় তবে পাম_একসেস বিধিগুলিতে হোস্টের নামগুলি মেলানো যাবে না এবং পরিবর্তে আইপি অবশ্যই ব্যবহার করা উচিত।

— কলিনম

আমি এই উত্তরটি কয়েক বছর আগে উন্নীত করেছিলাম তবে কেবল আজই আমি লক্ষ্য করেছি যে, ওপেনএসএসএইচ 6.8p1 এ ডিফল্টটি "ইউজডিএনএস নং" তে পরিবর্তন করা হয়েছিল, যা উবুন্টু 15.10 এবং পরে রয়েছে ।

— অ্যান্টনি জিওগেইগান 21

রেডহ্যাট (আরএইচইএল 7 তে) সম্প্রতি ডিফল্টটিকে নো-তেও বদলেছে, যা হোস্ট-নেম-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণগুলি ভেঙে দেয় (যা কেবলমাত্র একমাত্র অ্যাক্সেস নিয়ন্ত্রণ ব্যবস্থা হিসাবে নয়, একটি ইন্ট্রানেটে বেশিরভাগ পরামর্শমূলক নিয়ন্ত্রণ হিসাবে কার্যকর)।

— ড্যানিসাউয়ার

Answer 3

এর ম্যানপেজ থেকে sshd_config(5):

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

এটিকে সক্ষম করা সঠিক (ফরোয়ার্ড এবং বিপরীত) ছাড়াই কোনও অবস্থান থেকে অ্যাক্সেস তৈরি করে লগগুলিতে একটি সতর্কতা উত্পন্ন করে।

সুতরাং এটি কোনও আক্রমণকে আটকায় না except এই ধরনের সতর্কতা আপনাকে কেবল আক্রমণকারীর সন্ধানে সহায়তা করতে পারে যদি সেই পিটিআর রেকর্ডটি কোনও অর্থ দেয়।

^{সম্পাদনা: অ্যান্ড্রে ভয়েটেনকভের মন্তব্য অনুসারে আপডেট হয়েছে ।}

Comments

সুতরাং এটি ডিএনএস সার্ভারে যা আছে তার ভিত্তিতে কাকে সংযোগ করার অনুমতি দেওয়া হচ্ছে তার একটি ফিল্টার?

— user368507

কেন এটি অ্যাক্সেসকে অসম্ভব করে তুলবে? ডিএনএস এ / পিটিআর রেকর্ড মেলে না তবে sshd কেবল সতর্কতা উত্পন্ন করে। সমস্যা সমাধানের ক্ষেত্রে লগন ক্রমটি ধীর হবে।

— আন্দ্রে ভয়েটেনকভ

আক্রমণকারী from=যদি প্রশ্নে অনুমোদিত চাবি (যদি ব্যবহৃত হয়) এর আগে ক্ষেত্রের মানগুলিকে ফাঁকি না দিতে পারে ততক্ষণ অনুমোদিত কীটি আপস করা থাকলে এটি অ্যাক্সেস আটকাতে পারে না ।

— আলেকজ

Answer 4

আপনি যখন কোনও অনুমোদিত_কিজ ফাইলগুলিতে এফআরএম বিকল্পটি ব্যবহার করেন তখন এটি প্রয়োজন হয় এবং আপনি কেবল আইপি নয়, নাম দিয়ে ফিল্টার করতে চান।

কোনও অনুমোদিত_কিজ ফাইলের একটি লাইনে FROM বিকল্প আপনাকে একটি নির্দিষ্ট কী ব্যবহার করতে পারে এমন হোস্টগুলিকে সীমাবদ্ধ করতে দেয়।
এটি সাধারণত কোনও মেশিনের ক্লোনকে তার উত্সটি তৈরি করে, সাধারণত অজান্তেই (বাকী ক্রন্টাবগুলি, মানুষের ত্রুটি) তৈরি করে একে অপরের অ্যাক্সেস করে এমন একাধিক সার্ভার পরিচালনার দক্ষতা বৃদ্ধি করে।

Answer 5

আমি যে যোগ করার জন্য সেন্টওএস 7 (7.1.1503) এবং অত: পর রেড হ্যাট Enterprise Linux 7 চাই, আমার বয়স অক্ষম ডিফল্ট সেটিং দিয়ে লগ ইন yesজন্য UseDNS। এটিকে নিরবিচ্ছিন্ন করার পরে এবং সেট করার পরে no, আমি লগ ইন করতে সক্ষম হয়েছি Thus সুতরাং এটি প্রদর্শিত হয় যে ডিএনএস সঠিকভাবে কাজ না করা থাকলে একটি সত্যিই পরিষেবা অস্বীকার করা যেতে পারে! CentOS 6 এ, এটি ডিফল্ট হিসাবে উপস্থিত হয় noএবং তাই sshকোনও ডিএনএসের সাথে আমি কাজ করতে পারি না !

আমি যুক্ত করতে চাই যে আমার পরীক্ষাটি এলএক্সসি পাত্রে ছিল, শারীরিক মেশিনে নয়, যদি কোনও পার্থক্য আসে!