כיצד לשנות סיסמת root בשרת VPS עם Ubuntu

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

כדי לשנות את סיסמת root של ה-VPS (שרת פרטי וירטואלי) ב-Ubuntu, פתחו session של SSH (מעטפת מאובטחת) כמשתמש שיכול להריץ sudo, ולאחר מכן הריצו את sudo passwd root. הפקודה מבקשת את הסיסמה החדשה פעמיים ואינה מבקשת את הסיסמה הישנה, משום ש-sudo כבר אימת את זהותכם. כדי לשנות במקום זאת את סיסמת הכניסה שלכם, הריצו את passwd ללא ארגומנטים. במקרה זה תתבקשו תחילה להזין את הסיסמה הנוכחית.

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

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

פתחו הפעלה שנייה לפני שינוי סיסמה

פתחו עכשיו הפעלת 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 אינה ניתנת לכתיבה — זהו המצב הרגיל במצב שחזור. 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 מכיל את ! במקום hash, ו-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.

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

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

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

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

sudo -k && sudo -v

כדי לבדוק חשבון אחר, הריצו את su - deploy ממעטפת ללא הרשאות מיוחדות. אל תריצו את 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 מתייחס לסיסמה כאל סיסמה שפג תוקפה. בהתחברות האינטראקטיבית הבאה המערכת מבקשת את הסיסמה הנוכחית ולאחר מכן סיסמה חדשה, ורק אז מספקת מעטפת. 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 (virtual network computing) או כמסוף טורי. הוא מתחבר למכונה הווירטואלית מתחת לשכבת הרשת, ולכן הגדרות sshd וכללי חומת האש אינם משפיעים עליו.

1. אתחל את השרת מלוח הבקרה ועקוב אחר המסוף.
2. הצג את תפריט GRUB. בתמונות ענן בדרך כלל מוגדר GRUB_TIMEOUT=0, לכן החזק את Shift במהלך אתחול BIOS, או לחץ שוב ושוב על Esc במהלך אתחול UEFI, מיד עם תחילת האתחול.
3. בחר את Advanced options for Ubuntu, לאחר מכן את הרשומה המסתיימת ב-(recovery mode), ולבסוף את root בתפריט השחזור.
4. הפעל תחילה את mount -o remount,rw /. מצב השחזור טוען את מערכת הקבצים של root לקריאה בלבד, ולכן בלי פעולה זו 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 מוגדר במקום כלשהו, וב- 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, בחרו את רשומת המעטפת 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 או בהפעלות הפתוחות שלי?

לא. אימות באמצעות מפתח ציבורי אינו קורא את /etc/shadow, ולכן המפתחות ימשיכו לפעול לאחר שינוי סיסמה, לאחר passwd -l ולאחר chage -d 0. הפעלות שכבר פתוחות יישארו פתוחות, מכיוון ש-SSH בודק את פרטי האימות רק בעת הכניסה. הדבר היחיד שמשתנה בתוך הפעלה פעילה הוא sudo, שמבקש את הסיסמה החדשה לאחר שתוקף חותמת הזמן של 15 דקות פג.

כיצד לאלץ משתמש לשנות את הסיסמה בכניסה הבאה?

הפעילו את sudo chage -d 0 deploy או את sudo passwd -e deploy, שמבצע אותה פעולה. תאריך השינוי האחרון השמור מועבר ל-epoch, PAM מתייחס לסיסמה כאל סיסמה שפג תוקפה, והכניסה האינטראקטיבית הבאה חייבת להגדיר סיסמה חדשה לפני שהמעטפת מופעלת. אין לבצע זאת עבור חשבון שמשמש סקריפטים באמצעות SSH: פקודה לא-אינטראקטיבית תיכשל עם Password change required but no TTY available. ולא תופעל.