سرور اختصاصی
دسته بندی:
عوض کردن پسورد سرور اختصاصی از طریق کنسول vSphere
برای عوض کردن پسورد سرور اختصاصی از طریق vSphere باید از کنسول ماشین در vSphere Client استفاده کنید؛ کنسول دقیقاً معادل نشستن پشت کیبورد و مانیتور خود سرور است. در لینوکس سرور را با تغییر موقت پارامترهای بوت در GRUB به حالت تککاربره یا rescue میبرید و دستور passwd را اجرا میکنید، و در ویندوز یا از یک حساب Administrator دیگر پسورد را ریست میکنید یا از محیط ریکاوری. هر دو مسیر نیاز به ریاستارت دارند، پس قطعی سرویس را از قبل برنامهریزی کنید.
اول مطمئن شوید که راه سادهتری وجود ندارد
کنسول آخرین راه است، نه اولین. قبل از ریاستارت این گزینهها را بررسی کنید، چون هیچکدام قطعی ندارند:
- اگر با کلید SSH یا با کاربری در گروه
sudoیاwheelهنوز وارد میشوید، همانsudo passwd rootکافی است. - در ویندوز، اگر حساب Administrator دیگری فعال دارید، با آن RDP بگیرید و پسورد حساب قفلشده را عوض کنید.
- روی سرویسهای مدیریتشده مانند سرور مجازی ایران مدیریتشده، این کارها معمولاً بر عهده سرویسدهنده است.
رسیدن به کنسول در vSphere
با vSphere Client به vCenter یا مستقیم به هاست ESXi متعلق به VMware وصل شوید، ماشین موردنظر را انتخاب کنید و Launch Web Console یا Launch Remote Console را بزنید. از این لحظه هر چیزی که تایپ میکنید مستقیم به سرور میرسد، حتی وقتی شبکه یا سرویس SSH از کار افتاده باشد. اگر هنوز ESXi را تهیه نکردهاید یا درگیر مسئله لایسنس آن هستید، وضعیت امروز نسخه رایگان را در سریال VMware ESXi بررسی کردهایم.
اگر سرور اختصاصی شما فیزیکی است و هایپروایزر ندارد، معادل همین کنسول از طریق کارت مدیریتی مادربرد و KVM over IP در دسترس است؛ بسته به سازنده iDRAC، iLO یا IPMI نامیده میشود. فعال بودن این دسترسی به سرویسدهنده و مدل سرور بستگی دارد.
یک نکته عملی: در کنسول تحت وب چیدمان کیبورد ممکن است فرق کند و در تایپ سریع بعضی کلیدها جا میافتند. پس ابتدا یک پسورد ساده اما موقت بگذارید و بلافاصله بعد از ورود از راه دور، پسورد نهایی و قوی را جایگزین کنید. این پسورد موقت را روی سروری که ورود با پسورد در آن باز است حتی چند دقیقه هم رها نکنید.
دادن دسترسی کنسول و روشن و خاموش کردن به کاربر VPS
خیلی وقتها مشکل اصلی این نیست که پسورد را چطور عوض کنیم، بلکه این است که کاربر اصلاً به کنسول دسترسی ندارد. اگر شما مدیر vCenter یا هاست ESXi هستید، میتوانید یک حساب با دسترسی محدود بسازید که فقط روی همان یک ماشین مجازی کنسول باز کند و آن را روشن، خاموش و ریاستارت کند، بدون اینکه ماشینهای دیگر یا تنظیمات هاست را ببیند. چیزی که در آموزشهای قدیمی «دادن پنل به کاربر VPS» نامیده میشد، در عمل همین ساخت کاربر و اختصاص نقش (Role) است.
قبل از مسیرها یک هشدار درباره منابع قدیمی: مسیرهای منویی مثل View > Inventory و View > Administration > Roles مربوط به کلاینت دسکتاپ ویندوزی vSphere (نسخه C#) هستند که از vSphere 6.5 کنار گذاشته شد؛ vSphere Web Client مبتنی بر Flash هم در vSphere 7 حذف شد. امروز یا با vSphere Client تحت وب به vCenter وصل میشوید، یا با ESXi Host Client به نشانی https://ESXi-IP/ui مستقیم به هاست.
در vCenter
سه مرحله دارد: ساخت کاربر، ساخت نقش، و اختصاص مجوز روی خود ماشین.
- ساخت کاربر: از Menu وارد Administration شوید، در بخش Single Sign On سراغ Users and Groups بروید، دامنه
vsphere.localرا انتخاب کنید و کاربر جدید را با پسورد اضافه کنید. اگر Active Directory به vCenter وصل است، بهجای کاربر محلی از همان حساب دامنه استفاده کنید. - ساخت نقش: در همان Administration سراغ Access Control و Roles بروید و یک نقش تازه بسازید. چیزی که برای این سناریو لازم است زیرمجموعه Virtual machine و بخش Interaction است: مجوز Console interaction برای باز کردن کنسول، و Power On و Power Off و Reset و Suspend برای کنترل برق ماشین. اگر کاربر باید خودش ISO وصل کند، Configure CD media و Device connection را هم اضافه کنید. نقشهای نمونهای مثل Virtual Machine Power User (sample) هم آماده هستند؛ میتوانید یکی را کپی کنید و موارد اضافه را بردارید.
- اختصاص مجوز: ماشین مجازی را در فهرست انتخاب کنید، به تب Permissions بروید و کاربر را با آن نقش اضافه کنید. مجوز را روی خود ماشین بدهید، نه روی دیتاسنتر یا هاست؛ در vSphere کاربر فقط اشیائی را میبیند که روی آنها مجوز دارد، پس با این کار مشتری در فهرست فقط ماشین خودش را میبیند.
برای کاربر بعدی لازم نیست نقش را دوباره بسازید؛ فقط کاربر را اضافه کنید و همان نقش را روی ماشین او اختصاص دهید.
روی هاست ESXi و بدون vCenter
- در Host Client از Manage به Security & users و سپس Users بروید و Add user را بزنید. برخلاف کلاینت قدیمی، مرحله انتخاب گروه (مثلاً گروه users) دیگر وجود ندارد؛ کاربر ساخته میشود و مجوز را جداگانه میدهید.
- سپس در فهرست Virtual Machines ماشین موردنظر را انتخاب کنید و از منوی Actions گزینه Permissions را بزنید و کاربر را با نقش دلخواه اضافه کنید.
- یک محدودیت مهم: روی هاست تنها معمولاً فقط نقشهای پیشفرض Administrator و Read-only و No access در دسترساند و نقشی که دقیقاً محدود به کنسول و برق ماشین باشد نمیسازید. دادن نقش Administrator هاست به مشتری یعنی کنترل کامل کل هاست و همه ماشینهای روی آن؛ این کار را نکنید. تفکیک واقعی مشتریها به vCenter نیاز دارد.
یک نکته شبکهای هم هست: کنسول در نهایت به خود هاست ESXi وصل میشود، نه فقط به vCenter. اگر کاربر به هاست مسیر شبکهای ندارد یا فایروال جلوی آن را گرفته است، کنسول باز نمیشود، حتی وقتی مجوزها درست تنظیم شده باشند.
ریست پسورد root در لینوکس
اگر سرور یک ماشین مجازی است، اول یک Snapshot بگیرید تا در صورت اشتباه بتوانید برگردید. Snapshot جایگزین بکاپ نیست و نگه داشتن طولانیمدت آن به کارایی و فضای دیسک آسیب میزند؛ بعد از پایان کار حذفش کنید.
روش init=/bin/bash
روی دبیان، اوبونتو و توزیعهایی که SELinux فعال ندارند:
- سرور را ریاستارت کنید و در منوی GRUB روی ورودی کرنل کلید
eرا بزنید. اگر منو نمایش داده نمیشود، هنگام بوت Shift یا Esc را نگه دارید. - خط شروعشونده با
linuxرا پیدا کنید و در انتهایشrw init=/bin/bashرا اضافه کنید. وجودrwمهم است، وگرنه فایلسیستم فقطخواندنی بالا میآید. - با
Ctrl+XیاF10بوت کنید تا یک شل root بدون پرسیدن پسورد بگیرید. - اگر خطای read-only گرفتید،
mount -o remount,rw /را اجرا کنید. passwd rootرا بزنید و در پایانsyncو سپسexec /sbin/initرا اجرا کنید تا بوت عادی ادامه پیدا کند. اگر این دستور جواب نداد یا شل قفل شد، پیش از هر ریاستارت اجباری حتماًmount -o remount,ro /را بزنید تا نوشتهها روی دیسک بنشیند و فایلسیستم آسیب نبیند.
روش rd.break در خانواده RHEL
روی RHEL، CentOS، Rocky و AlmaLinux بهخاطر SELinux مسیر کمی فرق دارد:
- در منوی GRUB کلید
eرا بزنید، در انتهای خطlinuxعبارتrd.breakرا اضافه کنید و باCtrl+Xبوت کنید. - در پرامپت switch_root دستور
mount -o remount,rw /sysrootو سپسchroot /sysrootو بعدpasswd rootرا اجرا کنید. - کاربرد همین دستور
passwdدر حالت عادی و برای کاربران غیر روت را در تغییر رمز عبور سرور لینوکس اوبونتو توضیح دادهایم. - دستور
touch /.autorelabelرا فراموش نکنید. بدون آن برچسب SELinux فایل shadow اشتباه میماند و باز هم نمیتوانید وارد شوید. - دو بار
exitبزنید. بوت بعدی بهخاطر برچسبگذاری دوباره فایلسیستم طولانیتر است؛ وسط کار سرور را خاموش نکنید.
وقتی ویرایش GRUB ممکن نیست
اگر منوی GRUB با پسورد محافظت شده باشد، باید از یک ISO نجات بوت کنید. در vSphere از Edit Settings سراغ CD/DVD Drive بروید، ISO را از دیتااستور انتخاب کنید، تیک Connect At Power On را بزنید و اولویت بوت را به درایو نوری بدهید. اگر روی یک VPS هستید و خودتان به هاست ESXi و دیتااستور دسترسی ندارید، اتصال ISO یا بالا آوردن ماشین در حالت rescue را باید از سرویسدهنده بخواهید. در محیط زنده پارتیشن ریشه را mount کنید، /proc و /sys و /dev را با mount --bind داخلش بیاورید، chroot کنید و passwd را بزنید. اگر دیسک با LUKS رمزنگاری شده و عبارت عبور را ندارید، تنها گزینه بازیابی از بکاپ است.
معادل همین کار در ویندوز سرور
اگر با یک حساب Administrator دیگر وارد میشوید، سادهترین راه اجرای compmgmt.msc و رفتن به Local Users and Groups سپس Users است؛ روی کاربر راست کلیک کنید و Set Password را بزنید. همین کار با یک خط در Command Prompt با دسترسی Administrator هم انجام میشود:
net user Administrator *
ستاره باعث میشود ویندوز پسورد را بهصورت مخفی بپرسد. اگر پسورد را مستقیم در همان خط بنویسید، متن آن در تاریخچه فرمان و در لاگها باقی میماند. پسورد جدید باید سیاست پیچیدگی سرور یا دامنه را رعایت کند، وگرنه دستور با خطا برمیگردد.
هشدار ویندوز موقع Set Password جدی است: با ریست پسورد یک حساب توسط حساب دیگر، فایلهای رمزنگاریشده با EFS، گواهیهای شخصی و پسوردهای ذخیرهشده در Credential Manager آن کاربر از دسترس خارج میشوند. اگر خود کاربر پسورد را با Ctrl+Alt+Del عوض کند، این اتفاق نمیافتد.
اگر هیچ حساب ادمینی در دسترس نیست، از کنسول vSphere ایمیج نصب ویندوز را متصل کنید، سیستم را در Windows Recovery Environment بالا بیاورید و پسورد را آفلاین ریست کنید؛ روش شناختهشده آن جایگزینی موقت یکی از ابزارهای دسترسپذیری صفحه ورود با cmd.exe است. سه نکته: با BitLocker فعال و بدون کلید بازیابی راه به جایی نمیبرید؛ روی Domain Controller حساب محلی وجود ندارد و این روش پاسخ نمیدهد؛ و هر فایلی که جابهجا کردهاید باید بلافاصله بعد از ورود به حالت اول برگردد، وگرنه یک در پشتی دائمی روی سرور میماند.
قطعی سرویس را دستکم نگیرید
روشهای کنسولی بالا به ریاستارت نیاز دارند و در تمام مدت بوت سرویسهای شما پایین هستند. چند نکته که ریسک را کم میکند:
- کار را در بازه کمترافیک انجام دهید و از قبل به تیم و کاربران اطلاع بدهید.
- در صورت نصب بودن VMware Tools، برای ریاستارت گزینه Restart Guest OS را به Power Off ترجیح دهید تا فایلسیستم سالم بسته شود.
- پیش از شروع مطمئن شوید بکاپ سالم و قابل بازگردانی دارید.
بعد از تغییر پسورد چه کنیم
پسورد جدید را در یک مدیر رمز عبور ذخیره کنید و اگر قرار است با root از راه دور وارد شوید، مقدار PermitRootLogin را در /etc/ssh/sshd_config بررسی کنید؛ در بسیاری از توزیعها ورود root با پسورد پیشفرض بسته است. حواستان به فایلهای /etc/ssh/sshd_config.d/*.conf هم باشد؛ در اوبونتو ۲۲.۰۴ به بعد و RHEL 9 این فایلها با دستور Include خوانده میشوند و میتوانند مقداری را که در فایل اصلی گذاشتهاید بیاثر کنند. اگر ناچار شدید موقتاً PermitRootLogin yes بگذارید، بعد از پایان کار حتماً به prohibit-password برگردانید.
در ویرایش این فایل عجله نکنید، چون یک اشتباه کوچک میتواند شما را کامل بیرون بگذارد. ترتیب امن این است: نشست SSH فعلی را باز نگه دارید، فایل را ویرایش کنید، با sshd -t صحت آن را بسنجید و فقط اگر خروجی خالی بود سرویس را ریاستارت کنید. نام سرویس در همه توزیعها یکی نیست: روی دبیان و اوبونتو systemctl restart ssh و روی RHEL و CentOS و Rocky و AlmaLinux systemctl restart sshd. بعد از ریاستارت با یک ترمینال دوم ورود را تست کنید و تا وقتی ورود تازه موفق نشده، نشست قدیمی را نبندید؛ اگر ورود قطع شد، همان کنسول vSphere راه برگشت شماست. بهتر است بهجای پسورد از کلید SSH استفاده کنید تا دفعه بعد به این مسیر نیفتید.
اگر برای کاربری هم دسترسی کنسول در vSphere ساختهاید، همانجا هم بازبینی کنید: مجوزهای موقتی را بعد از پایان کار بردارید و حسابهای vCenter یا ESXi که دیگر استفاده نمیشوند را غیرفعال کنید.
یک نکته امنیتی را هم نادیده نگیرید: اگر پسورد بدون دلیل مشخص کار نمیکرد، احتمال دستکاری هست. لاگهای ورود، فایل authorized_keys کاربران، کرونجابها و کاربران تازهساختهشده را بررسی کنید. اگر مطمئن نیستید، سپردن کار به خدمات پشتیبانی سرور منطقیتر از آزمون و خطا روی سرور تولیدی است.
