Ubuntu VPS पर root पासवर्ड कैसे बदलें

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

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

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

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

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

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

एक खुला हुआ शेल उस अकाउंट के बदलने, लॉक होने या एक्सपायर होने के बाद भी काम करता रहता है, क्योंकि 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 एकमात्र ऐसा आउटपुट है जिसका अर्थ है कि /etc/shadow में हैश को बदल दिया गया है। इसके अलावा कुछ भी आने का मतलब है कि पुराना पासवर्ड ही बना हुआ है।

यहाँ दो प्रकार की विफलताएँ होती हैं। passwd: Authentication token manipulation error, जिसके बाद passwd: password unchanged आता है, का अर्थ है कि आपके द्वारा टाइप किया गया वर्तमान पासवर्ड गलत है, या /etc/shadow को होल्ड करने वाले फाइलसिस्टम पर लिखा नहीं जा सकता, जो कि रिकवरी मोड में सामान्य स्थिति है। You must choose a longer password. त्रुटि /etc/pam.d/common-password में pam_unix से आती है, जो सामान्य उपयोगकर्ताओं पर लंबाई और समानता की जाँच लागू करती है।

अधिकांश VPS इमेज पर डिफ़ॉल्ट खाते (ubuntu, या आपके प्रदाता द्वारा प्रदान किया गया कोई भी नाम) का कोई पासवर्ड नहीं होता है, केवल एक SSH key होती है। 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 में मौजूद कोई भी की (key) काम करती रहती है, क्योंकि पब्लिक की ऑथेंटिकेशन कभी भी /etc/shadow को नहीं पढ़ता है। किसी अकाउंट को पूरी तरह से रोकने के लिए, अकाउंट की समय-सीमा समाप्त (expire) करें:

sudo usermod --expiredate 1 deploy

यह अकाउंट की समाप्ति तिथि को 1970 की किसी तारीख पर सेट कर देता है, इसलिए sshd कोई भी क्रेडेंशियल दिए जाने पर लॉग इन को अस्वीकार कर देता है। इसे sudo usermod --expiredate '' deploy के साथ पूर्ववत करें।

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

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

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

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

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

मेटाडेटा से शुरुआत करें, फिर लॉगिन के साथ इसकी पुष्टि करें।

sudo passwd -S deploy

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

दूसरा फ़ील्ड स्थिति दर्शाता है: उपयोग योग्य पासवर्ड के लिए 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) मानता है। अगला इंटरैक्टिव लॉगिन शेल (shell) देने से पहले वर्तमान पासवर्ड और फिर एक नया पासवर्ड मांगता है। sudo passwd -e deploy बिल्कुल यही काम करता है।

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

Password change required but no TTY available.

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

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

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 (US National Institute of Standards and Technology) ने 2017 से ही नियमित पासवर्ड एक्सपायरी के खिलाफ सलाह दी है, क्योंकि यह लोगों को एक ही पासवर्ड के अनुमानित बदलाव करने के लिए प्रेरित करता है। इसके बजाय, NIST समझौता होने के प्रमाण मिलने पर पासवर्ड बदलने के लिए मजबूर करने की सिफारिश करता है। पासवर्ड मैनेजर में रखा गया एक लंबा और अद्वितीय पासवर्ड, साथ ही key आधारित SSH, 90 दिनों के चक्र से बेहतर सुरक्षा प्रदान करता है।

जब आप root पासवर्ड खो दें तो क्या करें

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

नीचे दी गई हर प्रक्रिया के लिए प्रोवाइडर कंसोल की आवश्यकता होती है, जिसे अधिकांश पैनल में VNC (virtual network computing) या सीरियल कंसोल के रूप में सूचीबद्ध किया जाता है। यह नेटवर्क स्टैक के नीचे वर्चुअल मशीन से जुड़ता है, इसलिए sshd सेटिंग्स और फायरवॉल नियम इसे प्रभावित नहीं करते हैं।

1. पैनल से सर्वर को रीबूट करें और कंसोल पर नज़र रखें।
2. GRUB मेनू प्राप्त करें। क्लाउड इमेज आमतौर पर GRUB_TIMEOUT=0 सेट करती हैं, इसलिए BIOS बूट पर Shift को दबाकर रखें, या रीबूट शुरू होते ही UEFI बूट पर बार-बार Esc दबाएं।
3. Advanced options for Ubuntu चुनें, फिर (recovery mode) पर समाप्त होने वाली प्रविष्टि चुनें, और उसके बाद रिकवरी मेनू में root चुनें।
4. सबसे पहले mount -o remount,rw / चलाएं। रिकवरी मोड रूट फाइलसिस्टम को केवल-पढ़ने (read-only) की अनुमति के साथ माउंट करता है, इसलिए इसके बिना 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

/dev/vda1 को इस पेज से कॉपी करने के बजाय lsblk से पार्टीशन लेआउट पढ़ें। रूट पार्टीशन बड़ा वाला होता है। UEFI इमेज पर यह एक छोटे EFI पार्टीशन के बगल में स्थित होता है जिसमें कोई /etc डायरेक्टरी नहीं होती है।

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

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

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

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

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

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

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

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

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

पासवर्ड एक शुरुआती कदम हैं, कुंजियाँ अंतिम स्थिति हैं

SSH पर काम करने वाला पासवर्ड वह पासवर्ड है जिसका अनुमान इंटरनेट पर मौजूद हर स्कैनर लगा सकता है। की-बेस्ड ऑथेंटिकेशन (key based authentication) अपनाएं और अनुमान लगाने की प्रक्रिया का महत्व खत्म हो जाएगा। एक की-पेयर (key pair) जनरेट करें, पब्लिक हाफ को इंस्टॉल करें, और कुछ भी बदलने से पहले दूसरे टर्मिनल से पुष्टि करें कि कुंजी आपको लॉग इन करने दे रही है। SSH कुंजी प्रबंधन की बुनियादी बातें में जनरेशन, authorized_keys और पासफ्रेज शामिल हैं।

इसके बाद पासवर्ड ऑथेंटिकेशन को बंद कर दें, और जिस फाइल को आपने एडिट किया है उस पर भरोसा करने के बजाय sudo sshd -T के साथ इसकी पुष्टि करें। VPS पर SSH को सुरक्षित करना उन बाकी sshd सेटिंग्स के बारे में बताता है जिन्हें बदलना उचित है, और नए VPS पर शुरुआती दस मिनट उन्हें एक नए सर्वर पर लागू करने का सही क्रम बताता है।

इसके बाद एक पासवर्ड अपने पास रखें। खराब sshd कॉन्फ़िगरेशन वाला की-ओनली सर्वर केवल प्रोवाइडर कंसोल के माध्यम से ही एक्सेस किया जा सकता है, और वह कंसोल यूजरनेम और पासवर्ड मांगता है। एक मजबूत पासवर्ड वाला अकाउंट, जिसे आपने सुरक्षित रखा है, वही पांच मिनट के फिक्स और रीइंस्टॉल के बीच का अंतर है।

FAQ

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

ऐसे उपयोगकर्ता के रूप में लॉग इन करें जो 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 लाइन पुष्टि करती है कि कुछ भी नहीं लिखा गया था। दूसरा कारण एक ऐसी फाइलसिस्टम है जिसे लिखा नहीं जा सकता, जो रिकवरी मोड में होता है क्योंकि वहां / केवल-पठनीय (read-only) मोड में माउंट होता है। mount -o remount,rw / चलाएं और पुनः प्रयास करें।

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

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

क्या पासवर्ड बदलने से मेरी SSH keys या खुले सत्र (sessions) प्रभावित होंगे?

नहीं। पब्लिक की ऑथेंटिकेशन कभी भी /etc/shadow को नहीं पढ़ती है, इसलिए पासवर्ड बदलने के बाद, passwd -l के बाद, और chage -d 0 के बाद भी keys काम करती रहती हैं। जो सत्र पहले से खुले हैं वे खुले ही रहेंगे, क्योंकि SSH केवल लॉगिन के समय क्रेडेंशियल्स की जांच करता है। लाइव सत्र के भीतर केवल एक चीज बदलती है, वह है sudo, जो 15 मिनट का टाइमस्टैम्प समाप्त होने के बाद नया पासवर्ड मांगता है।

मैं किसी उपयोगकर्ता को अगले लॉगिन पर पासवर्ड बदलने के लिए कैसे बाध्य करूँ?

sudo chage -d 0 deploy चलाएं, या sudo passwd -e deploy चलाएं, जो समान कार्य करता है। संग्रहीत अंतिम-परिवर्तन तिथि epoch पर चली जाती है, PAM पासवर्ड को समाप्त मान लेता है, और अगले इंटरैक्टिव लॉगिन पर शेल शुरू होने से पहले एक नया पासवर्ड सेट करना अनिवार्य हो जाता है। SSH के माध्यम से स्क्रिप्ट द्वारा उपयोग किए जाने वाले खाते के साथ ऐसा न करें: एक नॉन-इंटरैक्टिव कमांड तब Password change required but no TTY available. के साथ विफल हो जाएगी और कभी नहीं चलेगी।