שינוי סיסמת 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 דקות לאחר ה-prompt האחרון. לכן, הסיסמה החדשה תעבור את המבחן האמיתי הראשון שלה בפעם הבאה ש-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 מוסיפה ! לפני ה-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, מה שאומר שרק מפתחות (keys) מאושרים. בדוק מה השרת שלך משתמש בו בפועל:

sudo sshd -T | grep -i permitrootlogin

הפקודה sshd -T מדפיסה את התצורה האפקטיבית לאחר שכל שורת Include מיושמת, ולכן זו התשובה האמינה היחידה כאשר /etc/ssh/sshd_config.d/ מכיל קובצי תצורה נוספים.

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

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

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

echo "username:password" | chpasswd

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

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

mkpasswd -m sha-512
echo "username:hashed_password" | chpasswd -e

הפקודה openssl passwd -6 מבקשת את הסיסמה פעמיים ללא הצגת תווים על המסך, ולאחר מכן מדפיסה גיבוב SHA-512 שמתחיל ב-$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 אינה מכירה את שם השיטה הזה. גיבובים אלו שורדים גם מעבר בין גרסאות הפצה, כך ש-שדרוג שרת 24.04 ל-26.04 לא מחייב אתכם לאפס את הסיסמה של אף משתמש.

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

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

sudo passwd -S deploy

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

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

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

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

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

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

אותה שורה היא גם מה שמוצג כאשר התחברות עם מפתח נדחית, לכן אם ניסיתם להשתמש במפתח ולא בסיסמה, הגדרת הסיסמה של השרת היא רק אחת מתוך חמש התקלות שמאחורי 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 חסם את הכתובת שלכם לאחר ניסיונות כושלים חוזרים. חוק החסימה כברירת מחדל דוחה את החבילה במקום להתעלם ממנה, וזו הסיבה שהסירוב חוזר במהירות במקום להמתין עד ל-timeout. מתוך ה-console, הפקודה 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 shell, הריצו את mount -o remount,rw /, ולאחר מכן הריצו את passwd. אם ל-root כבר יש סיסמה וזו הסיסמה שאבדה, ה-shell של השחזור יבקש אותה; במקרה כזה, הדרך שנותרה היא שימוש ב-rescue image של הספק, עם ה-disk מחובר (mounted) וביצוע chroot.

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

שתי סיבות גורמות להודעה זו. הנפוצה שבהן היא תשובה שגויה בהנחיית ה-Current password:, ושורת ה-passwd: password unchanged שמתחתיה מאשרת שלא נכתב דבר. הסיבה השנייה היא מערכת קבצים שלא ניתן לכתוב אליה, מצב שנתקלים בו במצב שחזור, כיוון ש-/ מחובר שם במצב קריאה בלבד (read-only). הריצו את mount -o remount,rw / ונסו שנית.

האם שינוי סיסמת ה-Linux שלי משנה גם את סיסמת ה-sudo?

כן. ל-sudo אין סיסמה משל עצמו. הוא מאמת את זהותכם דרך PAM מול אותה רשומת /etc/shadow שבה משתמשים SSH ו-su, לכן קיימת סיסמה אחת בלבד לכל חשבון. זו גם הסיבה שהנחיית ה-sudo הראשונה לאחר שינוי היא המבחן האמיתי. הריצו את sudo -k && sudo -v כדי לאלץ את הופעת ההנחיה הזו בזמן שעדיין יש לכם session פעיל.

האם שינוי הסיסמה יפגע במפתחות ה-SSH שלי או ב-sessions פתוחים?

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

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

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