آموزش ویرایش امن فایل Sudoers

کیانا5 روز پیش

0 14 خواندن این مطلب 27 دقیقه زمان میبرد

مقدمه

ویرایش فایل /etc/sudoers کاری حیاتی است که مستقیماً بر امنیت سیستم و مدیریت دسترسی کاربران تأثیر می‌گذارد. تغییرات اشتباه می‌تواند شما را از دسترسی مدیریتی محروم کند یا آسیب‌پذیری‌های امنیتی ایجاد کند. تنها روش امن و توصیه‌شده برای ویرایش این فایل، استفاده از دستور visudo است که سینتکس را قبل از اعمال تغییرات اعتبارسنجی می‌کند تا از خطا جلوگیری شود.

در این مقاله یاد می‌گیرید چگونه فایل sudoers را با استفاده از visudo به‌طور امن اعتبارسنجی و تغییر دهید، دسترسی sudo را به‌شکل امن به کاربران بدهید، مشکلات رایج مرتبط با پیکربندی sudo را عیب‌یابی کنید و بهترین روش‌ها را برای حفظ یکپارچگی سیستم رعایت کنید. این راهنما بر دانش پایه‌ای مانند راه‌اندازی اولیه سرور بنا شده و مکمل آموزش‌های ساخت کاربران دارای دسترسی sudo است تا دسترسی‌ها را مؤثر و امن مدیریت کنید.

نکات کلیدی

همیشه برای ویرایش /etc/sudoers یا فایل‌های زیر /etc/sudoers.d/ از visudo استفاده کنید. این دستور فایل را قفل می‌کند و هنگام ذخیره، سینتکس را اعتبارسنجی می‌کند تا از قفل شدن (Lockout) جلوگیری شود.
قبل و بعد از تغییرات با sudo visudo -c اعتبارسنجی کنید، سپس به‌صورت عملی با sudo -k && sudo -v && sudo -l و یک دستور محدوده‌شده (مثلاً sudo /usr/bin/systemctl reload nginx) تست بگیرید.
مدیریت مبتنی بر گروه را به قوانین ALL به ازای هر کاربر ترجیح دهید (اوبونتو/دبیان: گروه sudo؛ RHEL/CentOS/Fedora: گروه wheel) تا ممیزی و لغو دسترسی‌ها ساده‌تر شود.
سیاست را ماژولار نگه دارید: از فایل‌های جداگانه با نام‌گذاری شفاف زیر /etc/sudoers.d/ استفاده کنید و آن‌ها را با visudo -f ویرایش کنید. فایل‌های ماژولار راحت‌تر بررسی، بازگردانی و بسته‌بندی می‌شوند.
اصل حداقل دسترسی را الزامی کنید: از مسیرهای مطلق و محدوده‌های محدود استفاده کنید و NOPASSWD: را فقط برای دستورات کم‌ریسک و خوش‌تعریف به کار ببرید. از وایلدکارت‌ها و ALLهای گسترده بپرهیزید.
امن‌سازی و مشاهده: لاگینگ sudo را فعال کنید (و در صورت تمایل، لاگ ورودی/خروجی)، مقدار secure_path را تنظیم کنید و به‌طور روتین لاگ‌ها را مرور کنید (/var/log/auth.log یا /var/log/secure).
برنامه بازیابی داشته باشید: اگر sudo خراب شد، ابتدا pkexec visudo را امتحان کنید؛ در غیر این صورت از حالت تک‌کاربره/اضطراری استفاده کنید، مسیر / را با دسترسی خواندن-نوشتن مونت کنید و با visudo تعمیر کنید.
تفاوت‌های توزیع‌ها را در نظر بگیرید: مسیرهایی مثل systemctl را با command -v تأیید کنید و قوانین را مطابق آن تنظیم کنید (مثلاً /usr/bin/systemctl در مقابل /bin/systemctl).
(اختیاری) یکپارچه‌سازی امن AI با Shell MCP Server: آن را با یک کاربر اختصاصی غیر root اجرا کنید و فقط دستورات فقط-خواندنی/کم‌ریسک و ممیزی‌شده را از طریق یک فهرست سفید (Allowlist) مینیمال در sudoers مجاز کنید.

پیش‌نیازها

قبل از شروع، از موارد زیر اطمینان حاصل کنید:

سرور لینوکس و پشتیبانی توزیع: اوبونتو 22.04+/24.04، دبیان 12+، CentOS Stream 8+/AlmaLinux/Rocky، RHEL 8+/9+، فدورا 37+. مسیرهای پکیج و لاگ توزیع خودتان را تأیید کنید.
دسترسی مدیریتی: یک کاربر با دسترسی sudo یا دسترسی کنسول/root برای بازیابی (کنسول سریال/KVM/کنسول ابری). همیشه یک مسیر بازیابی اضطراری در دسترس نگه دارید.
دسترسی ترمینال: SSH یا کنسول محلی همراه با یک ویرایشگر قابل اتکا (nano، vim) و مهارت پایه شل.
بکاپ/اسنپ‌شات (به‌شدت توصیه‌شده): قبل از ویرایش sudoers یک ایمیج یا اسنپ‌شات بگیرید تا در صورت نیاز بتوانید سریع بازگردانی کنید.
محیط تست/استیجینگ (توصیه‌شده): ویرایش‌ها و مراحل بازیابی را ابتدا روی یک ماشین مجازی غیرپروداکشن تمرین کنید.
اعتبارسنجی و ابزارها: با visudo، visudo -c، sudo -k && sudo -v && sudo -l و journalctl برای تأیید رفتار و لاگ‌ها آشنا باشید و از آن‌ها استفاده کنید.
عادت تأیید مسیرها: قبل از نوشتن قوانین، مسیرهای مطلق را تعیین کنید (مثلاً command -v systemctl) و از همان مسیرها دقیقاً در sudoers استفاده کنید.
(اختیاری) آمادگی یکپارچه‌سازی AI: برای Shell MCP Server، پایتون 3.9+ و pip یا uv را در دسترس داشته باشید؛ به‌همراه یک حساب غیرممتاز اختصاصی (مثلاً aiops) و دایرکتوری‌های ایزوله زیر /var/aiops/ برای لاگ‌ها/tmp. فقط وقتی با مدل امنیتی کاملاً آشنا هستید سراغ فهرست‌های سفید AI بروید.

نحوه کسب دسترسی Root

روی سیستم‌های لینوکس، حساب root دسترسی مدیریتی نامحدود دارد. برای نصب نرم‌افزار، مدیریت کاربران، تغییر فایل‌های پیکربندی سیستم یا انجام بازیابی اضطراری، به دسترسی root یا معادل آن نیاز دارید. چون این اقدامات می‌توانند رفتار سیستم را تغییر دهند یا داده‌های حساس را افشا کنند، روش‌های ارتقای دسترسی عمداً کنترل‌شده و قابل ممیزی هستند.

این بخش سه روش رایج برای کسب دسترسی root، بده‌وبستان‌های امنیتی هر کدام و الگوهای استفاده پیشنهادی را توضیح می‌دهد.

نحوه انتخاب روش درست دسترسی Root (sudo در مقابل su در مقابل root)

از sudo برای مدیریت روزانه استفاده کنید. از ورود مستقیم با root بپرهیزید؛ از su فقط به‌ندرت روی سیستم‌های قدیمی یا وقتی sudo در دسترس نیست استفاده کنید. یک مسیر بازیابی اضطراری (کنسول/root) برای شرایط بحرانی نگه دارید. سپس سیاست را با visudo الزامی کنید و با sudo -l تست بگیرید.

ماتریس تصمیم سریع

کار	روش پیشنهادی	دستور(های) اصلی	دلیل	ریسک‌ها / نکات	لاگ‌های قابل بررسی	راه‌حل / بازیابی
مدیریت روتین (پکیج‌ها، سرویس‌ها)	sudo برای هر دستور	`sudo apt install ...`، `sudo systemctl restart ...`	حداقل دسترسی؛ رد ممیزی به ازای هر دستور؛ لغو آسان	غلط تایپی در sudoers می‌تواند دستورات را رد کند؛ همیشه سیاست را اعتبارسنجی کنید	دبیان/اوبونتو: `/var/log/auth.log`؛ RHEL: `/var/log/secure`	اگر رد شد، مسیر مطلق در قانون را تأیید کنید؛ `sudo -l` را اجرا کنید؛ سیاست را با visudo اصلاح کنید
نگهداری یک‌باره که به شل root نیاز دارد	`sudo -i`	`sudo -i`	ارتقای لاگ‌شده با هویت خودتان؛ بدون اشتراک رمز root	شل ارتقایافته می‌تواند شعاع خرابی را بزرگ کند—بعد از اتمام کار فوراً خارج شوید	همان موارد بالا	اگر شل مجاز نیست، یک قانون موقت در `/etc/sudoers.d/` اضافه و بعد از کار حذف کنید
هاست‌های قدیمی بدون پیکربندی sudo	`su`	`su` / `exit`	بدون نیاز به راه‌اندازی sudo کار می‌کند؛ نگهداری پیوسته	اشتراک رمز root پاسخگویی را کم می‌کند؛ خطاکردن در شل root آسان‌تر است	تاریخچه شل + لاگ‌های سیستم	به sudo مهاجرت کنید؛ کاربر مدیر نام‌دار بسازید؛ سیاست را به `/etc/sudoers.d/` منتقل کنید
بازیابی اضطراری (sudo خراب شده)	ورود مستقیم root از کنسول	ورود کنسول/سریال؛ حالت تک‌کاربره/اضطراری	بازپس‌گیری کنترل وقتی sudoers نامعتبر است	ورود ریموت root با SSH باید معمولاً غیرفعال باشد	لاگ‌های بوت؛ خروجی شل بازیابی	در صورت موجود بودن از `pkexec visudo` استفاده کنید؛ وگرنه در حالت تک‌کاربره مونت RW کنید و با visudo اصلاح کنید

بررسی‌های قبل از انتخاب روش

دسترسی‌های فعلی خود را تأیید کنید:

id && groups && sudo -l

سلامت سیاست sudo را اعتبارسنجی کنید:

sudo visudo -c || echo "Sudoers خطا دارد — از کنسول یا pkexec visudo برای تعمیر استفاده کنید."

مسیرهای مطلق دستوراتی که می‌خواهید مجاز کنید را تأیید کنید (قوانین باید با مسیرهای کامل مطابقت داشته باشند):

command -v systemctl

۱. ورود با حساب root

ورود مستقیم با کاربر root، بلافاصله دسترسی کامل می‌دهد:

# ورود مستقیم SSH با root (فقط اگر ورود root فعال باشد)
ssh root@server_domain_or_ip

به‌طور فوری امن‌سازی کنید (توصیه‌شده): ورود ریموت root با SSH را غیرفعال کنید تا سطح حمله کاهش یابد:

# در /etc/ssh/sshd_config
PermitRootLogin no
# سپس ریلود
sudo systemctl reload sshd

مزایای ورود root:

دسترسی نامحدود فوری
مفید برای بازیابی از کنسول/خارج از باند وقتی sudo در دسترس نیست

معایب ورود root:

ریسک بالا برای کارهای روزمره (بدون رد ممیزی به ازای هر کاربر)
سطح حمله را اگر روی SSH مجاز باشد گسترش می‌دهد

چه زمانی از ورود root استفاده کنیم؟

فقط موارد اضطراری: دسترسی کنسول/سریال، حالت تک‌کاربره، یا هنگام تعمیر سیاست sudoers خراب‌شده

نکته ممیزی ورود root:

روی بسیاری از توزیع‌ها، تلاش‌های ورود مستقیم root با SSH در /var/log/auth.log (دبیان/اوبونتو) یا /var/log/secure (خانواده RHEL) ثبت می‌شوند. مرتباً بررسی کنید:

# دبیان/اوبونتو
sudo grep -i "session opened for user root" /var/log/auth.log | tail -n 20
# RHEL/CentOS
sudo grep -i "session opened for user root" /var/log/secure | tail -n 20

۲. استفاده از su برای تبدیل شدن به root

دستور su (جایگزینی کاربر) شل شما را به حساب دیگری (معمولاً root) تغییر می‌دهد:

# تبدیل به root (رمز حساب root را می‌پرسد)
su
# بازگشت به شل عادی
exit

مزایای استفاده از su چیست؟

همیشه در دسترس؛ بدون نیاز به پیکربندی قبلی sudo
مفید برای نشست‌های نگهداری کوتاه و پیوسته

معایب su چیست؟

رمز root را به اشتراک می‌گذارد (پاسخگویی کمتر)
آسان است فراموش کنید در شل root هستید؛ شعاع خرابی را افزایش می‌دهد

چه زمانی باید از su استفاده کرد؟

محیط‌های انتقالی/قدیمی که هنوز sudo در آن‌ها پیکربندی نشده
سیستم‌های تک‌مدیری که موقتاً به شل root مداوم نیاز دارند

چطور برای امنیت بیشتر از su فاصله بگیریم؟

sudo را راه‌اندازی کنید و اعتبارنامه‌های مشترک root را بازنشسته کنید. کاربران مدیر نام‌دار بسازید و به گروه مناسب اضافه کنید (ببینید: بخش‌های بعدی).

۳. استفاده از sudo برای اجرای دستورات با دسترسی root (توصیه‌شده)

دستور sudo دستورات منفرد را با دسترسی ارتقایافته اجرا می‌کند و ثبت می‌کند چه کسی چه کاری انجام داده:

# اجرای یک دستور منفرد به‌عنوان root
sudo systemctl restart sshd

# باز کردن یک شل ورود ارتقایافته (از محیط root استفاده می‌کند)
sudo -i

# فهرست دسترسی‌های مؤثر شما
sudo -l

مزایای sudo چیست؟

به‌طور پیش‌فرض حداقل‌دسترسی؛ فقط برای دستوری که اجرا می‌کنید ارتقا می‌یابید
رد ممیزی به ازای هر کاربر از طریق لاگ‌های سیستم
کنترل ریزبینانه از طریق /etc/sudoers و /etc/sudoers.d/*

معایب sudo چیست؟

نیازمند پیکربندی اولیه (باید به کاربری دسترسی sudo داده شود)
سینتکس بد sudoers می‌تواند دسترسی مدیریتی را قفل کند (از visudo استفاده کنید)

چه زمانی باید از sudo استفاده کرد؟

مدیریت روزانه روی سرورهای مشترک و سیستم‌های پروداکشن

چطور یک کاربر را برای sudo امن راه‌اندازی کنیم؟

# دبیان/اوبونتو
sudo usermod -aG sudo <username>
# RHEL/CentOS/Fedora
sudo usermod -aG wheel <username>

چطور پیکربندی sudo را اعتبارسنجی و تست کنیم؟

# ابتدا سینتکس sudoers را اعتبارسنجی کنید
sudo visudo -c
# بازاعتبارسنجی اجباری و سپس کش کردن اعتبارنامه‌ها
sudo -k && sudo -v
# تأیید اینکه کاربر چه کاری می‌تواند انجام دهد
sudo -l

لاگ‌های sudo را کجا بررسی کنیم؟

# دبیان/اوبونتو
sudo grep -i sudo /var/log/auth.log | tail -n 20
# RHEL/CentOS/Fedora
sudo grep -i sudo /var/log/secure | tail -n 20

برای راه‌اندازی سریع، راهنمای «نحوه ساخت کاربر جدید دارای دسترسی sudo در اوبونتو» در پارمین کلود را ببینید.

visudo چیست؟

دستور sudo توسط سیاستی که در /etc/sudoers ذخیره شده کنترل می‌شود. آن فایل (و فایل‌های زیر /etc/sudoers.d) تعیین می‌کنند کدام کاربران می‌توانند چه دستوراتی را و تحت چه شرایطی اجرا کنند. چون یک خطای سینتکس منفرد در /etc/sudoers می‌تواند کل sudo را از کار بیندازد، هرگز نباید /etc/sudoers را با یک ویرایشگر متنی معمولی ویرایش کنید.

visudo ویرایشگر امن sudoers است:

sudo visudo

مرجع: برای سینتکس رسمی و تضمین‌های امنیتی، صفحات راهنمای man برای sudoers(5) و visudo(8) را ببینید.

visudo چه چیزهایی فراهم می‌کند

قفل انحصاری تا فقط یک مدیر هم‌زمان بتواند ویرایش کند؛ که از شرایط رقابتی (Race Condition) جلوگیری می‌کند.
اعتبارسنجی سینتکس هنگام ذخیره — ویرایش‌های نامعتبر رد می‌شوند و فایل کارکرد قبلی دست‌نخورده باقی می‌ماند.
ویرایش هدفمند با -f تا بتوانید فایل‌های زیر /etc/sudoers.d را امن ویرایش کنید.

اعتبارسنجی بدون ویرایش

برای بررسی سینتکس پیکربندی فعلی بدون باز کردن ویرایشگر:

sudo visudo -c

نمونه خروجی — سینتکس معتبر:

/etc/sudoers: parsed OK

نمونه خروجی — خطای سینتکس:

/etc/sudoers: line 42: syntax error near 'ALL'
/etc/sudoers: parse error

وقتی visudo -c خطای پارس گزارش می‌کند، فایل و شماره خط تقریبی را هم می‌گوید تا بتوانید خط موردنظر را با visudo اصلاح کنید.

پیکربندی ویرایشگر (اوبونتو در مقابل CentOS/RHEL)

اوبونتو / دبیان: visudo به‌طور معمول nano را برای سادگی تعاملی باز می‌کند.
CentOS / RHEL: visudo معمولاً vi/vim را باز می‌کند.

تغییر ویرایشگر در کل سیستم روی دبیان/اوبونتو:

sudo update-alternatives --config editor

یا تنظیم ترجیح در سطح کاربر در فایل rc شل خودتان برای هر توزیعی:

# استفاده از vim برای visudo و دستورات مبتنی بر ویرایشگر
export EDITOR="$(command -v vim)"
# ریلود پیکربندی شل
. ~/.bashrc

مقایسه سریع ویرایشگرهای رایج

ویرایشگر	مزایا	معایب
nano	کاربرپسند برای مبتدیان؛ استفاده آسان	قابلیت‌ها و میان‌برهای محدود
vim/vi	ویرایش قدرتمند، همه‌جا حاضر، پشتیبانی از ماکرو	منحنی یادگیری تندتر برای کاربران جدید
ed	فوق‌سبک؛ موجود روی سیستم‌های مینیمال	استفاده تعاملی دشوار؛ برای بیشتر مدیران توصیه نمی‌شود

ویرایش فایل‌های جدا تحت /etc/sudoers.d

بهترین روش: سیاست‌های سفارشی را در فایل‌های جداگانه زیر /etc/sudoers.d/ نگه دارید. این کار /etc/sudoers را تمیز نگه می‌دارد و بررسی یا حذف قوانین پکیج‌ها را ساده‌تر می‌کند:

# ویرایش یا ساخت امن یک فایل جداگانه
sudo visudo -f /etc/sudoers.d/99-custom-ops

visudo فایل جداگانه را مثل خود فایل اصلی sudoers اعتبارسنجی می‌کند.

نحوه تغییر امن فایل Sudoers

این روند کاری تکرارپذیر را برای تغییر امن و قابل ممیزی سیاست sudo دنبال کنید.

گام ۱ — اعتبارسنجی سیاست فعلی

قبل از دست زدن به هر چیزی، سینتکس را بررسی کنید:

sudo visudo -c

اگر سالم باشد، parsed OK چاپ می‌شود.
خطاها شامل فایل و شماره خط برای اصلاح‌اند.

گام ۲ — باز کردن سیاست با visudo

فایل اصلی یا (ترجیحاً) یک فایل جداگانه را ویرایش کنید:

# سیاست اصلی
sudo visudo

# فایل جداگانه (توصیه‌شده)
sudo visudo -f /etc/sudoers.d/99-custom-ops

چرا فایل‌های جداگانه؟ ممیزی آسان‌تر، بازگردانی هدفمند، دیف‌های تمیزتر و تداخل‌های ادغام کمتر.

گام ۳ — مدیریت مبتنی بر گروه را ترجیح دهید (دسترسی کامل)

دسترسی کامل مدیریتی را از طریق گروه مدیر توزیع بدهید، نه با افزودن قوانین ALL به ازای هر کاربر:

# اوبونتو/دبیان
sudo usermod -aG sudo <username>

# RHEL/CentOS/Fedora
sudo usermod -aG wheel <username>

در صورت نیاز روی توزیع‌های خانواده RHEL، مطمئن شوید خط %wheel در sudoers فعال است:

%wheel ALL=(ALL) ALL

گام ۴ — ساخت قوانین حداقل‌دسترسی (دسترسی محدوده‌شده)

از نام‌های مستعار (Alias) و مسیرهای مطلق دستورات استفاده کنید. قوانین را مشخص و قابل ممیزی نگه دارید:

# /etc/sudoers.d/webops (با visudo -f ویرایش کنید)
# نام مستعار دستور برای اقدامات روشن/خاموش کردن
Cmnd_Alias POWER = /sbin/shutdown, /sbin/halt, /sbin/reboot

# کاربرانی که مجازند POWER را اجرا کنند
User_Alias  GROUPTWO = brent, doris, eric
GROUPTWO ALL = POWER

نام‌های مستعار Run-as به شما اجازه می‌دهند کاربران سرویس را هدف بگیرید:

Runas_Alias WEB = www-data, apache
GROUPTWO ALL = (WEB) /usr/bin/systemctl

از NOPASSWD: به‌ندرت و فقط برای دستورات محدود و کم‌ریسک استفاده کنید:

GROUPTWO ALL = NOPASSWD: /usr/bin/updatedb

گام ۵ — اعتبارسنجی مجدد و تست عملی

# بررسی سینتکس
sudo visudo -c

# بازاحراز هویت و فهرست دسترسی‌های مؤثر
sudo -k && sudo -v && sudo -l

اگر دستوری رد شد، مسیر مطلق، هدف Runas و اینکه هیچ قانون بعدی آن را بازنویسی نکرده را تأیید کنید.

گام ۶ — ثبت لاگ و ممیزی

# دبیان/اوبونتو
sudo grep -i sudo /var/log/auth.log | tail -n 50
# RHEL/CentOS/Fedora
sudo grep -i sudo /var/log/secure | tail -n 50

در صورت نیاز سیاست به ممیزی‌های تفصیلی، فعال کردن لاگ ورودی/خروجی sudo را در نظر بگیرید.

نکات امن‌سازی (پیشرفته)

مثال پیاده‌سازی عمیق — اعطای دسترسی sudo ریزبینانه برای رییلود Nginx (بهترین روش)

اعطای حداقل دسترسی لازم به کاربران برای انجام وظایف عملیاتی‌شان، سنگ بنای مدیریت امن سیستم است. سناریوی رایجی که زیاد پیش می‌آید، اجازه دادن به یک کاربر دیپلوی یا پروسه خودکارسازی برای رییلود کردن وب‌سرور Nginx است—بدون دادن دسترسی کامل root. این بخش راهنمای جامع و گام‌به‌گامی برای پیاده‌سازی این کار با بیشترین ایمنی، قابلیت ممیزی و نگهداری‌پذیری ارائه می‌دهد.

چرا این موضوع مهم است

اجازه رییلود Nginx به کاربران یا خودکارسازی اغلب برای دیپلوی‌های بدون قطعی یا تغییرات پیکربندی ضروری است. اما دادن sudo بی‌قیدوشرط یا دسترسی root، ریسک امنیتی بزرگی است. با ساخت یک قانون دقیق sudoers:

اصل حداقل دسترسی را الزامی می‌کنید: کاربر فقط می‌تواند Nginx را رییلود کند؛ نه ری‌استارت، نه توقف، نه پیکربندی مجدد سرویس و نه اقدامات ممتاز نامرتبط دیگر.
رد ممیزی شفاف حفظ می‌کنید: هر اقدام ممتاز همراه با هویت کاربر فراخوان‌کننده ثبت می‌شود.
تفویض امن را ممکن می‌کنید: می‌توانید به توسعه‌دهنده‌ها یا سیستم‌های CI/CD قدرت دیپلوی امن بدهید، بدون قرار دادن سیستم در معرض ریسک غیرضروری.

گام ۱: پیش‌نیازها و آماده‌سازی

قبل از ادامه، از موارد زیر اطمینان حاصل کنید:

Nginx نصب شده و توسط systemd مدیریت می‌شود (یعنی برای رییلود سرویس از systemctl reload nginx استفاده می‌کنید).
یک گروه و کاربر اختصاصی برای وظایف دیپلوی دارید یا خواهید ساخت. این تفکیک وظایف برای قابلیت ممیزی و لغو دسترسی حیاتی است.

گروه deploy و کاربر را بسازید (اگر از قبل وجود ندارند):

sudo groupadd -f deploy
id -u deployer >/dev/null 2>&1 || sudo useradd -m -G deploy deployer

تأیید مسیر (مسیر مطلق دستور):

از مسیر دقیق systemctl در قانون sudoers خود استفاده کنید. آن را روی هاست‌تان تأیید و متناسب جایگزین کنید:

# کشف مسیر مطلق resolve شده systemctl
command -v systemctl
readlink -f "$(command -v systemctl)"

نکته توزیع: روی بیشتر سیستم‌ها systemctl در /usr/bin/systemctl قرار دارد، اما برخی توزیع‌ها یا ایمیج‌های مینیمال ممکن است آن را در /bin/systemctl (یا از طریق symlink) ارائه کنند. همیشه از مسیر دقیقی که دستور بالا چاپ می‌کند در فایل sudoers استفاده کنید.

گام ۲: ساخت قانون حداقل‌دسترسی

با visudo -f فایلی بسازید که فقط رییلود Nginx را به‌عنوان root مجاز می‌کند (بدون ری‌استارت/توقف):

# /etc/sudoers.d/deploy-nginx (فقط با visudo -f ویرایش کنید)
%deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx

نکته: اگر مسیر systemctl شما متفاوت است (مثلاً /bin/systemctl)، در فایل بالا /usr/bin/systemctl را با مسیر دقیق کشف‌شده جایگزین کنید.

هم فایل جداگانه و هم کل سیاست را اعتبارسنجی کنید:

sudo visudo -f /etc/sudoers.d/deploy-nginx
sudo visudo -c

گام ۳: اعتبارسنجی و تست

یک نشست تازه برای کاربر deploy باز کنید، دسترسی‌ها را تأیید و اقدام را انجام دهید:

# اطمینان از نبود اعتبارسنجی کش‌شده، سپس رفتن به حساب deployer
sudo -k
sudo -u deployer -i

# فهرست دسترسی‌های مؤثر sudo
aaa=$(sudo -l 2>&1); echo "$aaa"

# بررسی عملکردی: رییلود Nginx با حداقل دسترسی
sudo /usr/bin/systemctl reload nginx

تأیید موفقیت رییلود:

وضعیت سرویس و لاگ‌های اخیر را بررسی کنید تا از رییلود (نه ری‌استارت) مطمئن شوید:

# نمایش خلاصه وضعیت فعلی (بدون پیجر)
systemctl status nginx --no-pager | sed -n '1,12p'

# بررسی لاگ‌های اخیر یونیت برای ورودی‌های "reloaded"
journalctl -u nginx -n 20 --no-pager

به‌صورت اختیاری، تأیید کنید که PID پروسه اصلی تغییر نکرده (رییلود PID اصلی را نگه می‌دارد؛ ری‌استارت آن را جایگزین می‌کند):

before=$(pidof nginx | awk '{print $1}')
sudo /usr/bin/systemctl reload nginx
after=$(pidof nginx | awk '{print $1}')
if [ "$before" = "$after" ]; then echo "رییلود موفق (PID بدون تغییر)"; else echo "PID تغییر کرد؛ این یک ری‌استارت بود"; fi

نمونه لاگ مورد انتظار:

<timestamp> <host> sudo:   deployer : TTY=pts/0 ; PWD=/home/deployer ; USER=root ; COMMAND=/usr/bin/systemctl reload nginx

گام ۴: بازگردانی / پاک‌سازی

اگر لازم است تغییرات را برگردانید، فایل جداگانه را حذف و دوباره اعتبارسنجی کنید:

sudo rm -f /etc/sudoers.d/deploy-nginx
sudo visudo -c

نکات امنیتی:

از مسیرهای مطلق و محدوده محدود استفاده کنید؛ از وایلدکارت بپرهیزید.
قوانین را در /etc/sudoers.d/ نگه دارید تا ممیزی آسان‌تر و بازگردانی امن‌تر باشد.
NOPASSWD: را فقط برای دستورات عملیاتی کم‌ریسک به کار ببرید؛ لاگ‌ها را مرتباً مرور کنید.
فعال کردن لاگ ورودی/خروجی sudo و پیش‌فرض secure_path را برای کنترل‌های قوی‌تر در نظر بگیرید.

خطاهای رایج و رفع آن‌ها

نشانه / پیام	علت محتمل	راه‌حل
user is not in the sudoers file	کاربر در گروه مدیر نیست	به گروه sudo (اوبونتو) یا wheel (RHEL) اضافه و دوباره وارد شوید
parse error همراه شماره خط	خطای سینتکس در فایل/قطعه	با visudo باز کنید و خط اشاره‌شده را اصلاح کنید؛ `visudo -c` را دوباره اجرا کنید
command not allowed	قانون فاقد مسیر مطلق یا Runas اشتباه	از مسیر کامل استفاده کنید (مثلاً `/usr/bin/systemctl`)؛ مطمئن شوید `(USER)` یا `(GROUP)` درست است
NOPASSWD اثر نمی‌کند	تگ بعداً بازنویسی شده یا محدوده‌اشتباه دارد	`NOPASSWD:` را به دستور نزدیک‌تر کنید یا تگ متناقض `PASSWD:` را حذف کنید
فایل جداگانه اعمال نمی‌شود	نام فایل بد (شامل نقطه یا منتهی به ~)	به نام ساده تغییر نام دهید (مثلاً `99-team-rules`)
sudo کاملاً خراب است	sudoers نامعتبر؛ هیچ sudoای کار نمی‌کند	از کنسول/root، `su -` یا `pkexec visudo` برای تعمیر استفاده کنید؛ آخرین راه‌حل بوت در حالت تک‌کاربره است

عیب‌یابی

این راهنمای عملی، رفع‌های سریع و تکرارپذیر به شما می‌دهد. با درخت تصمیم شروع کنید، سپس رد مربوطه را از جدول اعمال کنید.

درخت تصمیم (تفکیک سریع)

اصلاً نمی‌توانید sudo اجرا کنید؟

pkexec visudo را امتحان کنید. اگر در دسترس نیست، به حالت تک‌کاربره/اضطراری بوت کنید، فایل‌سیستم ریشه را با دسترسی خواندن-نوشتن مونت کنید، سپس سیاست را با visudo اصلاح کنید.

«command not allowed» می‌گیرید با اینکه قانون اضافه کرده‌اید؟

مسیر مطلق و هدف Runas را تأیید کنید؛ بررسی کنید قانون بعدی قانون شما را بازنویسی نکرده باشد؛ با visudo -c دوباره اعتبارسنجی و با sudo -l دسترسی‌ها را فهرست کنید.

فایل جداگانه نادیده گرفته می‌شود؟

مطمئن شوید نام فایل نقطه (.) ندارد و به ~ ختم نمی‌شود. نام‌های ساده نگه دارید (مثلاً 99-team-rules). دوباره اعتبارسنجی کنید.

جدول راهنمای عیب‌یابی

نشانه	بررسی‌های سریع	راه‌حل	دستورات نمونه
اصلاً sudo اجرا نمی‌شود	آیا pkexec موجود است؟ دسترسی کنسول/ILO/سریال دارید؟	در صورت موجود بودن از `pkexec visudo` استفاده کنید. اگر نه، به حالت تک‌کاربره یا اضطراری بوت کنید، `/` را به‌صورت خواندن-نوشتن ریمونت و با visudo تعمیر کنید.	`pkexec visudo; mount -o remount,rw /; visudo`
«command not allowed»	آیا قانون از مسیر مطلق استفاده می‌کند؟ آیا (USER)/(GROUP) درست مشخص شده؟ قانون بعدی بازنویسی نکرده؟	از مسیر کامل استفاده کنید؛ Runas درست را تنظیم کنید؛ قانون اجازه را پایین‌تر از هر ردِ گسترده‌ای بگذارید؛ دوباره اعتبارسنجی کنید.	`which systemctl; sudo -l; sudo visudo -c`
فایل جداگانه نادیده گرفته می‌شود	نام فایل نقطه یا ~ دارد؟ در `/etc/sudoers.d/` است؟	به نام ساده (بدون نقطه یا ~) در `/etc/sudoers.d/` تغییر نام دهید و دوباره اعتبارسنجی کنید.	`sudo ls -al /etc/sudoers.d/; sudo mv /etc/sudoers.d/team.rules /etc/sudoers.d/99-team-rules; sudo visudo -c`
parse error با شماره خط	چه فایل و خطی گزارش شده؟	فایل را با visudo باز کنید، خط دقیق را اصلاح و دوباره اعتبارسنجی کنید.	`sudo visudo; sudo visudo -c`
«user is not in the sudoers file»	کاربر در گروه مدیر است؟ (اوبونتو: sudo، RHEL: wheel)	کاربر را به گروه مناسب اضافه کنید و او را از سیستم خارج و دوباره وارد کنید.	`sudo usermod -aG sudo <username>; sudo usermod -aG wheel <username>`
NOPASSWD اثر نمی‌کند	تگ `PASSWD:` بعدی بازنویسی کرده؟ قانون خیلی کلی است؟	`NOPASSWD:` را کنار دستور مشخص قرار دهید یا تگ‌های متناقض را حذف کنید؛ دوباره اعتبارسنجی کنید.	`sudo visudo -f /etc/sudoers.d/99-team-rules; sudo visudo -c`

حالت تک‌کاربره / اضطراری (مراحل گسترده)

هشدار: مراحل دقیق ورود به حالت تک‌کاربره یا اضطراری بسته به توزیع لینوکس، بوت‌لودر (مثل GRUB یا systemd-boot) و اینکه روی سرور فیزیکی، ماشین مجازی یا ایمیج ابری اجرا می‌شوند، به‌طور چشمگیری متفاوت است. همیشه در صورت مواجهه با تفاوت‌ها، مستندات رسمی پلتفرم‌تان را ملاحظه کنید.

۱. ریبوت و ورود به حالت بازیابی یا تک‌کاربره

سیستم را ریبوت کنید.

در منوی بوت (اغلب GRUB)، به دنبال گزینه‌ای با برچسب «Advanced options» یا «recovery mode» بگردید. روی برخی سیستم‌ها ممکن است لازم باشد کلیدی (مثل Esc، Shift یا F12) را فشار دهید تا به منوی بوت دسترسی پیدا کنید.

گزینه بازیابی یا تک‌کاربره را انتخاب کنید. این کار سیستم را به محیطی مینیمال—اغلب با دسترسی root—بوت می‌کند.

۲. دسترسی به شل root و ریمونت فایل‌سیستم ریشه (در صورت نیاز)

وقتی در حالت بازیابی یا تک‌کاربره هستید، یک پرامپت شل root به شما ارائه می‌شود.

روی بسیاری از سیستم‌ها، فایل‌سیستم ریشه برای ایمنی به‌صورت فقط-خواندنی مونت می‌شود. برای اعمال تغییرات، باید آن را به‌صورت خواندن-نوشتن ریمونت کنید:

mount -o remount,rw /

اگر خطا گرفتید، نام دستگاه فایل‌سیستم ریشه‌تان را دوباره بررسی کنید (ممکن است /dev/sda1، /dev/vda1 و غیره باشد) و دستور را متناسب تنظیم کنید.

۳. تعمیر امن فایل Sudoers با visudo

از دستور visudo برای ویرایش امن فایل اصلی sudoers یا یک قطعه مشخص استفاده کنید. visudo قبل از ذخیره، خطاهای سینتکس را بررسی می‌کند؛ که به جلوگیری از اشتباهات پیکربندی که می‌توانند شما را قفل کنند کمک می‌کند:

visudo

اگر می‌دانید قانون مشکل‌دار در یک فایل جداگانه است (مثلاً فایلی در /etc/sudoers.d/)، مستقیماً همان فایل را هدف بگیرید:

visudo -f /etc/sudoers.d/99-team-rules

بعد از اعمال تغییرات، همیشه پیکربندی را اعتبارسنجی کنید:

visudo -c

اگر با خطاهای سینتکس روبه‌رو شدید، visudo آن‌ها را همراه با اطلاعات فایل و شماره خط گزارش می‌کند. قبل از ادامه، مشکلات را اصلاح کنید.

۴. ریبوت عادی سیستم

وقتی پیکربندی sudoers را تعمیر و اعتبارسنجی کردید، سیستم را ریبوت کنید تا به حالت عادی چندکاربره برگردید:

reboot

بعد از ریبوت، کارکرد sudo را تست کنید تا مطمئن شوید مشکل حل شده است.

نکته: اگر روی یک سرور ابری (مانند پارمین کلود) کار می‌کنید، ممکن است لازم باشد برای انجام این مراحل از کنسول وب یا دسترسی کنسول سریال ارائه‌دهنده استفاده کنید؛ چون تا وقتی سیستم کاملاً بوت شده و sudo کار می‌کند، SSH ممکن است در دسترس نباشد.

خلاصه: ورود به حالت تک‌کاربره یا اضطراری به شما اجازه می‌دهد با ویرایش مستقیم فایل sudoers با دسترسی‌های root، از پیکربندی‌های اشتباه sudo بازیابی کنید. همیشه از visudo برای جلوگیری از خطاهای سینتکس استفاده کنید و قبل از ریبوت، تغییرات‌تان را اعتبارسنجی کنید. اگر درباره هر مرحله مطمئن نیستید، مستندات بازیابی توزیع‌تان را ببینید یا کمک بگیرید تا از قفل شدن تصادفی یا از دست رفتن داده جلوگیری شود.

تأیید پس از تعمیر

این بررسی‌ها را اجرا کنید تا مطمئن شوید سیستم سالم است و سیاست با هدف مطابقت دارد:

# ۱) سینتکس
sudo visudo -c
# ۲) ریست کش احراز هویت و بازاحراز هویت
sudo -k && sudo -v
# ۳) دسترسی‌های مؤثر
sudo -l
# ۴) بررسی عملکردی (نمونه)
sudo -u www-data /usr/bin/systemctl reload nginx

نحوه اعطای دسترسی Sudo به کاربر

رایج‌ترین کاری که کاربران هنگام مدیریت مجوزهای sudo انجام می‌دهند، اعطای دسترسی sudo عمومی به یک کاربر جدید است. این کار مفید است اگر بخواهید به یک حساب، دسترسی مدیریتی کامل به سیستم بدهید.

ساده‌ترین راه انجام این کار روی سیستمی که با گروه مدیریت عمومی راه‌اندازی شده—مثل سیستم اوبونتوی این راهنما—در واقع افزودن کاربر موردنظر به آن گروه است.

نکته: اوبونتو 20.04 در مه ۲۰۲۵ به پایان عمر (EOL) رسید. اما گروه sudo همچنان روی همه نسخه‌های پشتیبانی‌شده فعلی اوبونتو (22.04، 24.04 و جدیدتر) دسترسی‌های مدیریتی کامل ارائه می‌کند.

مثلاً روی اوبونتو 22.04 و جدیدتر، گروه sudo دسترسی کامل مدیریتی دارد. می‌توانیم با افزودن کاربر به گروه، همین دسترسی‌ها را به او بدهیم:

sudo usermod -aG sudo <username>

دستور gpasswd هم قابل استفاده است:

sudo gpasswd -a <username> sudo

هر دوی این‌ها همان کار را انجام می‌دهند.

روی CentOS، این کار معمولاً با گروه wheel به‌جای گروه sudo انجام می‌شود:

sudo usermod -aG wheel <username>

یا با gpasswd:

sudo gpasswd -a <username> wheel

روی CentOS، اگر افزودن کاربر به گروه فوراً اثر نکرد، ممکن است لازم باشد فایل /etc/sudoers را ویرایش کنید تا نام گروه از کامنت دربیاید:

sudo visudo

# /etc/sudoers
. . .
%wheel ALL=(ALL) ALL
. . .

نحوه راه‌اندازی قوانین سفارشی Sudoers

حالا که با سینتکس کلی فایل آشنا شدیم، بیایید چند قانون جدید بسازیم.

نحوه ساخت نام‌های مستعار (Alias)

فایل sudoers را می‌توان با گروه‌بندی موارد با انواع «نام‌های مستعار» راحت‌تر سازمان‌دهی کرد.

مثلاً می‌توانیم سه گروه مختلف از کاربران با عضویت هم‌پوشان بسازیم:

# /etc/sudoers
. . .
User_Alias  GROUPONE = abby, brent, carl
User_Alias  GROUPTWO = brent, doris, eric
User_Alias  GROUPTHREE = doris, felicia, grant
. . .

نام گروه‌ها باید با حرف بزرگ شروع شوند. سپس می‌توانیم به اعضای GROUPTWO اجازه دهیم دیتابیس apt را به‌روز کنند با ساخت قانونی مثل این:

# /etc/sudoers
. . .
GROUPTWO ALL = /usr/bin/apt-get update
. . .

اگر مثل بالا کاربر/گروه اجراکننده را مشخص نکنیم، sudo به‌طور پیش‌فرض از کاربر root استفاده می‌کند.

می‌توانیم با ساخت یک «نام مستعار دستور» و استفاده از آن در قانونی برای GROUPTHREE، به اعضایش اجازه خاموش و ریبوت کردن ماشین بدهیم:

# /etc/sudoers
. . .
Cmnd_Alias  POWER = /sbin/shutdown, /sbin/halt, /sbin/reboot
GROUPTHREE ALL = POWER
. . .

نکته: نام مستعار POWER در مثال‌های قدیمی گاهی شامل /sbin/restart هم بود که روی بسیاری از توزیع‌های لینوکس استاندارد نیست. برای اجتناب از سردرگمی، بهتر است آن را حذف کنید و فقط /sbin/shutdown، /sbin/halt و /sbin/reboot را نگه دارید.

یک نام مستعار دستور به نام POWER ساختیم که دستورات خاموش و ریبوت کردن ماشین را شامل می‌شود. سپس به اعضای GROUPTHREE اجازه اجرای این دستورات را دادیم.

همچنین می‌توانیم «نام‌های مستعار Run as» بسازیم که می‌توانند بخشی از قانون که کاربر اجراکننده دستور را مشخص می‌کند جایگزین شوند:

# /etc/sudoers
. . .
Runas_Alias  WEB = www-data, apache
GROUPONE ALL = (WEB) ALL
. . .

این به هر عضوی از GROUPONE اجازه می‌دهد دستورات را به‌عنوان کاربر www-data یا apache اجرا کند.

فقط در نظر داشته باشید که قوانین بعدی، در صورت تعارض، قوانین قبلی را بازنویسی می‌کنند.

چگونه قوانین Sudo را برای حداکثر امنیت قفل کنیم

چرا قفل کردن قوانین Sudo حیاتی است

هنگام پیکربندی sudo، ضروری است دسترسی‌ها را تا جای ممکن محدود کنید تا از سوءاستفاده تصادفی یا مخربانه جلوگیری شود. قوانین بیش‌ازحد گسترده یا آسان‌گیرانه می‌توانند به کاربران اجازه دهند اقدامات ناخواسته انجام دهند؛ که بالقوه به به‌خطرافتادن سیستم، از دست رفتن داده یا اختلال سرویس منجر می‌شود. با قفل کردن دقیق قوانین sudoers، اصل حداقل دسترسی را الزامی می‌کنید—با اطمینان از اینکه کاربران و گروه‌ها فقط می‌توانند وظایف مدیریتی خاصِ موردنیازشان را انجام دهند و نه بیشتر.

خلاصه اینکه، قفل کردن قوانین sudo:

ریسک ارتقای دسترسی و آسیب تصادفی را کمینه می‌کند.
ممیزی و بررسی دسترسی‌ها را ساده‌تر می‌کند.
از انطباق با بهترین روش‌های امنیتی و الزامات قانونی پشتیبانی می‌کند.
سطح حمله در دسترس عوامل مخرب را کاهش می‌دهد.

بخش‌های بعدی تکنیک‌ها و مثال‌های عملی برای نوشتن قوانین sudoers امن و محکم را نشان می‌دهند؛ با استفاده از تگ‌هایی مثل NOPASSWD و NOEXEC فقط در جای مناسب و اطمینان از اینکه هر قانون تا جای ممکن مشخص و امن است.

قفل کردن قوانین در فایل sudoers تضمین می‌کند که ارتقای دسترسی کنترل‌شده و عامدانه باقی بماند. بدون محدودیت‌ها، کاربران ممکن است ناخواسته دسترسی گسترده‌تری از مورد نیاز به دست آورند؛ که به سوءاستفاده بالقوه یا شکاف‌های امنیتی منجر می‌شود. با اعمال دقیق تگ‌هایی مثل NOPASSWD یا NOEXEC و فقط به دستورات مشخص، اصول حداقل‌دسترسی را حفظ می‌کنید و در عین حال عملیات امن و قابل ممیزی را ممکن می‌سازید. این کار وضعیت امنیتی‌تان را تقویت می‌کند، ممیزی‌ها را شفاف‌تر می‌کند و ریسک خطا در محیط‌های پروداکشن را کاهش می‌دهد.

راه‌های متعددی برای کنترل بیشتر نحوه واکنش sudo به یک فراخوانی وجود دارد.

دستور updatedb مرتبط با پکیج mlocate روی سیستم تک‌کاربره نسبتاً بی‌خطر است. اگر بخواهیم به کاربران اجازه دهیم آن را با دسترسی root بدون تایپ رمز عبور اجرا کنند، می‌توانیم قانونی مثل این بسازیم:

# /etc/sudoers
. . .
GROUPONE ALL = NOPASSWD: /usr/bin/updatedb
. . .

NOPASSWD یک «تگ» است که یعنی رمز عبور درخواست نخواهد شد. یک تگ همزاد هم دارد به نام PASSWD که رفتار پیش‌فرض است. یک تگ برای بقیه قانون معتبر می‌ماند، مگر اینکه بعداً توسط تگ «همزاد»ش بازنویسی شود.

مثلاً می‌توانیم خطی مثل این داشته باشیم:

# /etc/sudoers
. . .
GROUPTWO ALL = NOPASSWD: /usr/bin/updatedb, PASSWD: /bin/kill
. . .

تگ مفید دیگری هم NOEXEC است که می‌تواند برای جلوگیری از برخی رفتارهای خطرناک در برنامه‌های خاص به کار رود.

مثلاً برخی برنامه‌ها مثل less می‌توانند با تایپ این از داخل رابط خودشان، دستورات دیگری اجرا کنند:

!command_to_run

این در اصل هر دستوری که کاربر بدهد را با همان دسترسی‌هایی که less در حال اجراست اجرا می‌کند؛ که می‌تواند بسیار خطرناک باشد.

برای محدود کردن این، می‌توانیم خطی مثل این استفاده کنیم:

# /etc/sudoers
. . .
<username> ALL = NOEXEC: /usr/bin/less
. . .

اطلاعات تکمیلی

چند نکته دیگر هم هست که ممکن است هنگام کار با sudo مفید باشد.

اگر در فایل پیکربندی کاربر یا گروه «اجرا به‌عنوان» مشخص کرده باشید، می‌توانید با فلگ‌های -u و -g به‌ترتیب دستورات را به‌عنوان آن کاربران/گروه‌ها اجرا کنید:

sudo -u <run_as_user> command
sudo -g <run_as_group> command

برای راحتی، sudo به‌طور پیش‌فرض جزئیات احراز هویت شما را برای مدت معینی در یک ترمینال ذخیره می‌کند. یعنی تا وقتی تایمر تمام نشده، دیگر لازم نیست رمز عبورتان را دوباره تایپ کنید.

برای اهداف امنیتی، اگر بخواهید این تایمر را بعد از اتمام اجرای دستورات مدیریتی پاک کنید، می‌توانید اجرا کنید:

sudo -k

از طرف دیگر، اگر می‌خواهید sudo را «از قبل آماده» کنید تا بعداً پرامپت نشوید، یا اجاره sudo خود را تمدید کنید، همیشه می‌توانید تایپ کنید:

sudo -v

از شما رمز عبور پرسیده می‌شود که برای استفاده‌های بعدی sudo کش می‌شود تا بازه زمانی sudo منقضی شود.

اگر صرفاً می‌خواهید بدانید چه نوع دسترسی‌هایی برای نام کاربری‌تان تعریف شده، می‌توانید تایپ کنید:

sudo -l

این دستور همه قوانین فایل /etc/sudoers که برای کاربر شما اعمال می‌شوند را فهرست می‌کند. تصویر خوبی از آنچه با sudo به‌عنوان هر کاربری مجاز یا غیرمجاز به انجامش هستید به شما می‌دهد.

بارها پیش می‌آید که دستوری اجرا می‌کنید و چون فراموش کرده‌اید sudo را قبلش بگذارید، شکست می‌خورد. برای اجتناب از تایپ مجدد دستور، می‌توانید از قابلیتی در bash استفاده کنید که یعنی «تکرار آخرین دستور»:

sudo !!

دو علامت تعجب، آخرین دستور را تکرار می‌کند. ما sudo را قبلش گذاشتیم تا دستور غیرممتاز را سریع به دستور ممتاز تبدیل کنیم.

برای کمی سرگرمی، می‌توانید خط زیر را با visudo به فایل /etc/sudoers خود اضافه کنید:

sudo visudo

# /etc/sudoers
. . .
Defaults insults
. . .

این کار باعث می‌شود sudo وقتی کاربری رمز عبور اشتباهی برای sudo وارد می‌کند، یک تیپ یک جواب مسخره بدهد. می‌توانیم با sudo -k رمز کش‌شده قبلی sudo را پاک کنیم تا امتحانش کنیم:

sudo -k
sudo ls

خروجی:

[sudo] password for demo:    # اینجا رمز اشتباه وارد کنید تا نتیجه را ببینید
Your mind just hasn't been the same since the electro-shock, has it?
[sudo] password for demo:
My mind is going. I can feel it.

مدیریت ارتقایافته با AI و Shell MCP Server

چرا مدیریت با کمک AI مهم است

ظهور دستیارها و هم‌پروازهای هوش مصنوعی، نحوه تعامل توسعه‌دهنده‌ها و تیم‌های عملیات با زیرساخت را دگرگون کرده است. به‌جای اجرای دستی دستورات تشخیصی، اسکن لاگ‌ها و انجام مانیتورینگ تکراری، مدیریت سیستم با کمک AI امکان خودکارسازی هوشمندانه را فراهم می‌کند و هم‌زمان کنترل‌های امنیتی سخت‌گیرانه را الزامی می‌سازد.

Shell MCP Server (سرور پروتکل زمینه مدل برای شل) راهی استاندارد برای اجرای دستورات مشخص توسط دستیارهای AI روی یک سیستم فراهم می‌کند. در ترکیب با قوانین sudoers با دامنه دقیق، به شما اجازه می‌دهد وظایف محدود و قابل ممیزی سیستم را به ایجنت‌های AI تفویض کنید—بدون افشای شل‌های root یا دسترسی‌های نامحدود.

مزایای کلیدی شامل:

مانیتورینگ خودکار: دستیارهای AI می‌توانند بررسی‌های منابع را اجرا و ناهنجاری‌ها را بلادرنگ به شما هشدار دهند.
عیب‌یابی هوشمند: به‌جای پارس دستی لاگ‌ها، AI می‌تواند الگوها را تحلیل و راه‌حل‌ها را پیشنهاد کند.
پشتیبانی امن دیپلوی: AI می‌تواند در اعتبارسنجی پیش از دیپلوی، رییلودهای کنترل‌شده سرویس و بررسی‌های بازگردانی کمک کند.
قابلیت ممیزی: هر دستور ممتازی که توسط AI اجرا می‌شود، زیر یک حساب سرویس نام‌دار ثبت می‌شود.

نکته امنیتی: ریسک اصلی مدیریت AI-محور، سوءاستفاده از دسترسی است. این راهنما اصل حداقل دسترسی را الزامی می‌کند—AI فقط می‌تواند دستورات از پیش تأییدشده با ردهای ممیزی شفاف اجرا کند، هرگز اقدامات root دلخواه نه.

پیش‌نیازهای راه‌اندازی Shell MCP Server

قبل از راه‌اندازی Shell MCP Server برای مدیریت با کمک AI، از رفع این الزامات مطمئن شوید:

الزامات سیستم:

یک سرور لینوکس با یکی از توزیع‌های: اوبونتو 22.04 یا جدیدتر، دبیان 12+، CentOS 8+، RHEL 8+ یا فدورا 37+.
پایتون 3.9 یا جدیدتر نصب‌شده.
pip یا uv برای مدیریت پکیج پایتون.

ساخت حساب سرویس اختصاصی AI:

برای امنیت و قابلیت ممیزی، یک کاربر غیر-ورود مخصوص عملیات AI بسازید:

sudo adduser --disabled-password --gecos "" aiops

راه‌اندازی دایرکتوری‌های ایزوله برای داده‌های AI:

دایرکتوری‌های اختصاصی برای لاگ‌ها و فایل‌های موقت بسازید و مالکیت را به کاربر aiops بدهید:

sudo mkdir -p /var/aiops/{logs,tmp}
sudo chown -R aiops:aiops /var/aiops

نصب Shell MCP Server:

با مدیر پکیج پایتون مورد علاقه‌تان، سرور را در محیط کاربر نصب کنید:

python3 -m pip install --user shell-mcp-server

یا اگر از uv استفاده می‌کنید:

uv tool install shell-mcp-server

پیکربندی اولیه سرور MCP:

دایرکتوری پیکربندی را بسازید و فایل کانفیگ اصلی را با تنظیمات مناسب سرور و لاگینگ راه بیندازید:

mkdir -p /home/aiops/.config/shell-mcp
cat <<EOF | sudo tee /home/aiops/.config/shell-mcp/config.yaml
server:
  port: 11434
  timeout: 30
  allowed_shell: /bin/bash
logging:
  level: INFO
  file: /var/log/aiops/mcp-server.log
EOF

از مالکیت کاربر aiops بر دایرکتوری پیکربندی و محتویاتش مطمئن شوید:

sudo chown -R aiops:aiops /home/aiops/.config/shell-mcp

پیکربندی Sudoers برای عملیات AI

فایل /etc/sudoers.d/50-ai-mcp-server را با قوانین با دامنه دقیق بسازید:

# پیکربندی امن sudoers برای Shell MCP Server
Cmnd_Alias AI_MONITORING = /usr/bin/uptime, /usr/bin/free, /usr/bin/df -h, /usr/bin/top -b -n 1
Cmnd_Alias AI_LOGS = /bin/journalctl -n 200, /bin/journalctl -u nginx -n 100, /usr/bin/tail -n 200 /var/log/syslog, /usr/bin/tail -n 200 /var/log/messages
Cmnd_Alias AI_SERVICES = /usr/bin/systemctl status nginx, /usr/bin/systemctl reload nginx, /usr/bin/systemctl status docker, /usr/bin/systemctl restart myapp
Cmnd_Alias AI_FILES = /usr/bin/ls /var/aiops/*, /usr/bin/cat /var/aiops/logs/*, /usr/bin/touch /var/aiops/tmp/*
Cmnd_Alias AI_NETWORK = /bin/ping -c 4 *, /usr/bin/curl -I http://*, /usr/bin/curl -I https://*
aiops ALL=(ALL) NOPASSWD: AI_MONITORING, AI_LOGS, AI_SERVICES, AI_FILES, AI_NETWORK

یکپارچه‌سازی Shell MCP Server

اجرای سرور:

sudo -u aiops shell-mcp-server --config /home/aiops/.config/shell-mcp/config.yaml

نمونه یکپارچه‌سازی با Claude:

{
  "servers": {
    "shell": {
      "command": "shell-mcp-server",
      "args": ["--config", "/home/aiops/.config/shell-mcp/config.yaml"],
      "env": { "PATH": "/usr/local/bin:/usr/bin:/bin" }
    }
  }
}

اعتبارسنجی:

ps -u aiops -o pid,cmd
sudo -u aiops sudo uptime
sudo -u aiops sudo bash  # باید رد شود

موارد استفاده دنیای واقعی

تحلیل خودکار لاگ: AI لاگ‌های ژورنال را برای الگوها اسکن می‌کند.
مانیتورینگ هوشمند: اجرای sudo -u aiops sudo free -m برای تحلیل روندهای حافظه.
دیپلوی امن: اجرای sudo -u aiops sudo systemctl reload nginx حین دیپلوی‌ها.
عیب‌یابی: اجرای sudo -u aiops sudo systemctl status docker برای تشخیص مشکلات.

ملاحظات امنیتی

فعال کردن لاگینگ sudo:

Defaults logfile="/var/log/sudo.log"

محدودیت نرخ (Rate Limit) از طریق systemd.
چرخش روزانه توکن‌های AI.
همیشه دسترسی کنسول/root را نگه دارید.
یکپارچه‌سازی با fail2ban یا SIEM.

عیب‌یابی عملیات AI

مشکل	تشخیص	راه‌حل
سرور MCP بالا نمی‌آید	خطای پیکربندی	`/var/log/aiops/mcp-server.log` را بررسی کنید
دستور رد شد	قانون sudoers اشتباه	`sudo visudo -c` را اجرا کنید
دستورات هنگ می‌کنند	تایم‌اوت	تایم‌اوت را در کانفیگ کم کنید
لاگ‌ها غایب‌اند	مسیر اشتباه	مسیر AI_LOGS را اصلاح کنید
قفل کامل	sudoers خراب	از `pkexec visudo` یا حالت تک‌کاربره استفاده کنید

گام‌های بعدی

MCP را با دستورات امن Kubernetes گسترش دهید.
در CI/CD یکپارچه کنید.
MFA را برای دسترسی sudo اکتشاف کنید.
صفحه PyPI پروژه Shell MCP Server را برای به‌روزرسانی‌ها دنبال کنید.

سوالات متداول

۱. فایل sudoers چیست و چرا مهم است؟

فایل sudoers (/etc/sudoers و /etc/sudoers.d/) تعیین می‌کند کدام کاربران می‌توانند دستورات ممتاز اجرا کنند.

به‌عنوان لایه سیاست امنیتی، حداقل دسترسی را الزامی می‌کند.
یک خطای سینتکس می‌تواند کل sudo را از کار بیندازد و دسترسی root را مسدود کند.
همیشه با visudo ویرایش کنید تا سینتکس قبل از ذخیره اعتبارسنجی شود.
در صورت پیکربندی درست، پاسخگویی، امن‌سازی سیستم و انطباق را در محیط‌های چندکاربره تضمین می‌کند.

۲. چرا همیشه باید از visudo به‌جای ویرایشگر متنی استفاده کنم؟

استفاده مستقیم از nano یا vim روی /etc/sudoers ریسک خراب کردن ارتقای دسترسی را دارد. visudo این مشکل را حل می‌کند:

فایل را برای جلوگیری از شرایط رقابتی قفل می‌کند.
سینتکس را قبل از ذخیره اعتبارسنجی می‌کند.
اگر خطا وجود داشته باشد، آخرین پیکربندی کارکرد را حفظ می‌کند.

استفاده:

sudo visudo
sudo visudo -f /etc/sudoers.d/99-custom-ops

این تضمین می‌کند ویرایش‌های امن‌تر و ماژولارتر با ریسک قفل شدن کمتر داشته باشید.

۳. چطور به‌شکل امن به کاربری دسترسی sudo بدهم؟

بهترین روش، تخصیص مبتنی بر گروه است:

# اوبونتو/دبیان
sudo usermod -aG sudo <username>

# RHEL/CentOS/Fedora
sudo usermod -aG wheel <username>

قوانین گروهی راحت‌تر ممیزی و لغو می‌شوند. از قوانین ALL به ازای هر کاربر بپرهیزید؛ در عوض فایل‌های جداگانه زیر /etc/sudoers.d/ بسازید. برای راهنمای گام‌به‌گام، آموزش «نحوه ساخت کاربر جدید دارای دسترسی sudo در اوبونتو» را ببینید.

۴. چطور sudo بدون رمز عبور را امن پیکربندی کنم؟

sudo بدون رمز فقط باید روی دستورات محدود و کم‌ریسک اعمال شود:

# /etc/sudoers.d/99-team-rules
GROUPONE ALL = NOPASSWD: /usr/bin/updatedb

از NOPASSWD: به‌ندرت استفاده کنید، از ALL بپرهیزید.
همیشه مسیرهای مطلق مشخص کنید.
با sudo visudo -c اعتبارسنجی کنید.
استفاده را از طریق /var/log/auth.log (اوبونتو) یا /var/log/secure (RHEL) ممیزی کنید.

این کار تعادل بین نیازهای خودکارسازی و پاسخگویی را برقرار می‌کند.

۵. اگر فایل sudoers را خراب کردم چه کنم؟

اگر sudo کاملاً از کار افتاد، تعمیر با این موارد را امتحان کنید:

pkexec visudo

اگر در دسترس نیست، به حالت تک‌کاربره/اضطراری بوت کنید:

mount -o remount,rw /
visudo

همیشه قبل از ریبوت با sudo visudo -c اعتبارسنجی کنید. به‌عنوان احتیاط، در سیستم‌های پروداکشن دسترسی کنسول یا root را برای بازیابی نگه دارید.

۶. چطور خطاهای رایج sudo را مؤثرانه عیب‌یابی کنم؟

خطاها را به رفع‌های سریع نگاشت کنید:

«command not allowed» ← مسیر مطلق را با which systemctl تأیید کنید؛ با sudo -l بررسی کنید.
فایل جداگانه نادیده گرفته می‌شود ← بدون . یا ~ تغییر نام دهید، مثلاً 99-team-rules.
parse error ← خط گزارش‌شده را در visudo باز کنید، با visudo -c دوباره اعتبارسنجی کنید.
کاربر در sudoers نیست ← به گروه sudo/wheel اضافه و دوباره وارد شوید.

بررسی‌های نظام‌مند، حل سریع‌تر را سرعت می‌بخشند.

۷. بهترین روش‌های پیشرفته امن‌سازی sudoers چیست؟

برای الزامای امنیت در سطح سازمانی:

فعال کردن لاگینگ: Defaults logfile=/var/log/sudo.log.
پیکربندی PATH امن:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

استفاده از لاگ ورودی/خروجی برای دستورات حساس.
الزام tty در RHEL: Defaults requiretty.
ممیزی دوره‌ای /etc/sudoers.d/ و چرخش حساب‌های دارای sudo.
در صورت امکان، یکپارچه‌سازی با MFA برای اقدامات سطح root.

نتیجه‌گیری

حالا پایه‌ای محکم برای خواندن و تغییر امن فایل sudoers دارید؛ به‌همراه ابزارهای مدیریت مسئولانه دسترسی‌های root. با همیشه استفاده از visudo، اعتبارسنجی تغییرات و اعمال اصل حداقل دسترسی، می‌توانید ریسک را کمینه کنید و در عین حال انعطاف و کنترل را حفظ نمایید.

دسترسی کاربر ممتاز (Super-user) هرگز نباید سبک گرفته شود—فقط وقتی لازم است از آن استفاده کنید و کارکردهای غیرضروری را محدود یا ممیزی کنید. پیروی از این بهترین روش‌ها کمک می‌کند سیستم‌های لینوکسی‌تان امن، مقاوم و مدیریت‌پذیر باقی بمانند.