كيفية تغيير كلمة مرور 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

هذه هي العملية كاملة. يوضح كل ما يلي ما قد يفشل: التحقق من عمل كلمة المرور الجديدة قبل فقدان الجلسة التي يمكنها إصلاح المشكلة، وتعيين كلمات المرور من برنامج نصي، وإجبار كلمة مرور على الانتهاء، واستعادة الوصول عندما تكون كلمة المرور مفقودة بالفعل.

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

افتح جلسة 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 هي المخرجات الوحيدة التي تعني أنه تم استبدال التجزئة في /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/ على ملفات إعداد إضافية.

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 chpasswd

That 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 -e

openssl 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.

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

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

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

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

Password change required but no TTY available.

لا يُنفّذ أي شيء بعد ذلك السطر، ولا تُبلغ المهمة إلا عن رمز خروج غير صفري.

معنى حقول تقادم كلمة المرور

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 من هذه الصفحة. القسم الجذري هو القسم الأكبر. في صورة UEFI، يوجد بجانبه قسم EFI صغير لا يحتوي على دليل /etc على الإطلاق.

ما يجب فعله عندما يتوقف SSH عن قبول كلمة مرورك

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

يعني 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 نفسه. إن تعطيل إحدى الطريقتين وترك الأخرى مفعّلة هو ما يجعل خادمًا يبدو مقصورًا على المفاتيح يستمر في قبول كلمات المرور المُدخلة.

يعني 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. ولن يُنفَّذ.