שינוי סיסמת 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

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

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

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

Shell שכבר פתוח ממשיך לפעול גם לאחר שמשנים, נועלים או פוקעים את החשבון שאליו הוא שייך, משום ש־SSH בודק את פרטי האימות בעת ההתחברות ואינו בודק אותם שוב. החריג הוא sudo. הוא בודק מחדש את הסיסמה באמצעות PAM (מודולי אימות הניתנים לחיבור) לאחר שתוקף פרטי האימות השמורים פג, כברירת מחדל לאחר 15 דקות ב־Ubuntu. פרק הזמן הזה אינו נספר מהפקודה האחרונה, משום ש־sudo -v מרענן את פרטי האימות השמורים בלי לבקש אותם שוב. לכן הסיסמה החדשה נבדקת בפועל בפעם הבאה שבה sudo מבקש אותה, ולא בעת ההתחברות.

בדקו את הסיסמה החדשה ב־session השני, בזמן שה־session הראשון נשאר פתוח.

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

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 באמצעות סיסמה עד שלא תגדיר אחת, וזו הסיבה שהתמונה (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

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

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

openssl passwd -6 מבקש את הסיסמה פעמיים בלי להציג את התווים, ולאחר מכן מדפיס hash מסוג SHA-512 crypt שמתחיל ב־$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 החל מ־18.04, בניגוד ל־chpasswd -c YESCRYPT: חבילת shadow הישנה יותר ב־20.04 אינה מכירה בשם השיטה הזה. Ubuntu 16.04 הוא חריג, משום ש־OpenSSL 1.0.2 שלו אינו כולל כלל אפשרות -6. ה־hashים האלה נשמרים גם לאחר שדרוג בין מהדורות, ולכן שדרוג שרת 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 מפעיל את שלב החשבון של PAM גם כאשר המפתח הוא שאימת את המשתמש. פקודת ssh deploy@203.0.113.10 'systemctl restart app' בסקריפט נכשלת לאחר מכן עם השגיאה הזאת, לפני שהפקודה מופעלת:

Password change required but no TTY available.

הפקודה המרוחקת אינה מופעלת, ו־ssh מסתיים בקוד שאינו אפס. אלא אם הסקריפט הקורא עוצר במקרה של שגיאות באמצעות set -e או באמצעות בדיקה מפורשת, השורות שאחריו עדיין יופעלו, והמשימה עלולה להסתיים כאילו האתחול מחדש אכן בוצע.

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

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. ה-no הזה יכול להימצא בקובץ הראשי או בקובץ drop-in, לכן בדוק את שניהם. sshd קורא את הקבצים תחת /etc/ssh/sshd_config.d/ בתחילת התצורה שלו ושומר את הערך הראשון שהוא מוצא עבור כל מילת מפתח, כך שקובץ drop-in דורס את /etc/ssh/sshd_config. אותו כלל פועל לעיתים קרובות בצורה הפוכה בשרתי Ubuntu 24.04 שהותקנו מ-ISO עם SSH פעיל: המתקין משאיר קובץ drop-in של cloud-init, ה-50-cloud-init.conf, שמגדיר PasswordAuthentication yes, ואז no שנוסף לקובץ הראשי מתעלמים ממנו. קרא את הערכים האפקטיביים:

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

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

כיצד מאלצים משתמש לשנות את הסיסמה בהתחברות הבאה?

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