وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

خطای «کاربر در sudoers نیست» در لینوکس؛ رفع مشکل بدون قفل‌شدن از سرور

راهنمای تشخیص خطای sudoers، بررسی گروه کاربر و بازیابی دسترسی مدیریتی در اوبونتو و AlmaLinux با حفظ راه ورود امن.

انتشار:
توسط تیم فنی نت‌آرام
۱۰ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله خطای «کاربر در sudoers نیست» در لینوکس؛ رفع مشکل بدون قفل‌شدن از سرور در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
با حساب عادی به سرور وصل شده‌اید و می‌خواهید کاری مدیریتی انجام دهید. پیش از دستور sudo می‌نویسید، اما پیام user is not in the sudoers file یا پیامی درباره مجاز نبودن اجرای دستور می‌بینید. معنی ساده‌اش این است که سیستم برای این حساب، در شرایط فعلی، اجازه اجرای آن کار با سطح مدیریتی پیدا نکرده است. لزوماً رمز اشتباه نیست و با تغییر رمز ریشه هم خودبه‌خود حل نمی‌شود.
نکته مهم: دادن دسترسی کامل sudo تقریباً به معنی دادن کلید مدیریت سرور است. اگر این حساب عمداً محدود شده یا سرور اشتراکی و مدیریت‌شده است، نباید خودسرانه محدودیتش را دور بزنید. روش زیر برای مدیر مجاز سرور مجازی یا اختصاصی است که واقعاً قصد دارد به یک حساب مشخص دسترسی بدهد.

قبل از شروع: راه ورود مدیریتی دوم داشته باشید

برای اضافه‌کردن دسترسی، معمولاً به یک حساب دیگر که از قبل دسترسی مدیریتی دارد یا به کنسول ارائه‌دهنده و حساب ریشه مجاز نیاز دارید. اگر تنها حساب شما همین حساب محدود است، خود آن حساب نمی‌تواند صرفاً با تکرار sudo به خودش اجازه بدهد. از کنسول سرور در پنل ارائه‌دهنده و روش بازیابی مستند همان سرویس استفاده کنید؛ اگر امکان ورود مدیریتی ندارید، از مسئول سرور برای بازگرداندن دسترسی کمک بگیرید. هیچ رمز عبور یا کلید خصوصی را در تیکت عمومی نفرستید.
جلسه مدیریتی فعلی را تا پایان آزمایش نبندید. یک پنجره جداگانه برای حسابی که در حال اصلاح آن هستید باز کنید. اگر هنگام تنظیم اشتباه کردید، وجود جلسه مدیریتی سالم راه بازگشت را حفظ می‌کند. در سرور دارای cPanel، DirectAdmin یا سیاست دسترسی سازمانی، قبل از تغییر گروه یا فایل سیاست مطمئن شوید این تغییر با روش مدیریت همان سرور سازگار است.
در مثال‌ها نام حساب آزمایشی operator است؛ آن را در همه دستورها با نام واقعی حساب خودتان جایگزین کنید. نشانه‌های $ و # در خروجی‌های نمونه، متن قابل تایپ نیستند. خروجی‌های نمونه اطلاعات یک سرور فرضی‌اند.

قدم اول: ببینید کدام نوع خطا را دریافت می‌کنید

در پنجره حساب مشکل‌دار، ابتدا این دو دستور فقط برای مشاهده هویت و گروه‌های همان نشست هستند:
کد / دستورwhoami id
whoami نام حساب فعلی را چاپ می‌کند. id شناسه کاربر و گروه‌هایی را که به این نشست تعلق دارند نشان می‌دهد. مثلاً در بخشی از خروجی فرضی ممکن است ببینید:
کد / دستورuid=1001(operator) gid=1001(operator) groups=1001(operator),27(sudo)
در این مثال نام حساب operator و یکی از گروه‌های نشست sudo است. شماره گروه‌ها ممکن است در سرور شما متفاوت باشند؛ به نام گروه و حساب دقت کنید. اگر whoami نام دیگری را نشان می‌دهد، ممکن است دستور را در جلسه اشتباه اجرا کرده باشید.
حال نوع پیام را از این جدول تشخیص دهید:
| پیام یا نشانه | معنی محتمل و اقدام بعدی | | --- | --- | | user is not in the sudoers file یا مجاز نبودن حساب | حساب یا گروهش در سیاست فعلی اجازه لازم را ندارد؛ گروه‌ها و سیاست را با دسترسی مدیریتی بررسی کنید. | | Sorry, try again پس از درخواست رمز | ممکن است رمز همان کاربر اشتباه وارد شده باشد؛ این پیام به تنهایی ثابت نمی‌کند کاربر خارج از sudoers است. | | sudo: command not found | برنامه sudo در دسترس نیست یا در مسیر فرمان پیدا نمی‌شود؛ مرحله مربوط به نبود برنامه را ببینید. | | فقط یک دستور خاص مجاز نیست | ممکن است سیاست عمداً فقط فرمان‌های مشخصی را اجازه داده باشد؛ دسترسی کامل اضافه نکنید. | | پس از چند بار تلاش، حساب موقتاً مسدود می‌شود | از تکرار رمز خودداری و گزارش احراز هویت و سیاست امنیتی همان سرور را بررسی کنید. |
وقتی sudo رمز می‌خواهد، در تنظیم متداول رمز حساب فعلی درخواست می‌شود، نه لزوماً رمز root. هنگام تایپ معمولاً هیچ ستاره‌ای روی صفحه نمی‌بینید؛ رمز را تایپ و Enter بزنید. سیاست هر سازمان ممکن است متفاوت باشد.

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

در همان حساب، این دستور نام و نسخه توزیع لینوکس را نشان می‌دهد:
کد / دستورcat /etc/os-release
در خروجی دنبال ID و VERSION_ID بگردید. در Ubuntu معمولاً گروه مدیریتی پیش‌فرض sudo است؛ در AlmaLinux و توزیع‌های خانواده RHEL معمولاً گروه wheel برای این نقش استفاده می‌شود. معمولاً مهم است: مدیر سرور می‌تواند سیاست را تغییر داده باشد و عضویت در یک گروه فقط وقتی اثر دارد که همان گروه در سیاست sudoers مجاز باشد.
اکنون، از جلسه مدیریتی مستقل، وجود حساب و گروه ذخیره‌شده آن را ببینید:
کد / دستورid operator
در این فرمان operator فقط نمونه است. خروجی نشان می‌دهد سیستم برای حساب موردنظر چه گروه‌هایی ثبت کرده است. اگر خطای «کاربر وجود ندارد» می‌گیرید، نام را با املای دقیق بررسی کنید؛ تا پیدا شدن حساب درست هیچ تغییر گروهی ندهید. مقایسه مهم این است: id بدون نام، گروه‌های نشست جاری را نشان می‌دهد؛ id operator گروه‌های حساب را از اطلاعات فعلی سیستم می‌خواند. اگر به‌تازگی حساب را به گروه اضافه کرده‌اید، این دو ممکن است تا خروج و ورود دوباره با هم فرق کنند.

اگر حساب واقعاً باید دسترسی مدیریتی کامل داشته باشد

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

Ubuntu: افزودن حساب مجاز به گروه sudo

در Ubuntu، از جلسه root یا از حساب مدیریتی دیگر، این دستور را اجرا کنید:
کد / دستورsudo usermod -aG sudo operator
اگر خود جلسه با کاربر root باز شده است، پیشوند sudo لازم نیست. usermod حساب موجود را تغییر می‌دهد؛ -G sudo گروه تکمیلی موردنظر را مشخص می‌کند و -a آن را به گروه‌های قبلی اضافه می‌کند. حذف -a می‌تواند فهرست گروه‌های تکمیلی کاربر را جایگزین کند؛ بنابراین گزینه را دقیق تایپ کنید.
این فرمان معمولاً در صورت موفقیت پیام خاصی چاپ نمی‌کند. برای بررسی ثبت گروه، اجرا کنید:
کد / دستورid operator
در خروجی باید نام sudo در فهرست گروه‌های حساب دیده شود. سپس حساب operator را کاملاً از نشست SSH خارج و دوباره وارد کنید و در نشست جدید id را بدون نام اجرا کنید. اگر sudo در فهرست گروه‌های نشست جدید است، به بخش آزمایش نهایی بروید.

AlmaLinux و خانواده RHEL: افزودن حساب مجاز به wheel

در AlmaLinux معمولاً گروه مدیریتی wheel است. در جلسه root یا حساب مدیریتی دیگر، پس از تأیید نام کاربر و سیاست سرور، اجرا کنید:
کد / دستورsudo usermod -aG wheel operator
مانند مثال قبل، در نشست root می‌توانید پیشوند sudo را حذف کنید. این دستور گروه wheel را به گروه‌های موجود کاربر اضافه می‌کند و معمولاً خروجی ندارد. سپس:
کد / دستورid operator
اگر wheel در خروجی دیده شد، از حساب کاربر خارج شوید و دوباره وصل شوید. با id بدون نام مطمئن شوید گروه در نشست تازه هم وجود دارد. اگر حساب عضو wheel است اما هنوز مجوز ندارد، به احتمال زیاد باید سیاست گروه را بررسی کنید؛ افزودن دوباره کاربر، جایگزین بررسی سیاست نیست.

عضویت درست است اما sudo هنوز رد می‌شود

ابتدا اطمینان پیدا کنید واقعاً نشست تازه باز کرده‌اید. اگر مدیر در یک پنجره کاربر را به گروه اضافه کرده اما کاربر پنجره قدیمی SSH را نگه داشته، آن نشست معمولاً گروه‌های قبل را حفظ می‌کند. یک اتصال جدید باز کنید و id را دوباره اجرا کنید.
اگر گروه در نشست تازه هم درست است، از جلسه مدیریتی مستقل وضعیت سیاست را بخوانید. در سرورهای خانواده RHEL خطی شبیه %wheel ALL=(ALL) ALL، اگر فعال و سازگار با بقیه سیاست باشد، به اعضای wheel مجوز می‌دهد. در Ubuntu معمولاً قاعده‌ای برای %sudo وجود دارد. سیاست محلی می‌تواند متفاوت یا محدودتر باشد؛ صرف دیدن نام گروه در یک فایل، بدون بررسی فایل‌های سیاست دیگر، حکم قطعی نیست.
برای بررسی نحوی فایل‌های sudoers، از جلسه مدیریتی موجود می‌توانید از این فرمان استفاده کنید:
کد / دستورsudo visudo -c
visudo -c سیاست را از نظر خطای نگارشی بررسی می‌کند و پیام وضعیت فایل‌ها را چاپ می‌کند؛ در نشست root پیشوند sudo لازم نیست. پیام parsed OK نشانه عبور از بررسی نحوی همان فایل است، اما تضمین نمی‌کند حساب شما برای هر فرمان مجوز دارد. اگر خطای نحوی یا مسیر فایل خطادار نشان داده شد، متن آن را بدون اطلاعات محرمانه ثبت کنید.
برای ویرایش سیاست، فایل اصلی را با ویرایشگر ساده و بدون کنترل نحوی دست‌کاری نکنید. از visudo یا روش مدیریت دسترسی مستند سرور استفاده کنید؛ این ابزار پیش از ذخیره نهایی، نگارش سیاست را بررسی می‌کند. اگر با قواعد sudoers آشنا نیستید، از مدیر مجاز کمک بگیرید. اضافه‌کردن ALL برای همه کاربران یا استفاده از NOPASSWD صرفاً برای رفع خطا می‌تواند دسترسی مدیریتی ناخواسته ایجاد کند.
اگر برای کاربر فقط اجرای چند فرمان لازم است، مدیر باید سیاست محدود و مشخصی برای همان کار تعریف و آزمایش کند. عضویت در گروه مدیریتی کامل، راه میان‌بُر مناسبی برای دورزدن سیاست محدود سازمان نیست.

اگر خود sudo پیدا نمی‌شود

در حسابی که خطا گرفته، این دستور را اجرا کنید:
کد / دستورcommand -v sudo
اگر مسیری مانند /usr/bin/sudo برگردد، فرمان در مسیر فعلی پیدا شده است. اگر چیزی چاپ نشود، ممکن است نصب نباشد یا مسیر جست‌وجوی نشست متفاوت باشد؛ ابتدا توزیع و تنظیمات همان سرور را بررسی کنید. نصب بسته سیستمی به دسترسی مدیریتی و مخزن معتبر نیاز دارد. اگر فقط یک حساب محدود دارید، از همان حساب با دستورهای دانلود ناشناس یا تغییر مجوز فایل اجرایی تلاش به دورزدن نکنید.
در یک سرور مدیریت‌شده ممکن است عمداً دسترسی shell یا sudo برای کاربران سرویس ارائه نشود. آن وضعیت با خرابی یک VPS شخصی یکسان نیست؛ پیش از تغییر، نوع سرویس و مسئول مدیریت آن را مشخص کنید.

آزمایش نهایی و راه برگشت

در نشست جدید همان کاربر، ابتدا فهرست اجازه‌های خودش را درخواست کنید:
کد / دستورsudo -l
این فرمان طبق سیاست محلی ممکن است رمز بخواهد و سپس فرمان‌های مجاز را نشان دهد؛ اگر پیام رد دسترسی یا خطای تنظیمات داد، خروجی را با مدیر سرور بررسی کنید. این آزمون تنظیمات را تغییر نمی‌دهد، اما اطلاعات سیاست دسترسی را برای همان کاربر نمایش می‌دهد؛ آن را در مکان عمومی منتشر نکنید.
اگر عمداً دسترسی کامل داده‌اید، برای یک آزمون ساده می‌توانید اجرا کنید:
کد / دستورsudo whoami
در حالت موفق معمولاً خروجی root است. اگر سیاست فقط فرمان‌های مشخص را مجاز کرده، شکست sudo whoami لزوماً به معنی خراب بودن آن سیاست نیست؛ فقط همان فرمان مجاز و بی‌خطرِ تعریف‌شده را طبق دستور مدیر آزمایش کنید. در پایان، دسترسی موردنیاز را با مالک سرور تأیید کنید، اتصال مدیریتی دوم را پس از موفقیت نگه دارید یا مطابق سیاست امنیتی ببندید و تغییرات انجام‌شده را ثبت کنید.
اگر به دسترسی مدیریتی و کنسول اختصاصی نیاز دارید، امکانات سرور مجازی ایران نت‌آرام را بررسی کنید. تهیه سرور جدید به‌تنهایی مجوز اشتباه حساب روی سرور فعلی را اصلاح نمی‌کند؛ ابتدا مشخص کنید مالک و مدیر همان ماشین چه کسی است.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام