آموزش تغییر رمز عبور root در اوبونتو

نحوه تغییر رمز عبور root در VPS اوبونتو

برای تغییر رمز عبور root در VPS (سرور مجازی) خود روی اوبونتو، یک نشست SSH (پوسته امن) را با کاربری که دسترسی اجرای sudo دارد باز کنید و سپس دستور sudo passwd root را اجرا نمایید. این دستور دو بار رمز عبور جدید را از شما می‌خواهد و هرگز رمز عبور قدیمی را درخواست نمی‌کند، زیرا sudo قبلاً هویت شما را تأیید کرده است. برای تغییر رمز عبور ورود به سیستم خودتان، دستور passwd را بدون هیچ آرگومانی اجرا کنید؛ در این حالت، سیستم ابتدا رمز عبور فعلی شما را درخواست می‌کند.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

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

پیش از تغییر رمز عبور، یک نشست دوم باز کنید

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

شل‌هایی که از قبل باز هستند، حتی پس از تغییر، قفل کردن یا منقضی کردن حساب کاربری مربوطه به کار خود ادامه می‌دهند، زیرا SSH اعتبارنامه‌ها را فقط در زمان ورود بررسی می‌کند و پس از آن دوباره آن‌ها را چک نمی‌کند. استثنا در این مورد sudo است. این ابزار پس از انقضای بازه زمانی (به‌طور پیش‌فرض 15 دقیقه پس از آخرین درخواست)، رمز عبور شما را مجدداً از طریق PAM (ماژول‌های احراز هویت قابل اتصال) بررسی می‌کند. بنابراین، رمز عبور جدید در اولین باری که sudo آن را درخواست کند (نه در لحظه ورود)، به‌طور واقعی تست می‌شود.

رمز عبور جدید را در نشست دوم تست کنید، در حالی که نشست اول همچنان باز است.

تغییر رمز عبور خود با استفاده از passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully تنها خروجی است که نشان می‌دهد هش موجود در /etc/shadow جایگزین شده است. هر خروجی دیگری به این معناست که رمز عبور قدیمی همچنان باقی مانده است.

در اینجا دو خطا ممکن است رخ دهد. passwd: Authentication token manipulation error، که به دنبال آن passwd: password unchanged می‌آید، به این معناست که رمز عبور فعلی که وارد کرده‌اید اشتباه است، یا سیستم فایلی که /etc/shadow را نگه می‌دارد قابل نوشتن نیست، که این وضعیت در حالت recovery mode عادی است. You must choose a longer password. از طرف pam_unix در /etc/pam.d/common-password صادر می‌شود که بررسی‌های مربوط به طول و شباهت رمز عبور را برای کاربران عادی اعمال می‌کند.

در اکثر ایمیج‌های VPS، حساب کاربری پیش‌فرض (ubuntu، یا هر نامی که ارائه‌دهنده شما ارائه می‌دهد) هیچ رمز عبوری ندارد و فقط از SSH key استفاده می‌کند. passwd هیچ رمز عبور فعلی برای تطبیق ندارد، بنابراین نمی‌تواند از اولین اعلان (prompt) عبور کند. در عوض از sudo passwd $USER استفاده کنید؛ این دستور کار می‌کند زیرا فایل sudoers در ایمیج به آن حساب اجازه می‌دهد sudo را بدون نیاز به رمز عبور اجرا کند.

تغییر رمز عبور کاربر دیگر با sudo passwd

sudo passwd deploy

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

قفل کردن یک اقدام مجزا است. sudo passwd -l deploy یک ! در ابتدای هش ذخیره‌شده قرار می‌دهد تا هیچ رمز عبوری با آن مطابقت نداشته باشد. sudo passwd -u deploy این قفل را حذف می‌کند. وضعیت را با sudo passwd -S deploy بررسی کنید.

قفل کردن رمز عبور مانع ورود کاربر نمی‌شود. هر کلیدی در ~/.ssh/authorized_keys کاربر همچنان کار می‌کند، زیرا احراز هویت با کلید عمومی هرگز /etc/shadow را نمی‌خواند. برای متوقف کردن کامل یک حساب، تاریخ انقضای خود حساب را تنظیم کنید:

sudo usermod --expiredate 1 deploy

این دستور تاریخ انقضای حساب را به سال 1970 تغییر می‌دهد، بنابراین sshd بدون توجه به اعتبارنامه‌ای که ارائه شود، ورود را رد می‌کند. این تغییر را با sudo usermod --expiredate '' deploy لغو کنید.

از passwd -d اجتناب کنید. این دستور به جای قفل کردن، رمز عبور را خالی می‌کند و در نسخه‌های قدیمی‌تر که هنوز nullok را در پشته PAM دارند، رمز عبور خالی می‌تواند توسط هر کسی استفاده شود.

آیا کاربر root در VPS به رمز عبور نیاز دارد؟

توزیع Ubuntu به‌صورت پیش‌فرض حساب root را قفل می‌کند. در فایل /etc/shadow به‌جای هش رمز عبور، مقدار ! قرار دارد و دستور sudo passwd -S root خطی را نمایش می‌دهد که با root L شروع می‌شود. تا زمانی که رمز عبوری برای root تعیین نکنید، هیچ‌کس نمی‌تواند با رمز عبور وارد این حساب شود؛ به همین دلیل است که در ایمیج‌های سرور، یک کاربر با دسترسی sudo در اختیار شما قرار می‌گیرد. کار کردن از طریق حساب‌های کاربری با حداقل دسترسی در VPS به‌جای استفاده از root، الگوی امنیتی است که باید رعایت شود.

تعیین رمز عبور برای root تنها یک مزیت دارد: فراهم کردن راه دسترسی از طریق کنسول ارائه‌دهنده سرور. این کنسول مستقیماً به ماشین مجازی در لایه‌ای پایین‌تر از پشته شبکه متصل می‌شود، بنابراین اگر تنظیمات sshd اشتباه باشد یا یک قانون فایروال دسترسی شما را مسدود کند، همچنان کار می‌کند. اما این کار هزینه‌ای هم دارد. در منوی بازیابی GRUB، دسترسی به root shell نیازمند رمز عبور root است؛ بنابراین ابزاری که برای بازنشانی رمز عبور فراموش‌شده استفاده می‌کنید، اکنون خود پشت همان رمز عبور محافظت می‌شود.

تعیین رمز عبور برای root به معنای اجازه ورود از طریق SSH نیست. Ubuntu به‌صورت پیش‌فرض از PermitRootLogin prohibit-password استفاده می‌کند که به معنای احراز هویت فقط با کلید است. بررسی کنید سرور شما در حال حاضر از چه تنظیماتی استفاده می‌کند:

sudo sshd -T | grep -i permitrootlogin

دستور sshd -T پیکربندی نهایی را پس از اعمال تمام خطوط Include نمایش می‌دهد، بنابراین این دستور تنها راه برای مشاهده تنظیمات واقعی است، به‌ویژه زمانی که /etc/ssh/sshd_config.d/ شامل فایل‌های پیکربندی جانبی (drop-in) باشد.

تنظیم رمز عبور از طریق اسکریپت با استفاده از chpasswd

passwd ورودی را از ترمینال می‌خواند و نمی‌توان آن را از طریق اسکریپت کنترل کرد. chpasswd جفت‌های user:password را از ورودی استاندارد (stdin)، هر کدام در یک خط، می‌خواند.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

این روش کار می‌کند، اما رمز عبور را به صورت متن ساده (plaintext) در تاریخچه shell و لاگ‌های CI (یکپارچه‌سازی مداوم) شما قرار می‌دهد. در عوض، ابتدا آن را هش کنید:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 دو بار رمز عبور را بدون نمایش کاراکترها (no echo) می‌پرسد و سپس یک هش SHA-512 crypt که با $6$ شروع می‌شود را چاپ می‌کند. -e به chpasswd می‌گوید که فیلد دوم از قبل هش شده است، بنابراین همان‌طور که هست در /etc/shadow کپی می‌شود. نگهداری این هش در مخزن کد یا متغیرهای CI امن است و متن ساده رمز عبور هرگز از ماشینی که آن را تایپ کرده‌اید خارج نمی‌شود.

اوبونتو 24.04 رمزهای عبور جدید را با استفاده از yescrypt ($y$) هش می‌کند، زمانی که passwd آن‌ها را تنظیم می‌کند، در حالی که openssl passwd -6 به شما SHA-512 می‌دهد. هر دو در هنگام ورود به سیستم تأیید می‌شوند، زیرا libxcrypt هر دو فرمت را می‌خواند. ترکیب آن‌ها مشکلی ندارد و openssl passwd -6 در تمام نسخه‌های LTS اوبونتو به همین شکل رفتار می‌کند، که chpasswd -c YESCRYPT این‌طور نیست: بسته قدیمی shadow در نسخه 20.04 آن نام متد را نمی‌شناسد. این هش‌ها در ارتقای نسخه سیستم‌عامل نیز باقی می‌مانند، بنابراین انتقال یک سرور 24.04 به 26.04 شما را مجبور به بازنشانی رمز عبور هیچ کاربری نمی‌کند.

چگونه تغییر واقعی رمز عبور را بررسی کنیم؟

ابتدا متادیتای مربوطه را بررسی کنید و سپس با یک ورود به سیستم (login)، آن را اثبات نمایید.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

فیلد دوم نشان‌دهنده وضعیت است: P برای رمز عبور قابل استفاده، L برای حساب قفل‌شده، و NP برای حالتی که هیچ رمز عبوری تنظیم نشده است. تاریخ ذکر شده، زمان آخرین تغییر رمز عبور است؛ بنابراین باید تاریخ امروز را نشان دهد. اعداد پس از آن، فیلدهای مربوط به aging هستند که در ادامه توضیح داده شده‌اند.

مطمئن‌ترین تست زنده، استفاده از خود دستور sudo است. دستور sudo -k مهر زمانی کش‌شده را حذف می‌کند و sudo -v سیستم را مجبور به نمایش مجدد اعلان (prompt) می‌کند. اگر رمز عبور جدید در اینجا پذیرفته شود، یعنی PAM آن را تأیید کرده است و هیچ تغییری در نشست (session) فعلی شما رخ نداده است.

sudo -k && sudo -v

برای تست یک حساب کاربری دیگر، دستور su - deploy را از یک شل بدون دسترسی ریشه (unprivileged) اجرا کنید. دستور sudo su - deploy را اجرا نکنید، زیرا از کاربر root هرگز رمز عبور خواسته نمی‌شود و این تست هیچ چیزی را اثبات نمی‌کند. در صورت وارد کردن رمز عبور اشتباه، پیام su: Authentication failure نمایش داده می‌شود.

تست نهایی، یک ورود SSH تازه از لپ‌تاپ شماست، در حالی که نشست کاری فعلی همچنان باز است:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

پیام Permission denied (publickey). در اینجا به این معنی است که سرور هرگز احراز هویت با رمز عبور را ارائه نداده است، بنابراین هیچ تغییر رمز عبوری به شما اجازه ورود نخواهد داد. پیام Permission denied, please try again. به این معنی است که سرور احراز هویت را ارائه داده اما رمز عبوری که تایپ کرده‌اید را رد کرده است.

اجبار به تغییر رمز عبور در ورود بعدی با استفاده از chage

sudo chage -d 0 deploy

دستور -d 0 تاریخ آخرین تغییر رمز عبور را به epoch تنظیم می‌کند، بنابراین PAM رمز عبور را منقضی‌شده تلقی می‌کند. در ورود تعاملی بعدی، سیستم پیش از ارائه shell، ابتدا رمز عبور فعلی و سپس رمز عبور جدید را درخواست می‌کند. دستور sudo passwd -e deploy دقیقاً همین کار را انجام می‌دهد.

از این دستور فقط برای حساب‌هایی استفاده کنید که به‌صورت تعاملی و با رمز عبور وارد می‌شوند. انقضای رمز عبور بر ورودهای مبتنی بر کلید (key-based) نیز تأثیر می‌گذارد، زیرا sshd حتی در صورت احراز هویت با کلید، مرحله account در PAM را اجرا می‌کند. در نتیجه، یک اسکریپت ssh deploy@203.0.113.10 'systemctl restart app' با این وضعیت شکست می‌خورد و متوقف می‌شود:

Password change required but no TTY available.

پس از این خط، هیچ دستوری اجرا نمی‌شود و job فقط یک کد خروج غیر صفر (non-zero exit code) گزارش می‌دهد.

معنای فیلدهای مربوط به طول عمر رمز عبور

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

این اعداد، فیلدهای 4 تا 8 از خط مربوط به کاربر در فایل /etc/shadow هستند. حداقل روزها (chage -m) مدت زمانی است که کاربر باید پیش از تغییر مجدد رمز عبور صبر کند؛ این محدودیت مانع از آن می‌شود که کاربر بلافاصله پس از یک تغییر اجباری، دوباره به رمز عبور قبلی بازگردد. حداکثر روزها (chage -M) مدت زمانی است که رمز عبور معتبر باقی می‌ماند. روزهای هشدار (chage -W) زمانی است که سیستم هنگام ورود کاربر، نمایش هشدار را آغاز می‌کند. روزهای غیرفعال (chage -I) دورهٔ مهلت پس از انقضا است که در آن رمز عبور هنوز پذیرفته می‌شود، اما پس از آن دسترسی کاملاً قطع خواهد شد. انقضای حساب (chage -E) یک تاریخ قطعی است و مستقل از رمز عبور عمل می‌کند.

sudo chage -M 90 -W 14 deploy

این تنظیمات را تنها زمانی اعمال کنید که یک سیاست امنیتی خاص آن را الزامی کرده باشد. مؤسسه ملی فناوری و استانداردها (NIST) در ایالات متحده از سال 2017 توصیه کرده است که از انقضای روتین رمز عبور خودداری شود، زیرا این کار کاربران را به سمت استفاده از تغییرات قابل پیش‌بینی در یک رمز عبور واحد سوق می‌دهد. این مؤسسه توصیه می‌کند که تغییر رمز عبور تنها در صورت وجود شواهدی مبنی بر نفوذ (compromise) اجباری شود. استفاده از یک رمز عبور طولانی و منحصربه‌فرد در یک مدیریت‌کننده رمز عبور (password manager) به همراه احراز هویت مبتنی بر کلید در SSH، بسیار امن‌تر از چرخهٔ تعویض 90 روزه است.

در صورت فراموشی رمز عبور root چه باید کرد

اگر هر حساب کاربری روی سرور امکان اجرای sudo را داشته باشد، نیازی به بازیابی نیست: sudo passwd root یک رمز عبور جدید تنظیم می‌کند. حالت دشوار زمانی است که هیچ دسترسی لاگینی وجود نداشته باشد.

تمام مراحل زیر به کنسول ارائه‌دهنده نیاز دارند که در اکثر پنل‌ها با نام VNC (رایانش شبکه مجازی) یا کنسول سریال شناخته می‌شود. این کنسول به ماشین مجازی در لایه‌ای پایین‌تر از پشته شبکه متصل می‌شود، بنابراین تنظیمات sshd و قوانین فایروال بر آن تأثیری ندارند.

1. سرور را از طریق پنل ریبوت کنید و کنسول را زیر نظر بگیرید.
2. منوی GRUB را باز کنید. ایمیج‌های ابری معمولاً GRUB_TIMEOUT=0 را تنظیم می‌کنند، بنابراین در بوت BIOS کلید Shift را نگه دارید، یا در بوت UEFI بلافاصله پس از شروع ریبوت، کلید Esc را به‌طور مکرر فشار دهید.
3. گزینه Advanced options for Ubuntu، سپس ورودی که به (recovery mode) ختم می‌شود و در نهایت root را در منوی بازیابی انتخاب کنید.
4. ابتدا mount -o remount,rw / را اجرا کنید. حالت بازیابی، فایل‌سیستم root را فقط‌خواندنی (read-only) mount می‌کند، بنابراین بدون این دستور، passwd با خطای passwd: Authentication token manipulation error مواجه می‌شود زیرا امکان نوشتن در /etc/shadow را ندارد.
5. دستور passwd ubuntu را برای حساب کاربری مورد نظر اجرا کنید و سپس سرور را از طریق پنل ریبوت کنید.

اگر حساب root از قبل دارای رمز عبور باشد و همان رمزی است که فراموش کرده‌اید، shell بازیابی آن را درخواست می‌کند و این مسیر مسدود خواهد بود. در این صورت، ایمیج rescue ارائه‌دهنده را بوت کنید، سپس دیسک اصلی را mount کرده و رمز عبور را از داخل آن تغییر دهید.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

طرح پارتیشن‌بندی را از lsblk بخوانید و از کپی کردن /dev/vda1 از این صفحه خودداری کنید. پارتیشن root همان پارتیشن بزرگ است. در ایمیج‌های UEFI، این پارتیشن در کنار یک پارتیشن کوچک EFI قرار دارد که فاقد دایرکتوری /etc است.

وقتی SSH دیگر رمز عبور شما را نمی‌پذیرد چه باید کرد

از نشست (session) فعالی که هنوز در اختیار دارید استفاده کنید. اگر هیچ نشستی باقی نمانده است، از کنسول استفاده کنید.

Permission denied, please try again. به این معنی است که سرور احراز هویت با رمز عبور را ارائه داده اما آنچه ارسال کرده‌اید را رد کرده است. دلایل معمول، روشن بودن Caps Lock یا تفاوت چیدمان صفحه‌کلید در کنسول با چیدمانی است که هنگام تعیین رمز عبور از آن استفاده کرده‌اید.

Permission denied (publickey). به این معنی است که سرور هرگز احراز هویت با رمز عبور را ارائه نداده است. PasswordAuthentication no در جایی تنظیم شده است و در Ubuntu 22.04 و نسخه‌های بعد از آن، معمولاً در یک فایل drop-in در مسیر /etc/ssh/sshd_config.d/ قرار دارد که فایل اصلی را بازنویسی می‌کند. مقادیر مؤثر را بخوانید:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes در کنار PasswordAuthentication no همچنان اجازه عبور رمز عبور را می‌دهد، زیرا متد keyboard-interactive از همان پشته PAM استفاده می‌کند. غیرفعال کردن یکی و فعال گذاشتن دیگری، دلیلی است که سروری که به نظر می‌رسد فقط کلید می‌پذیرد، همچنان رمزهای تایپ‌شده را قبول می‌کند.

همان خط، پیامی است که هنگام رد شدن ورود با کلید نیز نمایش داده می‌شود؛ بنابراین اگر به جای رمز عبور، کلیدی ارائه می‌دادید، تنظیمات رمز عبور سرور تنها یکی از پنج خطای پشت پیام Permission denied (publickey) است و خروجی ssh -v به شما می‌گوید با کدام یک مواجه هستید.

Too many authentication failures در پیام قطع اتصال به این معنی است که کلاینت شما پیش از رسیدن به رمز عبور، چندین کلید ارائه داده و سرور به محدودیت MaxAuthTries رسیده است که به‌طور پیش‌فرض 6 است. یک متد واحد را اجبار کنید:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused روی پورتی که تا یک دقیقه پیش کار می‌کرد، معمولاً به این معنی است که fail2ban که SSH را مانیتور می‌کند، آدرس شما را پس از تلاش‌های ناموفق مکرر مسدود کرده است. قانون مسدودسازی پیش‌فرض آن، بسته را به جای نادیده گرفتن (drop)، رد (reject) می‌کند؛ به همین دلیل است که پاسخ رد، سریع‌تر از زمان انتظار (timeout) بازمی‌گردد. از طریق کنسول، sudo fail2ban-client status sshd آدرس‌های مسدودشده را لیست می‌کند و sudo fail2ban-client set sshd unbanip 203.0.113.10 آدرس شما را پاک می‌کند.

گذرواژه‌ها یک گام اولیه هستند، کلیدها وضعیت نهایی‌اند

گذرواژه‌ای که در SSH کار می‌کند، گذرواژه‌ای است که تمام اسکنرهای اینترنت فرصت حدس‌زدن آن را دارند. به احراز هویت مبتنی بر کلید مهاجرت کنید تا دیگر حدس‌زدن‌ها اهمیتی نداشته باشند. یک جفت کلید ایجاد کنید، نیمه عمومی آن را نصب کنید و پیش از تغییر هر تنظیم دیگری، در یک ترمینال دوم تأیید کنید که کلید به شما اجازه ورود می‌دهد. اصول مدیریت کلید SSH به نحوه تولید، authorized_keys و عبارات عبور (passphrases) می‌پردازد.

سپس احراز هویت با گذرواژه را غیرفعال کنید و آن را به جای اعتماد به فایلی که ویرایش کرده‌اید، با sudo sshd -T تأیید کنید. ایمن‌سازی SSH روی یک VPS سایر تنظیمات sshd که ارزش تغییر دارند را بررسی می‌کند و ده دقیقه اول روی یک VPS جدید آن‌ها را به ترتیبی که باید روی یک سرور تازه انجام شوند، فهرست می‌کند.

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

FAQ

چگونه رمز عبور root را در VPS تغییر دهم اگر رمز قبلی را نمی‌دانم؟

با کاربری که اجازه اجرای sudo را دارد وارد شوید و sudo passwd root را اجرا کنید. این دستور بدون پرسیدن رمز عبور قدیمی، رمز جدیدی تنظیم می‌کند، زیرا sudo قبلاً شما را احراز هویت کرده است. اگر هیچ حسابی در سرور اجازه اجرای sudo را ندارد، کنسول ارائه‌دهنده (provider console) را باز کنید، سیستم را در منوی بازیابی GRUB ریبوت کنید، گزینه shell با نام root را انتخاب کنید، mount -o remount,rw / را اجرا کرده و سپس passwd را وارد کنید. اگر root از قبل رمز عبور دارد و همان را فراموش کرده‌اید، shell بازیابی آن را درخواست می‌کند؛ در این صورت تنها راه باقی‌مانده، استفاده از rescue image ارائه‌دهنده است که در آن دیسک mount شده و chroot انجام می‌شود.

چرا دستور passwd خطای "Authentication token manipulation error" را نمایش می‌دهد؟

دو دلیل باعث بروز این پیام می‌شود. دلیل رایج، پاسخ اشتباه در اعلان Current password: است و خطای passwd: password unchanged در زیر آن تأیید می‌کند که چیزی نوشته نشده است. دلیل دیگر، فایل‌سیستمی است که قابلیت نوشتن ندارد؛ این همان وضعیتی است که در حالت بازیابی با آن مواجه می‌شوید، زیرا / در آنجا به صورت read-only mount شده است. دستور mount -o remount,rw / را اجرا کنید و دوباره تلاش کنید.

آیا تغییر رمز عبور لینوکس، رمز عبور sudo را هم تغییر می‌دهد؟

بله. sudo رمز عبور مستقلی ندارد. این دستور شما را از طریق PAM و در برابر همان ورودی /etc/shadow که SSH و su استفاده می‌کنند، احراز هویت می‌کند؛ بنابراین برای هر حساب تنها یک رمز عبور وجود دارد. به همین دلیل است که اولین اعلان sudo پس از تغییر رمز، آزمون اصلی است. دستور sudo -k && sudo -v را اجرا کنید تا در حالی که هنوز یک نشست فعال دارید، این اعلان را مجبور به نمایش کنید.

آیا تغییر رمز عبور باعث از کار افتادن کلیدهای SSH یا نشست‌های باز من می‌شود؟

خیر. احراز هویت با کلید عمومی (Public key authentication) هرگز /etc/shadow را نمی‌خواند، بنابراین کلیدها پس از تغییر رمز عبور، پس از passwd -l و پس از chage -d 0 همچنان کار می‌کنند. نشست‌هایی که از قبل باز هستند باز می‌مانند، زیرا SSH فقط در لحظه ورود (login) اعتبارنامه‌ها را بررسی می‌کند. تنها چیزی که در یک نشست فعال تغییر می‌کند sudo است که پس از انقضای بازه زمانی 15 دقیقه‌ای، رمز عبور جدید را درخواست می‌کند.

چگونه یک کاربر را مجبور کنم در ورود بعدی رمز عبور خود را تغییر دهد؟

دستور sudo chage -d 0 deploy یا sudo passwd -e deploy را اجرا کنید که هر دو یک کار را انجام می‌دهند. تاریخ آخرین تغییر رمز به زمان epoch منتقل می‌شود، PAM رمز عبور را منقضی‌شده تلقی می‌کند و در ورود تعاملی بعدی، کاربر باید پیش از شروع shell، رمز جدیدی تنظیم کند. این کار را برای حسابی که توسط اسکریپت‌ها از طریق SSH استفاده می‌شود انجام ندهید: در این صورت یک دستور غیرتعاملی با خطای Password change required but no TTY available. مواجه شده و هرگز اجرا نمی‌شود.