Ubuntu VPS पर root password कैसे बदलें

Ubuntu पर अपने VPS का root password कैसे बदलें

Ubuntu पर अपने VPS (virtual private server) का root password बदलने के लिए, एक ऐसे user के रूप में SSH (secure shell) session खोलें जो sudo चला सकता हो, फिर sudo passwd root चलाएं। यह आपसे दो बार नया password मांगेगा और पुराना password कभी नहीं पूछेगा, क्योंकि sudo पहले ही आपकी पहचान सत्यापित कर चुका है। इसके बजाय अपने स्वयं के login password को बदलने के लिए, बिना किसी argument के passwd चलाएं, और यह सबसे पहले आपसे आपका वर्तमान password मांगेगा।

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

यह पूरी प्रक्रिया है। नीचे दी गई हर चीज़ वह हिस्सा है जहाँ गड़बड़ी हो सकती है: उस session को खोने से पहले यह जांचना कि नया password काम कर रहा है या नहीं (जिससे आप इसे ठीक कर सकते हैं), script से password सेट करना, जानबूझकर password expire करना, और password खो जाने पर वापस access प्राप्त करना।

पासवर्ड बदलने से पहले दूसरा session खोलें

अभी एक दूसरा SSH session खोलें और उसे connected रहने दें। इस गाइड में होने वाली लगभग हर त्रुटि को तब दो मिनट में ठीक किया जा सकता है जब एक authenticated shell सक्रिय हो, जबकि अंतिम shell बंद होने के बाद आपको console तक जाना पड़ सकता है।

एक बार open हो चुकी shell उस account के बदले जाने, lock होने या expire होने के बाद भी काम करती रहती है, क्योंकि SSH credentials की जाँच केवल login के समय करता है और बाद में दोबारा नहीं करता। इसका अपवाद sudo है। यह PAM (pluggable authentication modules) के माध्यम से आपके पासवर्ड की दोबारा जाँच करता है, जो डिफ़ॉल्ट रूप से अंतिम prompt के 15 मिनट बाद expire हो जाता है। इसलिए नए पासवर्ड का वास्तविक परीक्षण अगली बार तब होता है जब sudo इसे मांगता है, न कि login के समय।

दूसरे session में नए पासवर्ड का परीक्षण करें जबकि पहला session खुला रहे।

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 स्थित है, उसमें लिखा नहीं जा सकता, जो कि recovery mode में सामान्य स्थिति है। You must choose a longer password. त्रुटि /etc/pam.d/common-password में pam_unix से आती है, जो सामान्य उपयोगकर्ताओं पर लंबाई और समानता की जांच लागू करती है।

अधिकांश VPS images पर डिफ़ॉल्ट खाते (ubuntu, या आपके प्रदाता द्वारा दिया गया कोई भी नाम) का कोई पासवर्ड नहीं होता, केवल एक SSH key होती है। passwd के पास जांचने के लिए कोई वर्तमान पासवर्ड नहीं होता, इसलिए यह पहले प्रॉम्प्ट से आगे नहीं बढ़ सकता। इसके बजाय sudo passwd $USER का उपयोग करें, जो इसलिए काम करता है क्योंकि image की sudoers drop-in file उस खाते को बिना पासवर्ड के sudo चलाने की अनुमति देती है।

sudo passwd का उपयोग करके किसी अन्य उपयोगकर्ता का पासवर्ड बदलें

sudo passwd deploy

Root से पुराना पासवर्ड नहीं पूछा जाता है, और pam_unix उन strength checks को छोड़ देता है जो सामान्य उपयोगकर्ताओं पर लागू होते हैं। इसलिए root ऐसा पासवर्ड सेट कर सकता है जिसे उपयोगकर्ता स्वयं सेट नहीं कर सकता था।

Locking एक अलग प्रक्रिया है। sudo passwd -l deploy संग्रहीत hash के आगे एक ! लगा देता है, जिससे कोई भी पासवर्ड उससे मेल नहीं खाता। sudo passwd -u deploy इसे हटा देता है। sudo passwd -S deploy के साथ स्थिति की जाँच करें।

पासवर्ड lock करने से उपयोगकर्ता का login नहीं रुकता है। उनके ~/.ssh/authorized_keys में मौजूद कोई भी key काम करती रहेगी, क्योंकि public key authentication कभी भी /etc/shadow को नहीं पढ़ता है। किसी account को पूरी तरह से रोकने के लिए, account की समय-सीमा समाप्त (expire) करें:

sudo usermod --expiredate 1 deploy

यह account की expiry date को 1970 में सेट कर देता है, इसलिए sshd किसी भी credential के बावजूद login को अस्वीकार कर देता है। इसे sudo usermod --expiredate '' deploy के साथ पूर्ववत करें।

passwd -d का उपयोग करने से बचें। यह lock किए गए पासवर्ड के बजाय एक खाली पासवर्ड सेट कर देता है, और पुराने release पर जिसमें PAM stack में अभी भी nullok मौजूद है, खाली पासवर्ड का उपयोग कोई भी कर सकता है।

क्या VPS पर root के लिए पासवर्ड की आवश्यकता होती है?

Ubuntu में root अकाउंट लॉक होकर आता है। /etc/shadow में हैश के स्थान पर ! होता है, और sudo passwd -S root एक ऐसी लाइन प्रिंट करता है जो root L से शुरू होती है। जब तक आप पासवर्ड सेट नहीं करते, तब तक कोई भी root के रूप में पासवर्ड से लॉग इन नहीं कर सकता, इसीलिए सर्वर इमेज आपको sudo-capable यूजर प्रदान करती है। root के बजाय VPS पर least privilege user accounts का उपयोग करना ही सुरक्षित तरीका है।

root पासवर्ड सेट करने से केवल एक लाभ मिलता है: प्रोवाइडर कंसोल के माध्यम से सर्वर एक्सेस करना। वह कंसोल नेटवर्क स्टैक के नीचे वर्चुअल मशीन से जुड़ा होता है, इसलिए जब sshd गलत कॉन्फ़िगर हो या कोई फायरवॉल नियम समस्या पैदा करे, तब भी यह काम करता है। लेकिन इसकी एक कीमत भी है। GRUB रिकवरी मेनू का root शेल पासवर्ड मांगता है यदि 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

यह काम करता है, लेकिन यह आपके शेल हिस्ट्री और CI (कंटीन्यूअस इंटीग्रेशन) लॉग्स में प्लेनटेक्स्ट पासवर्ड डाल देता है। इसके बजाय पहले इसे हैश करें:

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

openssl passwd -6 पासवर्ड को बिना इको (echo) के दो बार पूछता है, और फिर $6$ से शुरू होने वाला SHA-512 क्रिप्ट हैश प्रिंट करता है। -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 नहीं करता: 20.04 पर पुराना shadow पैकेज उस मेथड नाम को नहीं पहचानता। ये हैश रिलीज अपग्रेड के बाद भी सुरक्षित रहते हैं, इसलिए 24.04 सर्वर को 26.04 पर ले जाने के लिए आपको किसी का भी पासवर्ड रीसेट करने की आवश्यकता नहीं पड़ती।

पासवर्ड वास्तव में बदल गया है, यह कैसे जाँचें?

सबसे पहले मेटाडेटा देखें, फिर लॉगिन करके इसकी पुष्टि करें।

sudo passwd -S deploy

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

दूसरा फ़ील्ड स्थिति (state) दर्शाता है: P एक उपयोग योग्य पासवर्ड के लिए, L लॉक किए गए पासवर्ड के लिए, और NP बिना पासवर्ड के खाते के लिए। तारीख वह है जब पासवर्ड आखिरी बार बदला गया था, इसलिए इसमें आज की तारीख होनी चाहिए। इसके बाद के नंबर एजिंग फ़ील्ड हैं, जिन्हें नीचे समझाया गया है।

सबसे सुरक्षित लाइव टेस्ट स्वयं sudo है। sudo -k कैश किए गए टाइमस्टैम्प को हटा देता है और sudo -v एक नया प्रॉम्प्ट अनिवार्य कर देता है। यदि नया पासवर्ड वहाँ स्वीकार कर लिया जाता है, तो PAM ने इसे स्वीकार कर लिया है, और आपके सत्र (session) में कोई बदलाव नहीं हुआ है।

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 पासवर्ड परिवर्तन की अंतिम तिथि को epoch पर सेट कर देता है, जिससे PAM पासवर्ड को expired मानता है। अगला इंटरैक्टिव लॉगिन शेल देने से पहले वर्तमान पासवर्ड और फिर एक नया पासवर्ड मांगता है। sudo passwd -e deploy बिल्कुल यही काम करता है।

इसका उपयोग केवल उन खातों के लिए करें जो पासवर्ड के साथ इंटरैक्टिव रूप से लॉगिन करते हैं। एक expired पासवर्ड key-based लॉगिन को भी प्रभावित करता है, क्योंकि sshd तब भी PAM account stage को चलाता है जब authentication के लिए key का उपयोग किया गया हो। एक स्क्रिप्टेड ssh deploy@203.0.113.10 'systemctl restart app' इसके साथ विफल हो जाता है और रुक जाता है:

Password change required but no TTY available.

उस लाइन के बाद कुछ भी रन नहीं होता है, और जॉब केवल एक non-zero exit code रिपोर्ट करता है।

पासवर्ड एजिंग फील्ड्स का क्या अर्थ है

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

ये संख्याएं /etc/shadow में उस उपयोगकर्ता की लाइन के 4 से 8 तक के फील्ड्स हैं। न्यूनतम दिन (chage -m) वह अवधि है जिसके बाद ही उपयोगकर्ता अपना पासवर्ड दोबारा बदल सकता है, जो किसी को मजबूरन बदलाव के तुरंत बाद पुराने पासवर्ड पर वापस जाने से रोकता है। अधिकतम दिन (chage -M) वह अवधि है जिसके लिए पासवर्ड वैध रहता है। चेतावनी के दिन (chage -W) वह समय है जब लॉगिन के दौरान चेतावनी दिखाई देने लगती है। निष्क्रिय दिन (chage -I) पासवर्ड समाप्त होने के बाद की वह रियायती अवधि है जिसके बाद पासवर्ड पूरी तरह से स्वीकार करना बंद कर दिया जाता है। खाता समाप्ति (chage -E) एक निश्चित तारीख है, और यह पासवर्ड से स्वतंत्र होती है।

sudo chage -M 90 -W 14 deploy

इसे केवल तभी सेट करें जब कोई नीति इसकी मांग करे। NIST (यूएस नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड्स एंड टेक्नोलॉजी) ने 2017 से ही नियमित पासवर्ड समाप्ति के खिलाफ सलाह दी है, क्योंकि यह लोगों को एक ही पासवर्ड के अनुमानित बदलावों का उपयोग करने के लिए प्रेरित करता है। इसके बजाय, वे समझौता होने के प्रमाण मिलने पर ही पासवर्ड बदलने के लिए मजबूर करने की सिफारिश करते हैं। पासवर्ड मैनेजर में रखा गया एक लंबा और अद्वितीय पासवर्ड, साथ ही key based SSH, 90 दिनों के चक्र से कहीं अधिक बेहतर सुरक्षा प्रदान करता है।

root password खो जाने पर क्या करें

यदि सर्वर पर कोई भी account sudo चला सकता है, तो कुछ भी recover करने की आवश्यकता नहीं है: sudo passwd root एक नया password सेट कर देता है। कठिन स्थिति तब होती है जब कोई भी login काम नहीं कर रहा हो।

नीचे दी गई प्रक्रिया के लिए provider console की आवश्यकता है, जो अधिकांश panels में VNC (virtual network computing) या serial console के रूप में सूचीबद्ध होती है। यह network stack के नीचे virtual machine से जुड़ती है, इसलिए sshd settings और firewall rules का इस पर कोई प्रभाव नहीं पड़ता है।

1. Panel से सर्वर को reboot करें और console पर ध्यान दें।
2. GRUB menu प्राप्त करें। Cloud images आमतौर पर GRUB_TIMEOUT=0 सेट रखती हैं, इसलिए BIOS boot पर Shift को दबाकर रखें, या UEFI boot पर reboot शुरू होते ही बार-बार Esc दबाएं।
3. Advanced options for Ubuntu चुनें, फिर (recovery mode) पर समाप्त होने वाली entry चुनें, और recovery menu में root चुनें।
4. सबसे पहले mount -o remount,rw / चलाएं। Recovery मोड root filesystem को read-only mount करता है, इसलिए इसके बिना passwd विफल हो जाता है क्योंकि यह passwd: Authentication token manipulation error के साथ /etc/shadow में कुछ भी लिख नहीं पाता है।
5. जिस account के लिए आवश्यकता हो उसके लिए passwd ubuntu चलाएं, फिर panel से reboot करें।

यदि root का पहले से ही कोई password है और आप वही भूल गए हैं, तो वह recovery shell आपसे password मांगेगा और यह रास्ता बंद हो जाएगा। इसके बजाय provider की rescue image से boot करें, फिर वास्तविक disk को mount करें और उसके भीतर password बदलें।

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

इस पृष्ठ से /dev/vda1 को copy करने के बजाय lsblk से partition layout पढ़ें। Root partition वह बड़ी वाली होती है। UEFI image पर यह एक छोटी EFI partition के बगल में स्थित होती है जिसमें कोई /etc directory नहीं होती है।

जब SSH आपका पासवर्ड स्वीकार करना बंद कर दे तो क्या करें

अपने उस सत्र (session) से काम करें जो अभी भी खुला है। यदि कोई सत्र नहीं बचा है, तो कंसोल (console) का उपयोग करें।

Permission denied, please try again. का अर्थ है कि सर्वर ने पासवर्ड प्रमाणीकरण (authentication) की पेशकश की और आपके द्वारा भेजे गए पासवर्ड को अस्वीकार कर दिया। इसके सामान्य कारण caps lock का चालू होना, या कंसोल का कीबोर्ड लेआउट वह न होना है जिसका उपयोग आपने पासवर्ड सेट करते समय किया था।

Permission denied (publickey). का अर्थ है कि सर्वर ने कभी पासवर्ड प्रमाणीकरण की पेशकश ही नहीं की। PasswordAuthentication no कहीं न कहीं सेट है, और Ubuntu 22.04 या उसके बाद के वर्ज़न में यह आमतौर पर /etc/ssh/sshd_config.d/ के अंतर्गत एक drop-in फ़ाइल में होता है जो मुख्य फ़ाइल को ओवरराइड (override) कर देता है। प्रभावी मान (effective values) पढ़ें:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes के साथ PasswordAuthentication no अभी भी पासवर्ड को स्वीकार करने देता है, क्योंकि keyboard-interactive विधि वही PAM स्टैक चलाती है। एक को बंद करना और दूसरे को चालू छोड़ देना ही वह तरीका है जिससे एक सर्वर जो केवल key-only दिखता है, टाइप किए गए पासवर्ड स्वीकार करना जारी रखता है।

वही लाइन वह भी है जो एक अस्वीकृत key login प्रिंट करता है, इसलिए यदि आप पासवर्ड के बजाय एक key का उपयोग कर रहे थे, तो सर्वर की पासवर्ड सेटिंग Permission denied (publickey) के पीछे के पांच दोषों में से केवल एक है, और ssh -v आउटपुट आपको बताता है कि आपके साथ कौन सी समस्या है।

डिस्कनेक्ट संदेश में Too many authentication failures का अर्थ है कि आपके क्लाइंट ने पासवर्ड तक पहुँचने से पहले कई keys की पेशकश की, और सर्वर MaxAuthTries तक पहुँच गया, जो डिफ़ॉल्ट रूप से 6 है। एक एकल विधि को बाध्य करें:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

जो पोर्ट एक मिनट पहले काम कर रहा था उस पर Connection refused का अर्थ आमतौर पर यह है कि fail2ban जो SSH की निगरानी कर रहा है ने बार-बार विफलताओं के बाद आपके पते को प्रतिबंधित (ban) कर दिया है। इसका डिफ़ॉल्ट प्रतिबंध नियम पैकेट को ड्रॉप करने के बजाय अस्वीकार कर देता है, यही कारण है कि इनकार (refusal) टाइम आउट होने के बजाय तुरंत वापस आ जाता है। कंसोल से, sudo fail2ban-client status sshd प्रतिबंधित पतों की सूची दिखाता है और sudo fail2ban-client set sshd unbanip 203.0.113.10 आपके पते को हटा देता है।

Passwords एक शुरुआती कदम हैं, keys अंतिम स्थिति हैं

SSH पर काम करने वाला password वह password है जिसे इंटरनेट पर मौजूद हर scanner guess करने की कोशिश करता है। Key-based authentication पर स्विच करें, फिर guessing का कोई महत्व नहीं रह जाएगा। एक key pair generate करें, public key को install करें, और किसी अन्य बदलाव से पहले दूसरे terminal से confirm करें कि key के जरिए login हो पा रहा है। SSH key management basics में generation, authorized_keys और passphrases की जानकारी दी गई है।

इसके बाद password authentication को बंद कर दें, और इसे केवल edit की गई file पर भरोसा करने के बजाय sudo sshd -T से confirm करें। hardening SSH on a VPS में sshd की बाकी settings के बारे में बताया गया है जिन्हें बदलना फायदेमंद है, और the first ten minutes on a new VPS में इन्हें एक नए server पर करने का सही क्रम दिया गया है।

इसके बाद भी एक password सुरक्षित रखें। यदि sshd config खराब हो जाए, तो key-only server तक केवल provider console के जरिए ही पहुँचा जा सकता है, और वह console username और password मांगता है। एक मजबूत password वाला account ही वह चीज है जो पांच मिनट के fix और पूरे server को reinstall करने के बीच का अंतर तय करता है।

FAQ

यदि मुझे अपना पुराना root password नहीं पता है, तो मैं अपने VPS पर इसे कैसे बदलूँ?

ऐसे user के रूप में login करें जो sudo चला सकता है और sudo passwd root चलाएँ। यह पुराने password के बारे में पूछे बिना एक नया password सेट कर देता है, क्योंकि sudo ने पहले ही आपकी पहचान प्रमाणित (authenticate) कर दी है। यदि सर्वर पर कोई भी account sudo नहीं चला सकता, तो provider console खोलें, GRUB recovery menu में reboot करें, root shell entry चुनें, mount -o remount,rw / चलाएँ, और फिर passwd चलाएँ। यदि root का पहले से कोई password है और आप उसे भूल गए हैं, तो recovery shell उसे मांगेगा। ऐसी स्थिति में एकमात्र विकल्प provider की rescue image का उपयोग करना है, जहाँ disk को mount और chroot किया जाता है।

passwd कमांड "Authentication token manipulation error" क्यों दिखाती है?

यह संदेश दो कारणों से आता है। सामान्य कारण Current password: prompt पर गलत उत्तर देना है, और इसके नीचे की passwd: password unchanged line पुष्टि करती है कि कुछ भी लिखा नहीं गया था। दूसरा कारण एक ऐसी filesystem है जिसे लिखा नहीं जा सकता, जो recovery mode में होता है क्योंकि वहाँ / को read-only mount किया जाता है। mount -o remount,rw / चलाएँ और पुनः प्रयास करें।

क्या Linux password बदलने से मेरा sudo password भी बदल जाता है?

हाँ। sudo का अपना कोई अलग password नहीं होता है। यह PAM के माध्यम से उसी /etc/shadow entry के विरुद्ध आपकी पहचान प्रमाणित करता है जिसका उपयोग SSH और su करते हैं, इसलिए प्रति account केवल एक ही password होता है। यही कारण है कि password बदलने के बाद पहला sudo prompt ही वास्तविक परीक्षा होती है। जब आपका session चल रहा हो, तो उस prompt को force करने के लिए sudo -k && sudo -v चलाएँ।

क्या password बदलने से मेरी SSH keys या open sessions टूट जाएंगे?

नहीं। Public key authentication कभी भी /etc/shadow को नहीं पढ़ता है, इसलिए password बदलने के बाद, passwd -l के बाद, और chage -d 0 के बाद भी keys काम करती रहती हैं। जो sessions पहले से खुले हैं, वे खुले ही रहेंगे, क्योंकि SSH केवल login के समय credentials की जाँच करता है। live session के अंदर केवल एक चीज बदलती है, वह है sudo, जो 15 मिनट का timestamp समाप्त होने के बाद नया password मांगता है।

मैं किसी user को अगले login पर password बदलने के लिए कैसे मजबूर करूँ?

sudo chage -d 0 deploy चलाएँ, या sudo passwd -e deploy चलाएँ, जो वही काम करता है। अंतिम-परिवर्तन की तिथि (last-change date) epoch पर चली जाती है, PAM password को expired मान लेता है, और shell शुरू होने से पहले अगले interactive login पर नया password सेट करना अनिवार्य हो जाता है। ऐसा उस account के साथ न करें जिसका उपयोग SSH के माध्यम से scripts द्वारा किया जाता है: एक non-interactive command तब Password change required but no TTY available. के साथ विफल हो जाएगी और कभी नहीं चलेगी।