كيفية تغيير كلمة مرور root على VPS في Ubuntu
غيّر كلمة مرور root أو مستخدم على VPS في Ubuntu باستخدام passwd وchpasswd وchage، وتحقّق من نجاحها واستعد الوصول عند فقدان SSH أو كلمة مرور root.
كيفية تغيير كلمة مرور 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 ثانية الآن واتركها متصلة. معظم حالات الفشل في هذا الدليل يمكن إصلاحها خلال دقيقتين ما دامت هناك shell موثَّقة واحدة قيد التشغيل، بينما ستحتاج إلى الوصول إلى وحدة التحكم بعد إغلاق آخر جلسة.
تواصل shell المفتوحة بالفعل العمل بعد تغيير الحساب الذي تنتمي إليه أو قفله أو انتهاء صلاحيته، لأن SSH يتحقق من بيانات الاعتماد عند تسجيل الدخول ولا يتحقق منها مرة أخرى. الاستثناء هو sudo. إذ يعيد التحقق من كلمة المرور عبر PAM (وحدات المصادقة القابلة للتوصيل) بعد انتهاء الطابع الزمني الخاص بها، ويحدث ذلك افتراضياً بعد 15 دقيقة من آخر مطالبة. لذلك تُختبر كلمة المرور الجديدة فعلياً في المرة التالية التي يطلبها فيها sudo، وليس عند تسجيل الدخول.
اختبر كلمة المرور الجديدة في الجلسة الثانية مع إبقاء الجلسة الأولى مفتوحة.
غيّر كلمة مرور حسابك باستخدام passwd
passwdChanging password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfullypasswd: 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 بدلاً من ذلك؛ فهذا يعمل لأن ملف الإضافة الخاص بـ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 غير صحيحة أو تكون قاعدة جدار ناري خاطئة. لكنه يفرض كلفة أيضاً. تطلب صدفة root في قائمة استرداد GRUB كلمة مرور root عندما تكون له كلمة مرور. لذلك تصبح الأداة التي ستستخدمها لإعادة تعيين كلمة مرور منسية محمية بكلمة المرور نفسها.
لا يتيح تعيين كلمة مرور لـroot تسجيل دخول root عبر SSH. تأتي Ubuntu مع PermitRootLogin prohibit-password، وهذا يعني السماح بالمفاتيح فقط. تحقّق مما يستخدمه خادمك فعلياً:
sudo sshd -T | grep -i permitrootloginيطبع sshd -T الإعداد الفعّال بعد حل كل سطر Include. لذلك فهو الإجابة الدقيقة الوحيدة عندما يحتوي /etc/ssh/sshd_config.d/ على ملفات drop-in.
Set a password from a script with chpasswd
passwd reads from the terminal and cannot be driven from a script. chpasswd reads user:password pairs on standard input, one per line.
printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswdThat works, and it puts a plaintext password into your shell history and your CI (continuous integration) logs. Hash it first instead:
HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -eopenssl passwd -6 prompts for the password twice with no echo, then prints a SHA-512 crypt hash starting with $6$. -e tells chpasswd that the second field is already hashed, so it is copied into /etc/shadow as it stands. The hash is safe to keep in a repository or a CI variable, and the plaintext never leaves the machine where you typed it.
Ubuntu 24.04 hashes new passwords with yescrypt ($y$) when passwd sets them, while openssl passwd -6 gives you SHA-512. Both verify at login, because libxcrypt reads both formats. Mixing them is fine, and openssl passwd -6 behaves the same way on every Ubuntu LTS release, which chpasswd -c YESCRYPT does not: the older shadow package on 20.04 does not know that method name. Those hashes survive a release jump as well, so moving a 24.04 server up to 26.04 does not force you to reset anybody's password.
كيف تتحقق من أن كلمة المرور تغيّرت فعلاً؟
ابدأ بالبيانات الوصفية، ثم أثبت ذلك عبر تسجيل الدخول.
sudo passwd -S deploydeploy 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 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.لا يُنفّذ أي شيء بعد ذلك السطر، وتُبلغ المهمة عن رمز خروج غير صفري فقط.
ما الذي تعنيه حقول تقادم كلمة المرور
sudo chage -l deployLast 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 بعدم فرض انتهاء صلاحية كلمات المرور بشكل دوري، لأن ذلك يدفع المستخدمين إلى إنشاء تغييرات متوقعة على كلمة مرور واحدة. ويوصي المعهد بفرض التغيير عند وجود دليل على الاختراق. إن استخدام كلمة مرور طويلة وفريدة محفوظة في password manager، إلى جانب SSH القائم على المفاتيح، أفضل من دورة مدتها 90 يوماً.
ما الذي تفعله عند فقدان كلمة مرور root
إذا كان أي حساب على الخادم يستطيع تشغيل sudo، فلا حاجة إلى استعادة كلمة المرور: يعيّن sudo passwd root كلمة مرور جديدة. تكمن الحالة الصعبة في عدم وجود أي تسجيل دخول فعّال.
تحتاج كل الخطوات التالية إلى وحدة تحكم المزوّد، وتظهر في معظم لوحات التحكم باسم VNC (virtual network computing) أو وحدة تحكم تسلسلية. تتصل هذه الوحدة بالآلة الافتراضية أسفل مكدس الشبكة، لذلك لا تؤثر إعدادات sshd وقواعد الجدار الناري فيها.
- أعد تشغيل الخادم من لوحة التحكم وراقب وحدة التحكم.
- اعرض قائمة GRUB. تضبط صور السحابة عادةً
GRUB_TIMEOUT=0، لذلك اضغط باستمرار علىShiftعند الإقلاع باستخدام BIOS، أو اضغطEscبشكل متكرر عند الإقلاع باستخدام UEFI، فور بدء إعادة التشغيل. - اختر
Advanced options for Ubuntu، ثم الإدخال الذي ينتهي بـ(recovery mode)، ثمrootمن قائمة الاسترداد. - شغّل
mount -o remount,rw /أولاً. يحمّل وضع الاسترداد نظام الملفات الجذر بصلاحية القراءة فقط، ولذلك يفشلpasswdمن دون هذه الخطوة معpasswd: Authentication token manipulation errorلأنه لا يستطيع الكتابة إلى/etc/shadow. - شغّل
passwd ubuntuللحساب المطلوب، ثم أعد التشغيل من لوحة التحكم.
إذا كانت لدى root كلمة مرور بالفعل وكانت هي كلمة المرور التي فقدتها، فستطلب منك shell الاسترداد إدخالها، وينتهي هذا المسار. شغّل صورة الإنقاذ التي يوفرها المزوّد بدلاً من ذلك، ثم حمّل القرص الحقيقي وغيّر كلمة المرور من داخله.
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 من هذه الصفحة. قسم الجذر هو القسم الأكبر. في صورة UEFI، يوجد بجانبه قسم EFI صغير لا يحتوي على أي مجلد /etc على الإطلاق.
ما الذي تفعله عندما يتوقف SSH عن قبول كلمة مرورك
اعمل من الجلسة التي ما زلت متصلاً بها. إذا لم تبقَ أي جلسة، فاستخدم وحدة التحكم.
يعني Permission denied, please try again. أن الخادم عرض مصادقة كلمة المرور، ثم رفض ما أرسلته. من الأسباب المعتادة تفعيل Caps Lock، أو اختلاف تخطيط لوحة مفاتيح وحدة التحكم عن التخطيط الذي استخدمته عند تعيين كلمة المرور.
يعني Permission denied (publickey). أن الخادم لم يعرض مصادقة كلمة المرور أصلاً. تم تعيين PasswordAuthentication no في موضع ما، وفي Ubuntu 22.04 والإصدارات الأحدث يوجد عادةً في ملف إسقاط ضمن /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 حظر عنوانك بعد محاولات فاشلة متكررة. ترفض قاعدة الحظر الافتراضية الحزمة بدلاً من إسقاطها، ولذلك يصل الرفض بسرعة بدلاً من انتهاء مهلة الاتصال. من وحدة التحكم، يسرد 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، واختر إدخال shell root، ثم شغّل mount -o remount,rw / وبعد ذلك passwd. إذا كانت لدى root كلمة مرور بالفعل وكانت هي التي فقدتها، فسيطلبها shell الخاص بالاسترداد، ويكون المسار المتبقي هو استخدام صورة الإنقاذ لدى المزوّد مع تحميل القرص وتنفيذ 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 أو جلساتي المفتوحة؟
لا. لا تستخدم مصادقة المفتاح العام /etc/shadow مطلقاً، لذلك تظل المفاتيح تعمل بعد تغيير كلمة المرور، وبعد passwd -l، وبعد chage -d 0. وتبقى الجلسات المفتوحة بالفعل مفتوحة، لأن SSH يتحقق من بيانات الاعتماد عند تسجيل الدخول فقط. الشيء الوحيد الذي يتغير داخل جلسة نشطة هو sudo، إذ يطلب كلمة المرور الجديدة مرة واحدة بعد انتهاء مدة الطابع الزمني البالغة 15 دقيقة.
كيف أفرض على مستخدم تغيير كلمة مروره عند تسجيل الدخول التالي؟
شغّل sudo chage -d 0 deploy، أو sudo passwd -e deploy الذي ينفذ الإجراء نفسه. ينتقل تاريخ آخر تغيير مخزّن إلى epoch، ويتعامل PAM مع كلمة المرور على أنها منتهية الصلاحية، ويجب على تسجيل الدخول التفاعلي التالي تعيين كلمة مرور جديدة قبل بدء shell. لا تطبق ذلك على حساب تستخدمه البرامج النصية عبر SSH، لأن أمراً غير تفاعلي سيفشل عندئذٍ بالرسالة Password change required but no TTY available. ولن يُنفَّذ.