লিনাক্স বাক্সে কোনও ব্যবহারকারীকে কনফিগার করার কোনও উপায় আছে (এই ক্ষেত্রে সেন্টোস ৫.২) যাতে তারা ফাইলগুলি পুনরুদ্ধার করতে স্ক্রিপ ব্যবহার করতে পারে তবে এসএসএইচ ব্যবহার করে সার্ভারে লগইন করতে না পারে?
লিনাক্স বাক্সে কোনও ব্যবহারকারীকে কনফিগার করার কোনও উপায় আছে (এই ক্ষেত্রে সেন্টোস ৫.২) যাতে তারা ফাইলগুলি পুনরুদ্ধার করতে স্ক্রিপ ব্যবহার করতে পারে তবে এসএসএইচ ব্যবহার করে সার্ভারে লগইন করতে না পারে?
উত্তর:
আরএসএস শেল ( http://pizzashack.org/rssh/ ) সুনির্দিষ্টভাবে এই উদ্দেশ্যে ডিজাইন করা হয়েছে।
যেহেতু আরএইচইএল / সেন্টোস 5.2 তে আরএসএসের জন্য কোনও প্যাকেজ অন্তর্ভুক্ত নেই, আপনি এখানে আরপিএম পেতে এখানে দেখতে পারেন: http://dag.wieers.com/rpm/packages/rssh/
এটি ব্যবহারের জন্য কেবল এটির মতো নতুন ব্যবহারকারীর শেল হিসাবে সেট করুন:
useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1
.. বা এটির মতো বিদ্যমান একটির জন্য শেল পরিবর্তন করুন:
chsh -s /usr/bin/rssh scpuser1
..আর /etc/rssh.conf
আরএসএস শেল কনফিগার করতে সম্পাদনা করুন - বিশেষত allowscp
সমস্ত আরএসএস ব্যবহারকারীদের এসসিপি অ্যাক্সেস সক্ষম করতে অসাধারণ লাইন।
(আপনি ব্যবহারকারীদের বাড়িতে রাখার জন্য ক্রুট ব্যবহার করতেও পারেন তবে এটি অন্য গল্প)
আমি এটির জন্য দেরি করে চলেছি তবে আপনি ssh কী ব্যবহার করতে পারেন এবং তাদের ~ / .ssh / अधिकृत_keys ফাইল যেমন অনুমোদিত কমান্ড নির্দিষ্ট করতে পারেন
নো-পোর্ট-ফরওয়ার্ডিং, ন-পিটিআই, কমান্ড = "এসপিপি উত্স লক্ষ্য" এসএসএস-ডিএসএস ...
ডান কমান্ড সেটিংস সেট করতে আপনার টার্গেটে পিএস ব্যবহার করতে হবে।
পিএস: আপনি যদি "-v" দিয়ে একটি টেস্ট স্কিপ কমান্ড চালান তবে আপনি এরকম কিছু দেখতে পাচ্ছেন
debug1: Sending command: scp -v -t myfile.txt
আপনি খেয়াল করবেন যে "-t" হ'ল একটি অননুমোদিত স্ক্রিপ অপশন, যা প্রান্তটির শেষে প্রোগ্রাম দ্বারা ব্যবহৃত হয়। এটি আপনাকে অনুমোদিত_পোক্রে কী কী লাগাতে হবে তার ধারণা দেয়।
সম্পাদনা: আপনি এই স্ট্যাকওভারফ্লো প্রশ্নটিতে আরও তথ্য (বেশ কয়েকটি লিঙ্ক সহ) পেতে পারেন ।
backup_user
সার্ভার সাইডে নামের একজন ব্যবহারকারীর জন্য এটির কার্যকারী উদাহরণ এখানে ।
~backup_user/.ssh/authorized_keys
সার্ভারের পক্ষের সামগ্রী (আরও কিছু সুরক্ষা বিধিনিষেধ সহ):
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...
ডিরেক্টরিতে লিঙ্কযুক্ত ~ ব্যাকআপ_উজার / এ একটি লিঙ্ক তৈরি করুন যেখানে সামগ্রীটি অ্যাক্সেসযোগ্য হবে।
$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT
এখন, ক্লায়েন্ট পক্ষ থেকে, নিম্নলিখিত কমান্ডটি কাজ করা উচিত:
scp -v -r -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT
এই আদেশটি কি করে:
-v
কমান্ড এবং অনুমোদিত_কাইজ ফাইল উভয় থেকে মুছে ফেলতে পারেন )-r
পুনরাবৃত্তি অনুলিপি তৈরি করতে না চাইলে আপনি আদেশ ও অনুমোদিত_জোকি উভয় ফাইল থেকে সরিয়ে নিতে পারেন)-P 2222
আদেশটি সরিয়ে ফেলতে পারেন )-i .ssh/id_rsa_key_file
path/to/data
অনুলিপি করা হবে/path/to/directory/with/accessible/content/
সার্ভার থেকে ক্লায়েন্টের কাছে কোনও ফাইলের (বা বেশ কয়েকটি) একটি অনুলিপি তৈরি করতে আপনার এখানে একটি শেল স্ক্রিপ্ট তৈরি করা উচিত যা এখানে বর্ণিত হিসাবে এটি পরিচালনা করে
chmod 400 ~/.ssh/authorized_keys
।
~/.bashrc
(এবং যা কিছু বাশ চালায়) এবং ~/.ssh/rc
কেবল পঠনযোগ্য। তবে যদি দূষিত ব্যবহারকারীর আরএসসিএনএইচ বা এসএফপি অ্যাক্সেস থাকে তবে সে এখনও মুছে ফেলতে ~/.bashrc
এবং একটি নতুন আপলোড করতে পারে। যেহেতু এটি রক্ষা করা শক্ত, তাই আমি এই পদ্ধতির বিরুদ্ধে প্রস্তাব দিই ( command="..."
)।
আমি পার্টিতে কিছুটা দেরি করছি, তবে আমি আপনাকে ForceCommand
ওপেনএসএইচ- র নির্দেশের দিকে নজর দেওয়ার পরামর্শ দেব ।
Subsystem sftp internal-sftp
Match group sftponly
ForceCommand internal-sftp
মঞ্জুর, এটি এসএফটিপি এবং এসসিপি নয়, তবে এটি একই লক্ষ্যতে পৌঁছেছে, একটি সীমাবদ্ধ শেলের চেয়ে বেশি সুরক্ষিত। এছাড়াও, আপনি চাইলে ব্যবহারকারীকে ক্রুট করতে পারেন।
chrootDirectory %h
এবং এর AllowTcpForwarding no
পরে যুক্ত করুন । দয়া করে নোট করুন যে ম্যাচটি (অবশ্যই!)
ForceCommand internal-sftp -u 0077 -d /uploaddir
এটি আপলোড ডিরেক্টরিতে উমাস্ককে জোর করে আরও শক্ত করতে পারে। 'ক্রুটডাইরেক্টরি'-এর সাথে একত্রে এটি একটি খুব নিয়ন্ত্রিত, বিচ্ছিন্ন আপলোড পরিবেশ তৈরি করে। বোনাস নোট: আপনি যদি তাদের কাজ করতে চান তবে ডিফল্ট দির এবং উমাস্ক অবশ্যই নির্দেশিকায় ForceCommand
নয়, সেট করা উচিতSubsystem
।
আমি scponly ব্যবহার করার পরামর্শ দিচ্ছি।
এটি একটি সীমাবদ্ধ শেল যা ব্যবহারকারীদের সার্ভারে এসসিপি ফাইলগুলি যেমন মনে হয় ঠিক তেমন করতে দেয় তবে আসলে লগ ইন করে না the সফ্টওয়্যারটির জন্য তথ্য এবং উত্স কোড ডাউনলোডগুলি এখানে উপলব্ধ এবং প্রাক-সংকলিত আরপিএম প্যাকেজগুলির মাধ্যমে উপলব্ধ EPEL YUM সংগ্রহস্থল ।
একবার ইনস্টল হয়ে গেলে, নতুন ইনস্টল হওয়া সীমাবদ্ধ শেলটি ব্যবহার করার জন্য আপনাকে প্রতিটি ব্যবহারকারীর অ্যাকাউন্ট কনফিগার করতে হবে যা আপনি অ্যাক্সেসকে সীমাবদ্ধ রাখতে চান। আপনি নিজে থেকে এটি / etc / passwd এর মাধ্যমে করতে পারেন বা নিম্নলিখিত কমান্ডটি ব্যবহার করতে পারেন: usermod -s /usr/bin/scponly USERNAME
scponly
ঠিক এই উদ্দেশ্যে ডিজাইন করা হয়।
এটি করার জন্য আমি মাইসিকিউরশেল ব্যবহার করি। আপনি অন্যান্য বিধিনিষেধগুলিও কনফিগার করতে পারেন।
https://github.com/mysecureshell/mysecureshell
কেবল এসএফটিপি / এসসিপি-তে সংযোগ সীমাবদ্ধ করে। শেল অ্যাক্সেস নেই।
পার্টিতে খুব দেরী হয়েছে, তবে গিট ব্যবহারকারীর শেলটি / usr / bin / git- শেল হিসাবে সেট করুন। এটি একটি সীমিত শেল যা ইন্টারেক্টিভ লগইনকে অনুমতি দেয় না। আপনি এখনও 'su -s / bin / bash git' বা আপনার গিট ব্যবহারকারীর নাম যা ব্যবহারকারীর সাথে সাইন ইন করতে পারেন।
আমি একটি দুর্দান্ত উপায় খুঁজে পেয়েছি হ'ল অনুমোদিত_কিজ ফাইলটির কমান্ড = "..." ব্যবহার করা। ( এই পৃষ্ঠায় আমার কাছে প্রস্তাবিত )
আপনি যে কমান্ডটি চালাতে চান তা হ'ল scp (এবং rsync) দিয়ে শুরু হওয়া যুক্তিগুলির জন্য পরীক্ষা করে।
অনুমোদিত_কিজ ফাইলটি এখানে:
# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew
রিমোট- সিএমডি.শ এর সামগ্রীগুলি এখানে:
#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
'scp'*)
$SSH_ORIGINAL_COMMAND
;;
'rsync'*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Access Denied"
;;
esac
আমি মনে করি আপনার সম্ভবত ব্যবহারকারীর অনুমোদিত_কিজি ফাইলটি রক্ষা করতে হবে তবে আমার উদ্দেশ্যটি ছিল একটি সম্পূর্ণ পাসওয়ার্ড-কম কীটি আমি ব্যাকআপের জন্য ব্যবহার করতে পারি, সম্পূর্ণ নতুন ব্যবহারকারী তৈরি না করে এবং কীটি শেলটি না দিয়ে থাকে (ঠিক আছে, সহজেই)
~/.ssh/authorized_keys
, ~/.bashrc
(এবং বাশ যে কোনও কিছুই কার্যকর করে) এবং ~/.ssh/rc
ব্যবহারকারীর জন্য কেবল পঠনযোগ্য। তবে যদি দূষিত ব্যবহারকারীর আরএসসিএনএইচ বা এসএফপি অ্যাক্সেস থাকে তবে সে এখনও মুছে ফেলতে ~/.bashrc
এবং একটি নতুন আপলোড করতে পারে। যেহেতু এটি রক্ষা করা শক্ত, তাই আমি এই পদ্ধতির বিরুদ্ধে প্রস্তাব দিই ( command="..."
)।
ব্যবহারকারীর লগইন শেলটিকে কোনও বিধিনিষেধযুক্ত এমন কিছুতে পরিবর্তন করুন, যা ব্যবহারকারীকে কেবলমাত্র scp , sftp-server এবং rsync চালাতে দেয় এবং এটি অনিরাপদ যুক্তিও অনুমোদিত নয় (যেমন scp -S ... এবং rsync -e ..) । অনিরাপদ, এখানে দেখুন: http://exploit-db.com/exploits/24795 )। যেমন সীমাবদ্ধ লগইন শেল জন্য উদাহরণ:
আপনি এর মধ্যে একটি ক্রুট বা অন্য একটি নিষিদ্ধ পরিবেশে (যেমন লিনাক্সে এনজেল ) চালাতে চাইতে পারেন, নেটওয়ার্ক অ্যাক্সেস অক্ষম করতে এবং কোন ডিরেক্টরিগুলি পড়তে এবং / অথবা লিখিত হতে পারে তার সহজতর (শ্বেত তালিকাভুক্ত ) নিয়ন্ত্রণের জন্য।
আমি ব্যবহার সুপারিশ না command="..."
মধ্যে ~/.ssh/authorized_keys
, (যেমন সাবধান অতিরিক্ত সুরক্ষা ছাড়া কারণ chmod -R u-w ~
ব্যবহারকারীর জন্য) একটি দূষিত ব্যবহারকারী এর একটি নতুন সংস্করণ আপলোড করতে পারেন ~/.ssh/authorized_keys
, ~/.ssh/rc
বা ~/.bashrc
, এবং এইভাবে অন্তর্ভুক্ত করা এবং অবাধ কমান্ড নির্বাহ করতে পারেন।
এটি সবচেয়ে কৃপণ সমাধান নয়, তবে আপনি ব্যবহারকারীদের মধ্যে এই জাতীয় কিছু ফেলে দিতে পারেন ash
if [ "$TERM" != "dumb" ]; then
exit
fi
আমি খুঁজে পেয়েছি যে এসসিপি ব্যবহারকারীরা 'বোবা' এর একটি TERM পান এবং অন্যরা সাধারণত ভিটি 100 পাবেন।
আমি কল্পনা করেছি যে ব্যবহারকারী সম্ভবত একটি নতুন .Bashrc- কে স্ক্র্যাপ করতে পারে যা এটি সেরা সমাধান হিসাবে নয়, তবে দ্রুত এবং নোংরা সমাধানের জন্য এটি কাজ করবে
~/.bashrc
)। এটি এই অর্থেও তাত্পর্যপূর্ণ যে ওপেনএসএসএইচের নতুন সংস্করণগুলি TERM
ভেরিয়েবলটিকে আলাদাভাবে সেট করবে , বা কিছু এসএসডি কনফিগার সেটিংস প্রভাবিত করতে পারে TERM
।
ssh -o SetEnv TERM=dumb yourserver bash
??