اگر همین الان پشت سیستم نشسته‌اید و با دیدن پیام «Access denied» یا ناتوانی در ورود با کاربر root کمی عرق سرد نشسته روی پیشانی‌تان، نفس عمیق بکشید. این یکی از رایج‌ترین مشکلاتی است که تقریباً هر کسی که یک سرور مجازی (VPS) مدیریت می‌کند، حداقل یک‌بار در طول کار با آن مواجه می‌شود. خبر خوب این است که فراموشی پسورد روت، برخلاف تصور خیلی‌ها، یک فاجعه غیرقابل‌جبران نیست؛ تا وقتی که به سرور خود در سطح هاست (یعنی از طریق کنسول یا VNC ارائه‌دهنده هاستینگ) دسترسی داشته باشید، امکان بازیابی آن کاملاً وجود دارد.

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

چرا اصلاً پسورد روت فراموش می‌شود؟

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

رایج‌ترین سناریو این است که سرور را مدت طولانی راه‌اندازی کرده‌اید و دیگر نیازی به ورود مستقیم با روت نداشته‌اید، چون کارها را از طریق پنل کنترل یا کاربر دیگری انجام می‌داده‌اید؛ طبیعی است که بعد از چند ماه پسورد از یاد برود. گاهی هم پسورد در جایی ناامن (مثل یک نوت ساده در گوشی یا فایل متنی روی دسکتاپ) ذخیره شده و آن فایل یا دستگاه از دسترس خارج شده است. یک حالت دیگر که کمی نگران‌کننده‌تر است، وقتی است که پسورد بدون اطلاع شما تغییر کرده؛ این می‌تواند نتیجه یک اسکریپت خودکار خراب، یک هم‌تیمی که پسورد را عوض کرده و نگفته، یا بدتر از همه، نتیجه‌ی نفوذ یک مهاجم به سرور باشد. دقیقاً به همین دلیل است که در این مقاله فقط به «چطور پسورد را عوض کنیم» بسنده نمی‌کنیم و به شما نشان می‌دهیم بعد از بازیابی دسترسی، چطور مطمئن شوید سرورتان همچنان امن است.

پیش‌نیازهایی که قبل از شروع باید داشته باشید

روش‌هایی که در ادامه معرفی می‌شوند، همگی بر این فرض استوارند که شما به سرور خود از طریق کنسول وب (Web Console) یا VNC ارائه‌دهنده هاستینگ دسترسی دارید. این یعنی حتی اگر نتوانید از طریق SSH وارد سرور شوید، می‌توانید از پنل مدیریتی هاست (مثل پنل مدیریت VPS در سایت ارائه‌دهنده) وارد بخش کنسول شوید و انگار که مانیتور و کیبورد را مستقیم به سرور وصل کرده‌اید، عملیات را انجام دهید. اگر نمی‌دانید این گزینه در پنل شما کجاست، معمولاً زیر عنوان‌هایی مثل «Console»، «VNC Console» یا «KVM» در صفحه مدیریت سرویس شما قرار دارد؛ در صورت پیدا نکردن آن، از پشتیبانی هاستینگ‌تان بپرسید.

نکته مهم دیگر این است که این آموزش برای سرورهایی نوشته شده که از GRUB2 به‌عنوان بوت‌لودر استفاده می‌کنند، که امروزه استاندارد تقریباً همه توزیع‌های لینوکسی روی VPS است.

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

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

روش بازیابی پسورد روت به تفکیک توزیع

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

اوبونتو و دبیان (Ubuntu / Debian)

۱. از طریق پنل هاستینگ، وارد بخش کنسول یا VNC سرور شوید و سرور را ری‌استارت کنید.

۲. در همان لحظاتی که سرور در حال بوت شدن است، باید صفحه منوی GRUB ظاهر شود. اگر این منو خیلی سریع رد می‌شود، معمولاً با نگه‌داشتن کلید Shift (یا در برخی سرورهای مجازی، فشردن مکرر Esc) بلافاصله بعد از ری‌استارت می‌توانید آن را نگه دارید.

۳. گزینه اصلی بوت (معمولاً همان نسخه فعلی کرنل) را با کلیدهای جهت‌دار انتخاب کنید، اما به‌جای Enter زدن، کلید e را بزنید تا وارد حالت ویرایش شوید.

۴. در متن باز شده، دنبال خطی بگردید که با linux شروع می‌شود (معمولاً شامل عباراتی مثل ro quiet splash است). به انتهای همین خط بروید و عبارت زیر را اضافه کنید:

init=/bin/bash

۵. حالا کلید Ctrl + X یا F10 را بزنید تا سیستم با این تنظیمات موقت بوت شود. توجه داشته باشید این تغییر فقط برای همین یک بار بوت اعمال می‌شود و فایل تنظیمات اصلی GRUB دست‌نخورده باقی می‌ماند.

۶. حالا باید وارد یک شل ساده شوید، بدون نیاز به پسورد. اولین کاری که باید انجام دهید این است که پارتیشن ریشه را به‌صورت قابل‌نوشتن (read-write) مانت کنید:

mount -o remount,rw /

۷. حالا می‌توانید پسورد روت را تغییر دهید:

passwd root

پسورد جدید را دو بار وارد کنید (این پسورد هنگام تایپ نمایش داده نمی‌شود، این طبیعی است).

۸. برای اطمینان از اینکه تغییرات به‌درستی روی دیسک نوشته می‌شوند، دستور زیر را بزنید:

exec /sbin/init

اگر این دستور کار نکرد، می‌توانید به‌سادگی سرور را از طریق پنل هاستینگ Reset یا Reboot کنید. حالا سرور باید به‌صورت عادی بالا بیاید و بتوانید با پسورد جدید وارد شوید.

CentOS / AlmaLinux / Rocky Linux (نسخه‌های ۸ و ۹)

توزیع‌های خانواده RHEL کمی متفاوت عمل می‌کنند و به جای init=/bin/bash از پارامتر rd.break استفاده می‌شود.

۱. از طریق کنسول یا VNC، سرور را ری‌استارت کنید و در منوی GRUB، کلید e را روی گزینه بوت فعلی بزنید.

۲. به انتهای خطی که با linux شروع می‌شود بروید و عبارت زیر را اضافه کنید:

rd.break

۳. با Ctrl + X بوت را ادامه دهید. سیستم شما را وارد یک محیط شل اضطراری (emergency shell) می‌کند.

۴. چون در این مرحله فایل‌سیستم به‌صورت read-only مانت شده، باید آن را دوباره با دسترسی نوشتن مانت کنید:

mount -o remount,rw /sysroot

۵. حالا وارد محیط chroot شوید تا انگار مستقیم داخل سیستم اصلی هستید:

chroot /sysroot

۶. پسورد روت را تغییر دهید:

passwd root

۷. نکته‌ای که خیلی‌ها فراموش می‌کنند: در توزیع‌های مبتنی بر SELinux (مثل CentOS, RHEL, AlmaLinux, Rocky)، باید یک فایل خاص بسازید تا در بوت بعدی، برچسب‌های امنیتی SELinux برای فایل تغییر یافته (/etc/shadow) دوباره تنظیم شوند؛ در غیر این صورت ممکن است بعد از ریستارت دوباره نتوانید لاگین کنید:

touch /.autorelabel

۸. حالا با دستورات زیر از chroot خارج شده و سیستم را ری‌استارت کنید:

exit
reboot

توجه داشته باشید که فرآیند autorelabel ممکن است چند دقیقه طول بکشد و سرور کمی دیرتر از حالت عادی بالا بیاید؛ این طبیعی است و نگران نشوید.

بعد از بازیابی دسترسی، این کارها را حتماً انجام دهید

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

• پسورد را دوباره و به‌صورت نهایی تغییر دهید. پسوردی که در حالت ریکاوری تنظیم کردید را با یک پسورد قوی، طولانی و منحصربه‌فرد (ترکیبی از حروف بزرگ و کوچک، عدد و کاراکتر خاص) جایگزین کنید و آن را در یک پسورد منیجر معتبر ذخیره کنید، نه در یک فایل متنی ساده.
• سرویس SSH را ری‌استارت کنید تا مطمئن شوید تغییرات به‌درستی اعمال شده‌اند: systemctl restart sshd
• از یک ترمینال جدید (بدون بستن سشن کنسول فعلی) لاگین را تست کنید. این نکته خیلی مهم است؛ تا وقتی مطمئن نشدید ورود جدید کار می‌کند، سشن کنسول را نبندید، چون اگر مشکلی پیش بیاید باز هم به همان کنسول نیاز خواهید داشت.

آیا واقعاً فقط «فراموشی» بوده یا نشانه‌ای از نفوذ؟

اینجا می‌رسیم به بخشی که خیلی از آموزش‌های مشابه از آن رد می‌شوند، اما به نظر ما اهمیت کمتری از خود بازیابی پسورد ندارد. اگر مطمئن نیستید که چرا پسورد کار نمی‌کرده، یا حس می‌کنید رفتار سرورتان اخیراً عجیب بوده (کندی غیرمعمول، ترافیک شبکه بالا، یا فضای دیسک که بی‌دلیل پر شده)، وقتش رسیده چند بررسی امنیتی ساده انجام دهید.

کاربران سیستم را چک کنید

فایل کاربران سیستم را باز کنید و ببینید آیا کاربری آنجا هست که شما نساخته‌اید:

cat /etc/passwd

به‌خصوص دنبال کاربرانی بگردید که شماره UID آن‌ها بالای ۱۰۰۰ است (یعنی کاربر عادی محسوب می‌شوند، نه کاربر سیستمی) ولی نام آشنایی ندارند. همچنین بررسی کنید چه کسانی در گروه‌های دارای دسترسی مدیریتی هستند:

getent group sudo
getent group wheel

کلیدهای SSH مجاز را بازبینی کنید

یکی از رایج‌ترین روش‌های نفوذکنندگان برای حفظ دسترسی بعد از یک بار ورود، اضافه کردن کلید عمومی خودشان به فایل authorized_keys است. این فایل را برای کاربر root و هر کاربر دیگری که SSH روی آن فعال است چک کنید:

cat /root/.ssh/authorized_keys
cat /home/*/.ssh/authorized_keys

اگر کلیدی آنجا می‌بینید که خودتان اضافه نکرده‌اید، بلافاصله آن را حذف کنید.

تاریخچه ورودها را بررسی کنید

دستور زیر ورودهای موفق اخیر را نشان می‌دهد:

last -a

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

lastb -a

اگر IP یا زمانی می‌بینید که با الگوی استفاده معمول خودتان همخوانی ندارد (مثلاً ورود موفق در ساعتی که مطمئنید کسی از تیم شما پشت سیستم نبوده)، این یک زنگ خطر جدی است.

فایل‌های لاگ سیستم را از نظر بگذرانید

بسته به توزیع، لاگ‌های احراز هویت در یکی از این مسیرها قرار دارند:

tail -n 200 /var/log/auth.log      # اوبونتو و دبیان
tail -n 200 /var/log/secure        # CentOS, RHEL, AlmaLinux, Rocky

دنبال ورودهای مشکوک، تغییر پسورد بدون اطلاع شما، یا اضافه شدن کاربر جدید بگردید.

کران‌جاب‌ها و تسک‌های زمان‌بندی‌شده را چک کنید

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

crontab -l -u root
ls -la /etc/cron.d/
systemctl list-timers

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

پردازش‌ها و اتصالات شبکه فعال را بررسی کنید

ps aux
ss -tulnp

دنبال پردازش‌هایی بگردید که منابع زیادی مصرف می‌کنند، نام عجیبی دارند یا اصلاً نمی‌دانید از کجا آمده‌اند؛ همچنین به پورت‌های بازی که نمی‌شناسید توجه کنید.

یک اسکن با ابزارهای تخصصی انجام دهید

ابزارهایی مثل rkhunter، chkrootkit و Lynis می‌توانند نشانه‌های رایج روت‌کیت و بدافزار را روی سرور پیدا کنند:

sudo apt install rkhunter -y   # دبیان/اوبونتو
sudo rkhunter --check

این ابزارها همیشه ۱۰۰٪ دقیق نیستند و ممکن است هشدار اشتباه (false positive) هم بدهند، اما به‌عنوان یک لایه اطمینان اضافه، ارزش زمان گذاشتن را دارند.

اگر شواهد نفوذ جدی پیدا کردید، چه کنیم؟

اگر بعد از این بررسی‌ها به این نتیجه رسیدید که سرورتان واقعاً هک شده، متأسفانه صادقانه‌ترین توصیه این است که به‌جای تلاش برای «تمیزکاری» یک سرور آلوده، یک سرور جدید راه‌اندازی کنید و داده‌های سالم (نه کل ایمیج سیستم) را از یک بکاپ مطمئن و قبل از تاریخ نفوذ روی آن بازیابی کنید. پاکسازی کامل یک سیستم آلوده کار بسیار دشوار و پرریسکی است، چون هیچ‌وقت نمی‌توان صد در صد مطمئن شد که تمام رد پاهای مهاجم پاک شده است.

چطور از تکرار این اتفاق جلوگیری کنیم؟

حالا که مشکل حل شد، چند تغییر کوچک می‌تواند احتمال گرفتار شدن دوباره در این وضعیت را به‌شدت کاهش دهد:

• پسورد روت را در یک پسورد منیجر معتبر ذخیره کنید، نه در حافظه یا یک فایل ساده روی دسکتاپ.
• در صورت امکان، ورود با پسورد را برای روت کاملاً غیرفعال کنید و به‌جای آن از احراز هویت با کلید SSH استفاده کنید؛ این هم امنیت را بالا می‌برد و هم دیگر پسوردی برای فراموش کردن وجود ندارد.
• به‌جای استفاده مستقیم از کاربر root برای کارهای روزمره، یک کاربر جداگانه با دسترسی sudo بسازید. این کار هم امن‌تر است و هم ردیابی اینکه چه کسی چه تغییری داده را ساده‌تر می‌کند.
• اگر بیش از یک نفر به سرور دسترسی دارد، دسترسی‌ها را مستند کنید تا در آینده مشخص باشد چه کسی چه زمانی پسورد را تغییر داده یا آخرین بار چه کسی وارد شده است.
• به‌صورت دوره‌ای از سرور اسنپ‌شات یا بکاپ بگیرید، چه از طریق پنل ارائه‌دهنده هاستینگ و چه با ابزارهای بکاپ خودکار، تا در هر شرایطی راه بازگشت داشته باشید.

جمع‌بندی

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

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

آیا بدون دسترسی کنسول یا VNC هم می‌توان پسورد روت را بازیابی کرد؟ نه. روش‌های این مقاله همگی نیازمند دسترسی مستقیم به محیط بوت سرور هستند که فقط از طریق کنسول یا VNC ارائه‌دهنده هاستینگ در دسترس است. اگر این دسترسی را ندارید، باید از پشتیبانی هاستینگ خود درخواست کمک کنید.

آیا تغییر پسورد از طریق GRUB باعث از دست رفتن اطلاعات سرور می‌شود؟ خیر، این روش فقط پسورد را تغییر می‌دهد و هیچ داده‌ای از دیسک پاک نمی‌شود. با این حال، همیشه توصیه می‌شود پیش از هر تغییری، یک اسنپ‌شات از سرور بگیرید.

چرا باید بعد از تغییر پسورد در CentOS دستور autorelabel را اجرا کنم؟ چون SELinux برای هر فایل یک برچسب امنیتی نگه می‌دارد. وقتی فایل /etc/shadow را در محیط ریکاوری تغییر می‌دهید، این برچسب به‌درستی تنظیم نمی‌شود و ممکن است در بوت بعدی باعث مسدود شدن ورود شود؛ دستور autorelabel این برچسب‌ها را دوباره می‌سازد.

چطور بفهمم کسی غیرمجاز به سرورم دسترسی داشته؟ بررسی فایل authorized_keys، خروجی دستورات last و lastb، لاگ‌های auth.log یا secure، و لیست کران‌جاب‌ها بهترین نقطه شروع است. اگر کاربر یا کلید ناشناس، یا ورود در زمانی غیرمعمول دیدید، احتمال دسترسی غیرمجاز وجود دارد.