تغییر گذرواژه root در VPS اوبونتو

نحوه تغییر گذرواژه root در VPS دارای Ubuntu

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

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

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

پیش از تغییر گذرواژه، یک نشست دوم باز کنید

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

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

در حالی که نشست اول باز است، گذرواژهٔ جدید را در نشست دوم آزمایش کنید.

گذرواژه خود را با passwd تغییر دهید

passwd

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

passwd: password updated successfully تنها خروجی‌ای است که نشان می‌دهد hash موجود در /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 ناشی می‌شود که محدودیت‌های طول و شباهت را برای کاربران معمولی اعمال می‌کند.

در بیشتر imageهای VPS، حساب پیش‌فرض (ubuntu یا هر نامی که provider شما ارائه می‌کند) اصلاً گذرواژه ندارد و فقط از SSH key استفاده می‌کند. passwd گذرواژه فعلی برای بررسی ندارد؛ بنابراین نمی‌تواند از نخستین prompt عبور کند. به‌جای آن از sudo passwd $USER استفاده کنید؛ این روش کار می‌کند، زیرا فایل drop-in مربوط به sudoers در image به آن حساب اجازه می‌دهد sudo را بدون گذرواژه اجرا کند.

تغییر گذرواژه کاربر دیگر با sudo passwd

sudo passwd deploy

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

قفل‌کردن گذرواژه یک اقدام جداگانه است. sudo passwd -l deploy یک ! را در ابتدای hash ذخیره‌شده قرار می‌دهد؛ بنابراین هیچ گذرواژه‌ای با آن مطابقت نمی‌کند. 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 استفاده نکنید. این دستور به‌جای قفل‌کردن گذرواژه، یک گذرواژه خالی تنظیم می‌کند. در یک release قدیمی‌تر که هنوز nullok را در پشته PAM دارد، گذرواژه خالی گذرواژه‌ای است که هر کسی می‌تواند استفاده کند.

آیا root در یک VPS به گذرواژه نیاز دارد؟

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

تعیین گذرواژه برای root یک قابلیت مشخص فراهم می‌کند: راهی برای ورود از طریق کنسول provider. این کنسول مستقیماً به ماشین مجازی و زیرساخت زیرین network stack متصل می‌شود. بنابراین، حتی اگر پیکربندی sshd نادرست باشد یا یک firewall rule مشکل داشته باشد، به کار خود ادامه می‌دهد. اما این کار هزینه‌ای نیز دارد. وقتی برای root گذرواژه تعیین شده باشد، root shell در منوی بازیابی GRUB گذرواژه root را درخواست می‌کند. در نتیجه، ابزاری که برای بازنشانی یک گذرواژه فراموش‌شده به آن نیاز دارید، پشت همان گذرواژه قرار می‌گیرد.

تعیین گذرواژه برای root، امکان ورود این حساب از طریق SSH را فراهم نمی‌کند. Ubuntu با PermitRootLogin prohibit-password منتشر می‌شود؛ یعنی فقط keyها مجاز هستند. بررسی کنید سرور شما واقعاً از چه پیکربندی استفاده می‌کند:

sudo sshd -T | grep -i permitrootlogin

sshd -T پیکربندی مؤثر را پس از resolve شدن هر خط Include چاپ می‌کند. بنابراین، وقتی /etc/ssh/sshd_config.d/ فایل‌های drop-in را در خود دارد، تنها پاسخ قابل‌اعتماد است.

تنظیم گذرواژه از یک script با chpasswd

passwd ورودی را از terminal می‌خواند و نمی‌توان آن را از یک script کنترل کرد. chpasswd جفت‌های user:password را از standard input می‌خواند؛ هر جفت در یک خط.

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

این روش کار می‌کند، اما یک گذرواژه متنی را در سابقه shell و logهای CI (continuous integration) قرار می‌دهد. ابتدا آن را به hash تبدیل کنید:

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

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

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

چگونه بررسی می‌کنید که گذرواژه واقعاً تغییر کرده است؟

ابتدا فراداده را بررسی کنید، سپس با ورود به سیستم آن را تأیید کنید.

sudo passwd -S deploy

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

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

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

sudo -k && sudo -v

برای آزمایش حسابی دیگر، su - deploy را از یک shell بدون دسترسی‌های ویژه اجرا کنید. sudo su - deploy را اجرا نکنید، زیرا root هرگز برای وارد کردن گذرواژه درخواست نمی‌شود و این آزمون چیزی را ثابت نمی‌کند. گذرواژه نادرست، su: Authentication failure را چاپ می‌کند.

آزمون واقعی، ورود جدید به SSH از لپ‌تاپ شماست؛ درحالی‌که session کاری همچنان باز است:

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 دقیقاً همین کار را انجام می‌دهد.

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

Password change required but no TTY available.

هیچ دستور دیگری پس از آن خط اجرا نمی‌شود و job فقط یک کد خروجی غیرصفر گزارش می‌کند.

معنای فیلدهای انقضای گذرواژه

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 درباره انقضای دوره‌ای گذرواژه‌ها توصیه منفی ارائه کرده است؛ زیرا این کار کاربران را به استفاده از تغییرات قابل‌پیش‌بینی یک گذرواژه سوق می‌دهد. NIST توصیه می‌کند زمانی تغییر گذرواژه اجباری شود که شواهدی از نفوذ وجود داشته باشد. یک گذرواژه طولانی و منحصربه‌فرد که در 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 به‌صورت فقط‌خواندنی mount می‌شود؛ بنابراین بدون این مرحله، passwd به‌دلیل ناتوانی در نوشتن در /etc/shadow، با خطای passwd: Authentication token manipulation error شکست می‌خورد.
5. برای حساب موردنظر passwd ubuntu را اجرا کنید، سپس سرور را از پنل راه‌اندازی مجدد کنید.

اگر root از قبل گذرواژه داشته باشد و همان گذرواژه‌ای باشد که گم کرده‌اید، آن shell بازیابی گذرواژه را درخواست می‌کند و این مسیر بسته است. در عوض، ایمیج نجات ارائه‌دهنده را بوت کنید، سپس دیسک واقعی را 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 دیگر گذرواژه شما را نمی‌پذیرد

از همان نشست فعال استفاده کنید. اگر هیچ نشستی باقی نمانده است، از console استفاده کنید.

Permission denied, please try again. یعنی سرور احراز هویت با گذرواژه را ارائه کرده است، اما مقدار ارسالی شما را رد کرده است. علت‌های معمول شامل فعال بودن caps lock یا تفاوت داشتن چیدمان صفحه‌کلید console با چیدمانی است که هنگام تنظیم گذرواژه استفاده کردید.

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 استفاده می‌کند. خاموش کردن یکی و روشن گذاشتن دیگری باعث می‌شود سروری که ظاهراً فقط از کلید استفاده می‌کند، همچنان گذرواژه‌های تایپ‌شده را بپذیرد.

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

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

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

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

گذرواژه‌ای که از طریق SSH کار می‌کند، گذرواژه‌ای است که هر scanner در اینترنت می‌تواند آن را حدس بزند. به احراز هویت مبتنی بر کلید منتقل شوید تا حدس‌زدن گذرواژه دیگر اهمیتی نداشته باشد. یک جفت کلید ایجاد کنید، بخش عمومی را نصب کنید و پیش از تغییر هر چیز دیگر، در یک terminal دوم تأیید کنید که کلید شما را وارد سیستم می‌کند. مبانی مدیریت کلید SSH ایجاد کلید، authorized_keys و عبارت‌های عبور را پوشش می‌دهد.

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

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

FAQ

اگر رمز عبور root را در VPS ندانم، چگونه آن را تغییر دهم؟

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

چرا passwd پیام "Authentication token manipulation error" را نشان می‌دهد؟

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

آیا تغییر رمز عبور Linux، رمز عبور sudo را هم تغییر می‌دهد؟

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

آیا تغییر رمز عبور، کلیدهای SSH یا sessionهای باز را مختل می‌کند؟

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

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

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