איך לשנות סיסמת root בשרת Ubuntu VPS

כיצד לשנות את סיסמת ה-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 שני והשאירו אותו מחובר. כמעט כל תקלה במדריך זה ניתנת לתיקון בתוך שתי דקות כל עוד קיים shell מאומת אחד פעיל, אך היא דורשת גישה לקונסולה ברגע שהסשן האחרון נסגר.

מעטפת (shell) שכבר פתוחה תמשיך לעבוד גם לאחר שתשנו, תנעלו או תגדירו תפוגה לחשבון שאליו היא שייכת, כיוון ש־SSH בודק הרשאות רק בזמן ההתחברות ולא בודק אותן שוב לאחר מכן. היוצא מן הכלל הוא sudo. הוא בודק מחדש את הסיסמה שלכם דרך PAM (ר"ת של pluggable authentication modules) ברגע שחותמת הזמן שלו פגה, כברירת מחדל 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, המחיל בדיקות אורך ודמיון על משתמשים רגילים.

ברוב תמונות ה-VPS, לחשבון ברירת המחדל (ubuntu, או כל שם אחר שמספקת ספקית השירות) אין סיסמה כלל, אלא רק מפתח SSH. ל-passwd אין סיסמה נוכחית להשוואה, ולכן הוא אינו יכול לעבור את ההנחיה הראשונה. השתמשו ב-sudo passwd $USER במקום זאת; פעולה זו עובדת מכיוון שקובץ ה-sudoers הייעודי בתמונה מאפשר לחשבון זה להריץ את 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. פקודה זו מגדירה סיסמה ריקה במקום סיסמה נעולה, ובגרסאות ישנות יותר שעדיין כוללות את nullok ב-PAM stack, סיסמה ריקה היא סיסמה שכל אחד יכול להשתמש בה.

האם root זקוק לסיסמה בשרת VPS?

Ubuntu מופצת כאשר חשבון ה-root נעול. הקובץ /etc/shadow מכיל ! במקום hash, והפקודה sudo passwd -S root מדפיסה שורה המתחילה ב-root L. לא ניתן להתחבר כ-root באמצעות סיסמה עד שלא תגדיר אחת, וזו הסיבה שהתמונה (image) מספקת לך משתמש בעל הרשאות sudo כברירת מחדל. עבודה לפי העיקרון של חשבונות משתמש בעלי הרשאות מינימליות ב-VPS במקום כ-root היא דפוס העבודה המומלץ.

הגדרת סיסמת root מעניקה יתרון אחד בלבד: דרך כניסה דרך ה-console של ספק השרתים. ה-console מתחבר למכונה הווירטואלית מתחת לשכבת הרשת, לכן הוא ממשיך לעבוד גם כאשר sshd מוגדר בצורה שגויה או כאשר חוק firewall חוסם גישה. עם זאת, יש לכך מחיר. ה-root shell בתפריט השחזור של 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 files).

הגדרת סיסמה מתוך סקריפט באמצעות chpasswd

passwd קורא מהטרמינל ולא ניתן להפעלה מתוך סקריפט. chpasswd קורא זוגות של user:password מהקלט הסטנדרטי, זוג אחד לכל שורה.

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

זה עובד, אך זה מכניס סיסמה בטקסט גלוי להיסטוריית ה-shell שלכם וללוגים של ה-CI (אינטגרציה רציפה). במקום זאת, בצעו לה Hash תחילה:

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

openssl passwd -6 מבקש את הסיסמה פעמיים ללא הצגת תווים על המסך, ולאחר מכן מדפיס Hash מסוג SHA-512 שמתחיל ב-$6$. -e מורה ל-chpasswd שהשדה השני כבר עבר Hash, ולכן הוא מועתק ל-/etc/shadow כפי שהוא. ה-Hash בטוח לשמירה במאגר קוד או במשתנה CI, והטקסט הגלוי לעולם לא עוזב את המכונה שבה הקלדתם אותו.

Ubuntu 24.04 מבצעת Hash לסיסמאות חדשות באמצעות yescrypt ($y$) כאשר passwd מגדיר אותן, בעוד ש-openssl passwd -6 מספק לכם SHA-512. שניהם מאומתים בעת התחברות, כיוון ש-libxcrypt קורא את שני הפורמטים. ערבוב ביניהם הוא תקין, ו-openssl passwd -6 מתנהג באותה צורה בכל גרסת Ubuntu LTS, מה ש-chpasswd -c YESCRYPT לא עושה: חבילת ה-shadow הישנה ב-20.04 אינה מכירה את שם השיטה הזה. ה-Hashes הללו שורדים גם מעבר בין גרסאות, כך ש-שדרוג שרת מ-24.04 ל-26.04 לא מחייב אתכם לאפס את הסיסמה של אף משתמש.

כיצד מוודאים שהסיסמה אכן השתנתה?

התחילו בבדיקת המטא-נתונים, ולאחר מכן אמת זאת באמצעות התחברות.

sudo passwd -S deploy

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

השדה השני מייצג את המצב: P עבור סיסמה תקינה, L עבור חשבון נעול, ו-NP עבור מצב שבו אין סיסמה כלל. התאריך מציין מתי הסיסמה שונתה לאחרונה, לכן הוא אמור להציג את התאריך של היום. המספרים המופיעים אחריו הם שדות ה-aging המוסברים בהמשך.

הבדיקה הבטוחה ביותר בזמן אמת היא הרצת sudo עצמו. הפקודה sudo -k מוחקת את חותמת הזמן השמורה ב-cache, ו-sudo -v מאלצת בקשת סיסמה חדשה. אם הסיסמה החדשה מתקבלת, המשמעות היא ש-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.

שום דבר אחרי שורה זו לא ירוץ, והמשימה תדווח רק על קוד יציאה שאינו אפס.

משמעות השדות של תקופת תוקף הסיסמה

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) הם התקופה שבה תהליך ה-login יתחיל להציג אזהרה למשתמש. ימי חוסר הפעילות (chage -I) הם תקופת החסד שלאחר פקיעת התוקף, שבסופה הסיסמה תפסיק להתקבל לחלוטין. תאריך פקיעת החשבון (chage -E) הוא תאריך סופי ומוחלט, והוא אינו תלוי בסיסמה.

sudo chage -M 90 -W 14 deploy

הגדירו זאת רק כאשר מדיניות הארגון מחייבת זאת. מאז שנת 2017, ה-NIST (המכון הלאומי לתקנים וטכנולוגיה של ארה"ב) ממליץ נגד החלפת סיסמאות שגרתית, כיוון שהדבר דוחף משתמשים ליצור וריאציות צפויות מראש של אותה סיסמה. המכון ממליץ לחייב שינוי סיסמה רק כאשר ישנן ראיות לפריצה. סיסמה ארוכה וייחודית המנוהלת בתוך מנהל סיסמאות, בשילוב עם SSH מבוסס מפתח, עדיפים על פני מחזור החלפה של 90 יום.

מה לעשות כאשר אבדה סיסמת ה-root

אם קיים חשבון כלשהו בשרת שיכול להריץ את sudo, אין צורך בשחזור: sudo passwd root מגדיר סיסמה חדשה. המקרה המורכב הוא כאשר אין אפשרות התחברות כלל.

כל הפעולות להלן דורשות גישה למסוף (console) של ספק הענן, המופיע ברוב לוחות הבקרה כ-VNC או כ-serial console. הוא מתחבר למכונה הווירטואלית מתחת לשכבת הרשת, ולכן הגדרות sshd וחוקי firewall אינם משפיעים עליו.

1. בצעו reboot לשרת מלוח הבקרה ועקבו אחר המסוף.
2. הגיעו לתפריט ה-GRUB. תמונות ענן מגדירות בדרך כלל GRUB_TIMEOUT=0, לכן החזיקו את Shift במהלך עליית BIOS, או לחצו על Esc שוב ושוב במהלך עליית UEFI, מיד עם תחילת ה-reboot.
3. בחרו ב-Advanced options for Ubuntu, לאחר מכן בערך שמסתיים ב-(recovery mode), ולבסוף ב-root בתפריט השחזור.
4. הריצו תחילה את mount -o remount,rw /. מצב השחזור מעגן (mount) את מערכת הקבצים של ה-root במצב קריאה בלבד, לכן ללא פעולה זו, passwd ייכשל עם passwd: Authentication token manipulation error כיוון שלא ניתן לכתוב ל-/etc/shadow.
5. הריצו את passwd ubuntu עבור החשבון הדרוש, ולאחר מכן בצעו reboot מלוח הבקרה.

אם ל-root כבר יש סיסמה וזו הסיסמה שאבדה, מעטפת השחזור תבקש אותה והנתיב הזה חסום. במקרה כזה, עלו מתוך תמונת ה-rescue של הספק, עגנו את הדיסק האמיתי ושנו את הסיסמה מתוכו.

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 לחוץ, או פריסת מקלדת במסוף השונה מזו שהייתה בשימוש בעת הגדרת הסיסמה.

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 חסם את הכתובת שלכם לאחר ניסיונות כושלים חוזרים. כלל החסימה כברירת מחדל דוחה את החבילה במקום להתעלם ממנה, וזו הסיבה שהסירוב חוזר במהירות במקום להמתין ל-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 שגויה נגיש רק דרך הקונסולה של ספק השרתים, וקונסולה זו דורשת שם משתמש וסיסמה. חשבון עם סיסמה חזקה ששמרתם הוא ההבדל בין תיקון של חמש דקות לבין התקנה מחדש.

FAQ

כיצד אוכל לשנות את סיסמת ה-root ב-VPS אם איני יודע את הסיסמה הישנה?

התחברו כמשתמש בעל הרשאה להריץ את sudo והריצו את sudo passwd root. פעולה זו מגדירה סיסמה חדשה ללא דרישה לסיסמה הישנה, כיוון ש-sudo כבר אימת את זהותכם. אם אין אף חשבון בשרת שיכול להריץ את sudo, פתחו את מסוף הניהול של ספק השרת, בצעו אתחול לתפריט השחזור של GRUB, בחרו בכניסה ל-root, הריצו את mount -o remount,rw /, ולאחר מכן הריצו את passwd. אם ל-root כבר יש סיסמה וזו הסיסמה שאבדה, מעטפת השחזור תבקש אותה; במקרה כזה, הדרך שנותרה היא שימוש ב-rescue image של הספק, עם הדיסק מחובר (mounted) וביצוע chroot.

מדוע הפקודה passwd מציגה את השגיאה "Authentication token manipulation error"?

שתי סיבות גורמות להודעה זו. הנפוצה שבהן היא תשובה שגויה בהנחיית ה-Current password:, כאשר השורה passwd: password unchanged מתחתיה מאשרת שלא נכתב דבר. הסיבה השנייה היא מערכת קבצים שלא ניתן לכתוב אליה, מצב שנתקלים בו במצב שחזור (recovery mode), כיוון ש-/ מחובר שם במצב קריאה בלבד (read-only). הריצו את 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. ולא תרוץ כלל.