كيفية تغيير كلمة مرور root في VPS على Ubuntu

كيفية تغيير كلمة مرور root لحساب VPS على Ubuntu

لتغيير كلمة مرور root لحساب VPS (خادم افتراضي خاص) على Ubuntu، افتح جلسة SSH (صدفة آمنة) باستخدام مستخدم يمكنه تشغيل sudo، ثم شغّل sudo passwd root. سيطلب منك إدخال كلمة المرور الجديدة مرتين، ولن يطلب كلمة المرور القديمة، لأن sudo أثبت هويتك مسبقاً. لتغيير كلمة مرور تسجيل دخولك أنت بدلاً من ذلك، شغّل passwd من دون وسيطات، وسيطلب منك كلمة مرورك الحالية أولاً.

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

هذه هي العملية كاملة. يوضّح كل ما يلي الحالات التي تحدث فيها المشكلات: التحقق من أن كلمة المرور الجديدة تعمل قبل فقدان الجلسة التي يمكنها إصلاح المشكلة، وتعيين كلمات المرور من script، وإبطال صلاحية كلمة مرور عمداً، واستعادة الوصول عندما تكون كلمة المرور قد فُقدت بالفعل.

افتح جلسة ثانية قبل تغيير كلمة المرور

افتح الآن جلسة SSH ثانية واتركها متصلة. يمكن إصلاح معظم الأعطال في هذا الدليل خلال دقيقتين ما دامت هناك صدفة موثَّقة واحدة لا تزال مفتوحة، بينما قد تحتاج إلى الوصول إلى وحدة التحكم بعد إغلاق آخر جلسة.

تستمر الصدفة المفتوحة بالفعل في العمل بعد تغيير الحساب الذي تنتمي إليه أو قفله أو انتهاء صلاحيته، لأن SSH يتحقق من بيانات الاعتماد عند تسجيل الدخول ولا يتحقق منها مرة أخرى. الاستثناء هو sudo. إذ يعيد التحقق من كلمة المرور عبر PAM (وحدات المصادقة القابلة للتوصيل) بعد انتهاء صلاحية بيانات الاعتماد المخزنة مؤقتاً، وذلك بعد 15 دقيقة افتراضياً في Ubuntu. لا تُحتسب هذه المهلة من آخر مطالبة، لأن sudo -v يجدّد بيانات الاعتماد المخزنة مؤقتاً من دون طلبها مرة أخرى. لذلك تُختبر كلمة المرور الجديدة فعلياً للمرة الأولى في المرة التالية التي يطلبها فيها 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 غير قابل للكتابة، وهذا هو الوضع المعتاد في وضع الاسترداد. ينتج You must choose a longer password. من pam_unix في /etc/pam.d/common-password، الذي يطبّق فحوصات الطول والتشابه على المستخدمين العاديين.

في معظم صور VPS، لا يملك الحساب الافتراضي (ubuntu، أو أي اسم يوفّره موفر الخدمة) كلمة مرور، بل يملك مفتاح SSH فقط. لا يملك passwd كلمة مرور حالية للتحقق منها، لذلك لا يمكنه تجاوز المطالبة الأولى. استخدم sudo passwd $USER بدلاً من ذلك؛ فهو يعمل لأن ملف drop-in الخاص بـ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 صالحاً، لأن المصادقة بالمفتاح العام لا تتحقق من تجزئة كلمة المرور. لإيقاف الحساب بالكامل، اجعل الحساب منتهي الصلاحية:

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 غير صحيح أو تكون قاعدة جدار ناري خاطئة. لكنه يفرض تكلفة أيضاً. تطلب قائمة استرداد root في GRUB كلمة مرور 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 من الإدخال القياسي، بمعدل زوج واحد في كل سطر.

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

يعمل ذلك، لكنه يضع كلمة المرور بنص صريح في سجل أوامر shell وسجلات CI (التكامل المستمر). أنشئ تجزئة لها أولاً بدلاً من ذلك:

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

يطالبك openssl passwd -6 بإدخال كلمة المرور مرتين من دون إظهارها، ثم يطبع تجزئة SHA-512 crypt تبدأ بـ $6$. يخبر -e الأمر chpasswd بأن الحقل الثاني مجزّأ مسبقاً، لذلك ينسخه إلى /etc/shadow كما هو. يمكنك الاحتفاظ بالتجزئة بأمان في مستودع أو في متغير CI، ولا تغادر كلمة المرور بنصها الصريح الجهاز الذي كتبتها عليه.

تجزئ Ubuntu 24.04 كلمات المرور الجديدة باستخدام yescrypt ($y$) عندما يعيّنها passwd، بينما يوفر لك openssl passwd -6 تجزئة SHA-512. يتحقق النظام من كليهما عند تسجيل الدخول، لأن libxcrypt يقرأ التنسيقين. لا مشكلة في مزجهما، ويعمل openssl passwd -6 بالطريقة نفسها في كل إصدار Ubuntu LTS بدءاً من 18.04، بخلاف chpasswd -c YESCRYPT: إذ إن حزمة shadow الأقدم في 20.04 لا تعرف اسم الطريقة هذا. Ubuntu 16.04 هو الاستثناء، لأن OpenSSL 1.0.2 فيه لا يتضمن خيار -6 على الإطلاق. تبقى هذه التجزئات صالحة أيضاً عند الانتقال بين الإصدارات، لذلك لا يفرض نقل خادم 24.04 إلى 26.04 إعادة تعيين كلمات مرور أي مستخدم.

كيف تتحقق من تغيّر كلمة المرور فعلاً؟

ابدأ بالبيانات الوصفية، ثم أثبت ذلك بتسجيل الدخول.

sudo passwd -S deploy

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

الحقل الثاني هو الحالة: P لكلمة مرور صالحة للاستخدام، وL للحساب المقفل، وNP لعدم وجود كلمة مرور إطلاقاً. يوضّح التاريخ آخر وقت تغيّرت فيه كلمة المرور، ولذلك يُفترض أن يعرض تاريخ اليوم. أما الأرقام التي تليه فهي حقول تقادم كلمة المرور الموضحة أدناه.

الاختبار المباشر الأكثر أماناً هو sudo نفسه. يتجاهل sudo -k الطابع الزمني المخزّن مؤقتاً، ويفرض sudo -v ظهور مطالبة جديدة. إذا قُبلت كلمة المرور الجديدة هناك، فقد قبلها PAM، ولم يتغير شيء في جلستك.

sudo -k && sudo -v

لاختبار حساب آخر، نفّذ su - deploy من shell غير ذي امتيازات. لا تنفّذ 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 تاريخ آخر تغيير إلى حقبة Unix، ولذلك يتعامل PAM مع كلمة المرور على أنّها منتهية الصلاحية. عند تسجيل الدخول التفاعلي التالي، يطلب النظام كلمة المرور الحالية، ثم يطلب كلمة مرور جديدة، قبل أن يفتح shell. وينفّذ sudo passwd -e deploy الإجراء نفسه تماماً.

استخدم ذلك فقط للحسابات التي تسجّل الدخول تفاعلياً باستخدام كلمة مرور. تؤثر كلمة المرور المنتهية الصلاحية أيضاً في عمليات تسجيل الدخول المستندة إلى المفاتيح، لأن sshd يشغّل مرحلة الحساب في PAM حتى عندما يكون المفتاح هو وسيلة المصادقة. عندئذ يفشل ssh deploy@203.0.113.10 'systemctl restart app' البرمجي بهذه الرسالة قبل تنفيذ الأمر:

Password change required but no TTY available.

لا يُنفَّذ الأمر البعيد، ويخرج ssh برمز غير صفري. ما لم يوقف السكربت المستدعي التنفيذ عند حدوث الأخطاء باستخدام set -e أو فحص صريح، تستمر الأسطر التالية في التنفيذ، وقد تنتهي المهمة كما لو أنّ إعادة التشغيل قد حدثت.

ما الذي تعنيه حقول تقادم كلمة المرور

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 بعدم فرض انتهاء صلاحية كلمات المرور بشكل دوري، لأن ذلك يدفع المستخدمين إلى اختيار تغييرات متوقعة على كلمة المرور نفسها. كما توصي بفرض التغيير عند وجود دليل على اختراقها. وتوفر كلمة مرور طويلة وفريدة محفوظة في مدير كلمات المرور، إلى جانب SSH المستند إلى المفاتيح، حماية أفضل من دورة تغيير مدتها 90 يوماً.

ما الذي تفعله عند فقدان كلمة مرور root

إذا كان بإمكان أي حساب على الخادم تشغيل sudo، فلا شيء يحتاج إلى استرداد: يعيّن sudo passwd root كلمة مرور جديدة. تكمن الحالة الصعبة في عدم وجود أي تسجيل دخول عامل.

تحتاج كل الخطوات التالية إلى وحدة تحكم المزوّد، وتظهر في معظم لوحات التحكم باسم VNC (الحوسبة الشبكية الافتراضية) أو وحدة تحكم تسلسلية. تتصل هذه الوحدة بالآلة الافتراضية أسفل طبقة الشبكة، لذلك لا تؤثر إعدادات sshd وقواعد جدار الحماية فيها.

1. أعد تشغيل الخادم من لوحة التحكم وراقب وحدة التحكم.
2. اعرض قائمة GRUB. تضبط صور السحابة عادةً GRUB_TIMEOUT=0، لذلك اضغط باستمرار على Shift عند الإقلاع عبر BIOS، أو اضغط على Esc بشكل متكرر عند الإقلاع عبر UEFI، فور بدء إعادة التشغيل.
3. اختر Advanced options for Ubuntu، ثم الإدخال المنتهي بـ(recovery mode)، ثم root في قائمة الاسترداد.
4. شغّل mount -o remount,rw / أولاً. يحمّل وضع الاسترداد نظام الملفات الجذري للقراءة فقط، ولذلك يفشل passwd من دون ذلك مع passwd: Authentication token manipulation error لأنه لا يستطيع الكتابة إلى /etc/shadow.
5. شغّل passwd ubuntu للحساب المطلوب، ثم أعد التشغيل من لوحة التحكم.

إذا كانت لدى root كلمة مرور بالفعل وكانت هي التي فقدتها، فستطلب منك جلسة الاسترداد هذه إدخالها، ويُغلق هذا المسار. أقلِع من صورة الإنقاذ الخاصة بالمزوّد بدلاً من ذلك، ثم حمّل القرص الحقيقي وغيّر كلمة المرور داخله.

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 عن قبول كلمة المرور

اعمل من الجلسة التي ما زلت تملكها. إذا لم تبقَ أي جلسة، فاستخدم وحدة التحكم.

يعني Permission denied, please try again. أن الخادم عرض مصادقة كلمة المرور، ثم رفض ما أرسلته. السبب المعتاد هو تفعيل Caps Lock، أو اختلاف تخطيط لوحة مفاتيح وحدة التحكم عن التخطيط الذي استخدمته عند تعيين كلمة المرور.

يعني Permission denied (publickey). أن الخادم لم يعرض مصادقة كلمة المرور مطلقاً، ولذلك تكون القيمة الفعلية هي PasswordAuthentication no. يمكن أن يوجد no في الملف الرئيسي أو في ملف drop-in، لذلك افحص كليهما. يقرأ sshd الملفات الموجودة ضمن /etc/ssh/sshd_config.d/ في بداية تحميل الإعدادات، ويحتفظ بأول قيمة يعثر عليها لكل كلمة مفتاحية، ولذلك يتجاوز ملف drop-in قيمة /etc/ssh/sshd_config. غالباً ما تعمل القاعدة نفسها بالعكس على خوادم Ubuntu 24.04 المثبتة من صورة ISO مع تفعيل SSH: يترك برنامج التثبيت ملف drop-in من cloud-init باسم 50-cloud-init.conf، ويضبط فيه PasswordAuthentication yes، ثم يتم تجاهل أي no يُضاف إلى الملف الرئيسي. اقرأ القيم الفعلية:

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 وحظر عنوانك بعد إخفاقات متكررة. ترفض قاعدة الحظر الافتراضية الحزمة بدلاً من إسقاطها، ولذلك يعود الرفض بسرعة بدلاً من انتهاء مهلة الاتصال. من وحدة التحكم، يعرض sudo fail2ban-client status sshd العناوين المحظورة، بينما يلغي sudo fail2ban-client set sshd unbanip 203.0.113.10 حظر عنوانك.

كلمات المرور مرحلة انتقالية، والمفاتيح هي الحالة النهائية

كلمة المرور التي تعمل عبر SSH هي كلمة مرور يمكن لكل أداة فحص على الإنترنت محاولة تخمينها. انتقل إلى المصادقة المعتمدة على المفاتيح، وعندها لن تعود محاولات التخمين مهمة. أنشئ زوج مفاتيح، وثبّت الجزء العام، وتأكد من أن المفتاح يسجّل دخولك من طرفية ثانية قبل تغيير أي شيء آخر. يشرح أساسيات إدارة مفاتيح SSH إنشاء المفاتيح، وauthorized_keys وعبارات المرور.

بعد ذلك عطّل مصادقة كلمات المرور، وتأكد من ذلك باستخدام sudo sshd -T بدلاً من الوثوق بالملف الذي عدّلته. يشرح تأمين SSH على VPS بقية إعدادات sshd التي تستحق التغيير، بينما يرتّب الدقائق العشر الأولى على VPS جديد الخطوات التي ينبغي تنفيذها على خادم جديد.

احتفظ بكلمة مرور واحدة بعد ذلك. لا يمكن الوصول إلى خادم يعتمد على المفاتيح فقط إذا كان إعداد sshd معطلاً إلا عبر وحدة تحكم المزوّد، وهذه الوحدة تطلب اسم مستخدم وكلمة مرور. الحساب الذي تملك كلمة مرور قوية له وتحتفظ بها هو ما يحدد الفرق بين إصلاح يستغرق خمس دقائق وإعادة تثبيت النظام.

FAQ

كيف أغيّر كلمة مرور root على VPS إذا كنت لا أعرف القديمة؟

سجّل الدخول باستخدام مستخدم يمكنه تشغيل sudo، ثم شغّل sudo passwd root. يعيّن هذا الأمر كلمة مرور جديدة من دون طلب القديمة، لأن sudo سبق أن صادق على هويتك. إذا لم يكن في الخادم أي حساب يمكنه تشغيل sudo، فافتح وحدة تحكم مزوّد الخدمة، وأعد التشغيل إلى قائمة استرداد GRUB، واختر إدخال الصدفة root، ثم شغّل mount -o remount,rw /، وبعد ذلك شغّل passwd. إذا كانت لـroot كلمة مرور بالفعل وكانت هي التي فقدتها، فستطلب منك صدفة الاسترداد إدخالها. في هذه الحالة، يكون المسار المتبقي هو استخدام صورة الإنقاذ الخاصة بمزوّد الخدمة، مع تحميل القرص وتنفيذ chroot عليه.

لماذا يعرض passwd الرسالة "Authentication token manipulation error"؟

يسبب هذه الرسالة أمران. السبب الشائع هو إدخال إجابة خاطئة في مطالبة Current password:، ويؤكد السطر passwd: password unchanged الموجود أسفلها أنه لم تُكتب أي تغييرات. والسبب الآخر هو أن نظام الملفات غير قابل للكتابة. يحدث ذلك في وضع الاسترداد لأن / يكون محمّلاً للقراءة فقط هناك. شغّل mount -o remount,rw / وحاول مرة أخرى.

هل يؤدي تغيير كلمة مرور Linux إلى تغيير كلمة مرور sudo أيضاً؟

نعم. لا يملك sudo كلمة مرور خاصة به. فهو يصادق على هويتك عبر PAM مقابل إدخال /etc/shadow نفسه الذي يستخدمه SSH وsu، ولذلك توجد كلمة مرور واحدة لكل حساب. ولهذا أيضاً تكون مطالبة sudo الأولى بعد التغيير هي الاختبار الفعلي. شغّل sudo -k && sudo -v لفرض ظهور هذه المطالبة ما دامت لديك جلسة عاملة.

هل يؤدي تغيير كلمة المرور إلى تعطيل مفاتيح SSH أو الجلسات المفتوحة؟

لا يؤدي تغيير كلمة المرور أو passwd -l إلى ذلك. لا يتحقق الاستيثاق بالمفتاح العام من تجزئة كلمة المرور، لذلك تستمر المفاتيح في العمل بعد أيٍّ منهما. يختلف chage -d 0 عن ذلك: يواصل sshd تنفيذ فحوصات حساب PAM بعد تسجيل الدخول بالمفتاح، وتقرأ هذه الفحوصات حقول تقادم كلمة المرور في /etc/shadow. لذلك تجعل كلمة المرور المنتهية تسجيل الدخول بالمفتاح يطلب كلمة مرور جديدة، كما تجعل أوامر SSH النصية تفشل. تبقى الجلسات المفتوحة بالفعل مفتوحة، لأن SSH يتحقق من بيانات الاعتماد عند تسجيل الدخول فقط. والشيء الوحيد الذي يتغير داخل جلسة حية هو sudo، إذ يطلب كلمة المرور الجديدة بعد انتهاء الطابع الزمني البالغ 15 دقيقة.

كيف أُجبر مستخدماً على تغيير كلمة المرور عند تسجيل الدخول التالي؟

شغّل sudo chage -d 0 deploy، أو sudo passwd -e deploy، فالأمران ينفذان الإجراء نفسه. ينتقل تاريخ آخر تغيير مخزّن إلى epoch، ويتعامل PAM مع كلمة المرور على أنها منتهية، ويجب على تسجيل الدخول التفاعلي التالي تعيين كلمة مرور جديدة قبل بدء الصدفة. لا تفعل ذلك لحساب تستخدمه النصوص البرمجية عبر SSH، لأن الأمر غير التفاعلي سيفشل عند ظهور Password change required but no TTY available. ولن يُنفَّذ.