ইউনিক্সের ক্ষেত্রে ব্যবহারকারীর নামটি কি সংবেদনশীল?


20

এর ssh abc@servernameথেকে আলাদা কি ssh Abc@servername? ইউনিক্সের ক্ষেত্রে ইউনিক্সের বিষয়টি কি গুরুত্বপূর্ণ?

আমার ব্যবহারকারী LDAP এর মাধ্যমে প্রমাণীকরণ করে।


3
লিনাক্সের প্রায় সব কিছুই কেস-সংবেদনশীল। অর্থ: এর cdমতো নয় CD... তাদের সত্যিকারের অর্থ বোঝানোর একমাত্র উপায় হ'ল আপনার .bashrcফাইলে এলিয়াস সেট করা ..
ryekayo

1
আমি মনে করি এটি আপনার ব্যবহারকারীর নামটির জন্য কী LDAP বৈশিষ্ট্যটি ব্যবহার করে তার উপর নির্ভর করে। যদি এটি আরএফসি 4519 থেকে গৃহীত হয় , তবে এটি ক্ষেত্রে সংবেদনশীল না থাকলেও প্রমাণীকরণের বাস্তবায়নগুলি এরপরেও মামলার তাত্পর্য আরোপ করতে পারে। এটি LDAP দিয়ে কীভাবে প্রমাণীকরণ করা হয় তার উপরও নির্ভর করে।
স্টাফেন চেজেলাস

1
কেবল আপনার ইউজারনেমকে মূলধন দিয়ে লগইন করার চেষ্টা করা মাত্র কয়েক সেকেন্ডের মধ্যে এটির উত্তর জানাত।
মনিকার সাথে লাইটনেস রেস

উত্তর:


14

হোস্ট-নেম এবং ডোমেন নামের মতো, ব্যবহারকারীর নামটি কঠোরভাবে কোনও ইউনিক্স জিনিস নয় তবে প্রায়শই ওএস প্রকারের বিস্তৃত পরিসীমা বিস্তৃত করতে পারে।

সেগুলি কেস সংবেদনশীল হিসাবে বিবেচনা করা হবে কিনা তা তাদের নির্দিষ্ট করার জন্য ব্যবহৃত মানের উপর নির্ভর করে।

হোস্টনাম এবং ডোমেনের নামগুলি DNS স্ট্যান্ডার্ডের দ্বারা স্পষ্টভাবে সংবেদনশীল নয় (দেখুন RFC4343 )।

একটি স্থানীয় ব্যাকএন্ড (/ etc / passwd) অথবা একটি ইউনিক্স শৈলী এক (NIS) সঞ্চিত ব্যবহারকারীর নাম দ্বারা কেস অবশ নয় POSIX মান

একটি এলডিএপি বা একটি অ্যাক্টিভ ডিরেক্টরি ব্যাকএন্ডে সঞ্চিত ব্যবহারকারীর নামগুলি ব্যবহৃত বৈশিষ্ট্য স্কিমা সংজ্ঞাটি অনুসরণ করবে uidএবং cnসাধারণত ব্যবহারকারী নামটি পৃথক করে স্কিমার বৈশিষ্ট্য ধারণ করে, পূর্বের ক্ষেত্রে সংবেদনশীল তবে পরবর্তী ক্ষেত্রে সংবেদনশীল। এর অর্থ উভয়ই Abcএবং ldap সার্ভারের কনফিগারেশনের উপর নির্ভর করে এর প্রবেশ abcমেলে বা নাও পারে abc

এই অসামঞ্জস্যতার কারণে, আমি কেবলমাত্র উভয় ব্যবহারকারীর নাম এবং হোস্ট / ডোমেন নামের জন্য ছোট হাতের ব্যবহার করার পরামর্শ দেব এবং তারপরে ssh ABC@SERVERNAME.DOMAIN.COMযা কোনওভাবে অভদ্রতা এড়ানো উচিত ।


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

1
@DougR। পসিক্সের সাথে সম্পর্কিত হিসাবে, ব্যবহারকারীর নামগুলি ক্ষেত্রে নির্ভরশীল। কেস সংবেদনশীলতা অন্যথায় নির্দিষ্ট করা হত। পোর্টেবল ফাইলনাম অক্ষর সেটকে উল্লেখ করার ক্ষেত্রে কেস সংবেদনশীলতা অন্তর্ভুক্ত।
jlliagre

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

5

হ্যাঁ এটি কেস সেনসিটিভ। আমি প্রযুক্তিগত তথ্য আনতে সক্ষম নই, আমি কেবল এটি পরীক্ষা করেছি এবং ভাবছি কেন আপনি (?) করেন নি

আমার লোকাল মেশিনটি লিনাক্স পুদিনা যেমন আপনি দেখতে পাচ্ছেন:

# cat /etc/*release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.2
DISTRIB_CODENAME=rafaela
DISTRIB_DESCRIPTION="Linux Mint 17.2 Rafaela"
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
cat: /etc/upstream-release: Is a directory

এবং আমি CentOS সার্ভারের সাথে এটির সাথে সংযোগ দেওয়ার চেষ্টা করেছি:

((ভুল) বড় হাতের ব্যবহারকারীর নাম ব্যবহার করে:

8D prova # ssh Root@agora-server
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password: 

Correct সঠিক ব্যবহারকারীর নাম ব্যবহার করে:

8D prova # ssh root@agora-server
root@agora-server's password: 
Last login: Fri Oct  2 01:50:13 2015 from 192.168.0.31
[root@agora-server ~]# 

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

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

3

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

আপনার কী চেষ্টা করা উচিত / তা হ'ল আপনার সিস্টেমটি জারি করে LDAP সঠিকভাবে ব্যবহার করছে কিনা তা getent passwd <username>। এই কমান্ডটি ব্যবহার করা আপনাকে নির্দিষ্ট ব্যবহারকারীর জন্য ব্যবহারকারীর নাম, হোম ডিরেক্টরি এবং শেল সহ একটি রেকর্ড দেবে। আপনি যদি এই জাতীয় রেকর্ড না দেখে থাকেন তবে এলডিএপ সঠিকভাবে কনফিগার করা হয়নি।

বেশ কয়েকটি জায়গা যেখানে আপনার এলডিএপি কনফিগার করা উচিত এবং সেই জায়গাগুলির মধ্যে একটি হ'ল:

/etc/nsswitch.conf

passwd: files ldap
group:  files ldap

আপনাকে পিএএম সঠিকভাবে কনফিগার করা হয়েছে কিনা তাও পরীক্ষা করে দেখতে হবে এবং সম্ভবত সবচেয়ে গুরুত্বপূর্ণ পদক্ষেপটি LDAP ক্লায়েন্টটি কনফিগার করা এবং কাজ করছে কিনা তা যাচাই করা। ldapsearchএলডিএপি জিজ্ঞাসা করা যায় কিনা তা পরীক্ষা করার মতো একটি সরঞ্জাম চেষ্টা করে দেখুন ।

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


1

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

কয়েকটি উদাহরণ হ'ল:

এটি ব্যবহারকারীর জন্য ইমেল ভঙ্গ করতে পারে। এসএমটিপি-র মানদণ্ডগুলি ইমেল ঠিকানাগুলিকে কেস-সংবেদনশীল হতে দেয় এবং ডিফল্টরূপে বার্তা প্রাপ্ত এমটিএ ব্যবহারকারীর কাছে পৌঁছে দেওয়ার জন্য এটি ইমেল ঠিকানাটি লোয়ারকেসে ফোল্ড করে দেয়। যদি ব্যবহারকারীর নামটিতে বড় হাতের অক্ষর থাকে তবে এটি পূরণের জন্য বিশেষ কনফিগারেশন ওভাররাইড ছাড়া সমাধান করা হবে না। (এটি এমটিএগুলিকে যেমন প্রেরণমেল, পোস্টফিক্স ইত্যাদি এবং প্রসবমিলের মতো বিতরণ প্রক্রিয়াকরণ এজেন্টকে প্রভাবিত করে)

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

যেহেতু এটি দীর্ঘকাল ধরে ব্যবহারকারীর নামগুলিতে কেবল ছোট হাতের অক্ষরগুলি ব্যবহার করার কনভেনশন হয়েছে, তাই এটি আশা করা যুক্তিসঙ্গত যে সিস্টেমে অন্যান্য সরঞ্জামগুলি (আমরা হয়ত কিছু ভাবিনি) এমনও ধরে নিতে পারে যে ব্যবহারকারীর নামটি ছোট হাতের করা উচিত এবং চেক, রূপান্তরকরণ ইত্যাদি তৈরি করা উচিত etc তদনুসারে, এইভাবে ব্যবহারকারীর জন্য জিনিসগুলি ভঙ্গ করা।


0

ব্যবহারকারীর নামগুলি অবশ্যই সংবেদনশীল। অনুরূপ নামের দুটি ব্যবহারকারী যুক্ত করে আপনি এটি সহজে পরীক্ষা করতে পারেন:

~ # useradd foobar
~ # useradd fooBar
~ # grep ^foo /etc/passwd
foobar:x:1001:1001::/home/foobar:/bin/sh
fooBar:x:1002:1002::/home/fooBar:/bin/sh

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.