Ubuntu VPS चा root पासवर्ड कसा बदलावा

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

Ubuntu वर तुमचा VPS (virtual private server) root पासवर्ड बदलण्यासाठी, sudo चालवू शकणाऱ्या वापरकर्त्याच्या रूपात SSH (secure shell) सत्र उघडा आणि त्यानंतर sudo passwd root चालवा. ही कमांड नवीन पासवर्ड दोनदा विचारते आणि जुना पासवर्ड विचारत नाही, कारण sudo ने तुमची ओळख आधीच पडताळली आहे. त्याऐवजी स्वतःचा login पासवर्ड बदलायचा असल्यास, कोणतेही arguments न देता passwd चालवा. त्या वेळी ही कमांड प्रथम सध्याचा पासवर्ड विचारते.

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

हीच संपूर्ण प्रक्रिया आहे. खालील भागात प्रत्यक्षात उद्भवणाऱ्या समस्या दिल्या आहेत: सत्र बंद होण्यापूर्वी नवीन पासवर्ड कार्यरत आहे हे पडताळणे, दुरुस्ती करू शकणारे सत्र गमावण्यापूर्वी त्याची खात्री करणे, script मधून पासवर्ड सेट करणे, एखादा पासवर्ड जाणीवपूर्वक expire करणे आणि पासवर्ड आधीच हरवला असल्यास पुन्हा प्रवेश मिळवणे.

पासवर्डमध्ये बदल करण्यापूर्वी दुसरे सत्र उघडा

आता दुसरे SSH सत्र उघडा आणि ते जोडलेले ठेवा. या मार्गदर्शकातील जवळजवळ प्रत्येक त्रुटी एका authenticated shell मध्ये session अद्याप सुरू असताना दोन मिनिटांत दुरुस्त करता येते. शेवटचे सत्र बंद झाल्यानंतर मात्र console पर्यंत जावे लागू शकते.

आधीपासून उघडलेला shell त्याच्याशी संबंधित account बदलल्यानंतर, lock केल्यानंतर किंवा expire केल्यानंतरही कार्यरत राहतो. याचे कारण SSH login वेळी credentials तपासते आणि त्यानंतर पुन्हा तपासत नाही. याला अपवाद sudo आहे. cached credentials expire झाल्यानंतर ते PAM (pluggable authentication modules) द्वारे तुमचा password पुन्हा तपासते. Ubuntu मध्ये ही मुदत default ने 15 minutes असते. ही मुदत शेवटच्या prompt पासून मोजली जात नाही, कारण sudo -v पुन्हा विचारणा न करता cached credentials refresh करते. त्यामुळे नवीन password ची पहिली वास्तविक चाचणी login वेळी होत नाही. sudo प्रत्यक्षात password विचारते तेव्हा ती होते.

पहिले सत्र सुरू ठेवून दुसऱ्या सत्रात नवीन password तपासा.

passwd वापरून तुमचा स्वतःचा पासवर्ड बदला

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully हेच एकमेव आउटपुट आहे ज्याचा अर्थ /etc/shadow मधील hash बदलला आहे. त्याशिवाय इतर कोणतेही आउटपुट आल्यास जुना पासवर्ड तसाच राहतो.

येथे दोन त्रुटी येतात. passwd: Authentication token manipulation error नंतर passwd: password unchanged आल्यास, तुम्ही टाइप केलेला सध्याचा पासवर्ड चुकीचा आहे किंवा /etc/shadow असलेली filesystem लिहिण्यायोग्य नाही. Recovery mode मध्ये ही नेहमीची स्थिती आहे. You must choose a longer password. हे /etc/pam.d/common-password मधील pam_unix कडून येते. ते सामान्य users साठी लांबी आणि साम्याच्या तपासण्या लागू करते.

बहुतेक VPS images मध्ये default account (ubuntu किंवा तुमच्या provider ने दिलेले कोणतेही नाव) साठी कोणताही पासवर्ड नसतो. त्या account साठी फक्त SSH key असते. passwd कडे तपासण्यासाठी सध्याचा पासवर्ड नसतो. त्यामुळे तो पहिल्या prompt नंतर पुढे जाऊ शकत नाही. त्याऐवजी sudo passwd $USER वापरा. हे कार्य करते, कारण image मधील sudoers drop-in file त्या account ला पासवर्डशिवाय sudo चालवण्याची परवानगी देते.

sudo passwd वापरून दुसऱ्या वापरकर्त्याचा पासवर्ड बदला

sudo passwd deploy

root कडून जुना पासवर्ड विचारला जात नाही. तसेच, pam_unix सामान्य वापरकर्त्यांसाठी लागू होणाऱ्या password strength तपासण्या वगळते. त्यामुळे root असा पासवर्ड सेट करू शकतो, जो वापरकर्ता स्वतःसाठी सेट करू शकला नसता.

पासवर्ड लॉक करणे ही स्वतंत्र कृती आहे. sudo passwd -l deploy साठवलेल्या hash च्या पुढे ! लावते. त्यामुळे कोणताही पासवर्ड त्याच्याशी जुळत नाही. sudo passwd -u deploy ते काढून टाकते. sudo passwd -S deploy वापरून स्थिती पुन्हा तपासा.

पासवर्ड लॉक केल्याने त्या वापरकर्त्याचे login थांबत नाही. त्याच्या ~/.ssh/authorized_keys मधील कोणतीही key अद्याप कार्यरत राहते, कारण public key authentication पासवर्ड hash तपासत नाही. एखादे account पूर्णपणे थांबवण्यासाठी account स्वतः expire करा:

sudo usermod --expiredate 1 deploy

यामुळे account expiry 1970 मधील तारखेवर सेट होते. त्यामुळे कोणतेही credential दिले तरी sshd login नाकारते. sudo usermod --expiredate '' deploy वापरून ही कृती पूर्ववत करा.

passwd -d टाळा. ते account लॉक करण्याऐवजी रिकामा पासवर्ड सेट करते. जुन्या release मध्ये PAM stack मध्ये nullok अद्याप असल्यास, रिकामा पासवर्ड कोणताही वापरकर्ता वापरू शकतो.

VPS वर root साठी password आवश्यक आहे का?

Ubuntu मध्ये root account locked असते. /etc/shadow मध्ये hash ऐवजी ! असते आणि sudo passwd -S root root L ने सुरू होणारी ओळ दाखवते. Password सेट करेपर्यंत password वापरून root म्हणून कोणीही login करू शकत नाही. त्यामुळे image ऐवजी sudo वापरता येणारा user दिला जातो. root म्हणून काम करण्याऐवजी VPS वरील least privilege user accounts वापरण्याची पद्धत कायम ठेवावी.

root password सेट केल्याने एक विशिष्ट सुविधा मिळते: provider console द्वारे प्रवेश. हा console network stack च्या खाली virtual machine शी जोडलेला असतो. त्यामुळे sshd configuration चुकीची असली किंवा firewall rule चुकीचा असला तरी तो कार्यरत राहतो. मात्र त्याची एक किंमतही आहे. root account साठी password सेट केले असल्यास GRUB recovery menu मधील root shell तो password विचारतो. त्यामुळे विसरलेला password reset करण्यासाठी वापरण्याचे साधन त्याच password मागे अडकते.

root password सेट केल्याने SSH द्वारे root म्हणून login करता येत नाही. Ubuntu मध्ये PermitRootLogin prohibit-password असते, म्हणजे केवळ keys वापरता येतात. तुमचा server प्रत्यक्षात कोणती configuration वापरतो ते तपासा:

sudo sshd -T | grep -i permitrootlogin

प्रत्येक Include line resolve केल्यानंतर sshd -T प्रभावी configuration दाखवते. त्यामुळे /etc/ssh/sshd_config.d/ drop-in files ठेवत असल्यास हेच एकमेव अचूक उत्तर असते.

स्क्रिप्टमधून chpasswd वापरून पासवर्ड सेट करा

passwd टर्मिनलमधून इनपुट वाचते आणि स्क्रिप्टद्वारे चालवता येत नाही. chpasswd standard input वरून प्रत्येक ओळीत एक user:password जोडी वाचते.

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

हे कार्य करते; परंतु यामुळे तुमच्या shell history आणि CI (continuous integration) logs मध्ये plaintext पासवर्ड नोंदवला जातो. त्याऐवजी आधी त्याचा hash तयार करा:

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

openssl passwd -6 पासवर्ड दोनदा विचारते आणि तो टाइप करताना काहीही दाखवत नाही. त्यानंतर ती $6$ ने सुरू होणारा SHA-512 crypt hash छापते. -e, chpasswd ला दुसरे field आधीच hashed असल्याचे सांगते. त्यामुळे ते /etc/shadow मध्ये जसेच्या तसे कॉपी केले जाते. हा hash repository किंवा CI variable मध्ये सुरक्षितपणे ठेवता येतो. plaintext तुम्ही टाइप केलेल्या machine बाहेर कधीही जात नाही.

passwd पासवर्ड सेट करते तेव्हा Ubuntu 24.04 नवीन पासवर्डसाठी yescrypt ($y$) वापरते. openssl passwd -6 मात्र SHA-512 देते. libxcrypt दोन्ही format वाचत असल्यामुळे login वेळी दोन्हीची पडताळणी होते. हे format एकत्र वापरणे सुरक्षित आहे. openssl passwd -6, 18.04 पासूनच्या प्रत्येक Ubuntu LTS release वर समान प्रकारे कार्य करते. chpasswd -c YESCRYPT मात्र तसे नाही: 20.04 मधील जुने shadow package त्या method name ला ओळखत नाही. Ubuntu 16.04 याला अपवाद आहे, कारण त्यातील OpenSSL 1.0.2 मध्ये -6 option मुळीच नाही. हे hash release upgrade नंतरही वैध राहतात. त्यामुळे 24.04 server ला 26.04 वर upgrade केल्यावर कोणाचाही पासवर्ड reset करावा लागत नाही.

पासवर्ड प्रत्यक्षात बदलला आहे का हे कसे तपासाल?

प्रथम metadata तपासा आणि त्यानंतर login करून त्याची खात्री करा.

sudo passwd -S deploy

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

दुसरे field म्हणजे state: वापरता येणाऱ्या पासवर्डसाठी P, locked पासवर्डसाठी L आणि पासवर्डच नसल्यास NP. तारीख म्हणजे पासवर्ड शेवटचा कधी बदलला ती वेळ; त्यामुळे त्यात आजची तारीख दिसली पाहिजे. त्यानंतरचे आकडे खाली स्पष्ट केलेली password aging fields आहेत.

प्रत्यक्ष प्रणालीवरची सर्वात सुरक्षित चाचणी म्हणजे sudo. sudo -k cached timestamp काढून टाकते आणि sudo -v नवीन prompt दाखवण्यास भाग पाडते. तिथे नवीन पासवर्ड स्वीकारला गेला, तर PAM ने तो स्वीकारला आहे आणि तुमच्या session मध्ये कोणताही बदल झालेला नाही.

sudo -k && sudo -v

दुसऱ्या account ची चाचणी करण्यासाठी unprivileged shell मधून su - deploy चालवा. sudo su - deploy चालवू नका, कारण root ला पासवर्ड विचारला जात नाही आणि या चाचणीतून काहीही सिद्ध होत नाही. चुकीचा पासवर्ड दिल्यास su: Authentication failure दिसते.

खरी चाचणी म्हणजे तुमच्या laptop वरून नवीन SSH login करणे आणि सध्याचे working session उघडे ठेवणे:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

येथे Permission denied (publickey). याचा अर्थ server ने password authentication उपलब्ध करून दिले नाही; त्यामुळे कोणताही पासवर्ड बदल तुम्हाला login करू देणार नाही. Permission denied, please try again. याचा अर्थ server ने password authentication उपलब्ध करून दिले, पण तुम्ही टाइप केलेला पासवर्ड नाकारला.

पुढील login वेळी password बदलण्यास chage वापरा

sudo chage -d 0 deploy

-d 0 last change ची तारीख epoch वर सेट करते. त्यामुळे PAM password expired असल्याचे मानते. पुढील interactive login वेळी shell देण्यापूर्वी current password आणि त्यानंतर नवीन password विचारला जातो. sudo passwd -e deploy हेच काम करते.

हे फक्त password वापरून interactive login करणाऱ्या accounts साठी वापरा. Expired password मुळे key-based login वरही परिणाम होतो, कारण key ने authentication झाले तरी sshd PAM account stage चालवते. Script मधील ssh deploy@203.0.113.10 'systemctl restart app' या कारणामुळे command चालण्यापूर्वीच fail होते:

Password change required but no TTY available.

Remote command कधीही चालत नाही आणि ssh non-zero code सह exit होते. Calling script ने errors वर थांबण्याची व्यवस्था केली नसेल, म्हणजे set -e किंवा explicit check वापरले नसेल, तर त्यानंतरच्या lines तरीही चालतात. त्यामुळे restart झाल्याप्रमाणे job पूर्ण होऊ शकते.

पासवर्ड कालबाह्यता फील्डचा अर्थ

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) म्हणजे login वेळी इशारा दाखवण्यास सुरुवात होण्यापूर्वीचे दिवस. निष्क्रिय दिवस (chage -I) म्हणजे पासवर्ड कालबाह्य झाल्यानंतर तो पूर्णपणे नाकारला जाण्यापूर्वीचा grace period. Account expiry (chage -E) ही निश्चित तारीख असते. ती पासवर्डपासून स्वतंत्र असते.

sudo chage -M 90 -W 14 deploy

धोरणात आवश्यक असल्यासच हे सेट करा. NIST (US National Institute of Standards and Technology) ने 2017 पासून नियमित पासवर्ड कालबाह्यतेविरुद्ध सल्ला दिला आहे. कारण त्यामुळे वापरकर्ते एका पासवर्डच्या अंदाज लावता येणाऱ्या आवृत्त्या वापरू लागतात. त्याऐवजी, पासवर्ड compromise झाल्याचा पुरावा मिळाल्यावर बदल सक्तीचा करण्याची शिफारस NIST करते. Password manager मध्ये जतन केलेला लांब आणि अद्वितीय पासवर्ड, तसेच key-based SSH, 90 दिवसांच्या चक्रापेक्षा अधिक सुरक्षित आहे.

root पासवर्ड हरवल्यावर काय करावे

सिस्टमवरील कोणतेही खाते sudo चालवू शकत असल्यास, पुनर्प्राप्त करण्यासारखे काहीही नाही: sudo passwd root नवीन पासवर्ड सेट करते. कोणतेही कार्यरत login उपलब्ध नसणे ही कठीण परिस्थिती आहे.

खालील सर्व कृतींसाठी provider console आवश्यक आहे. बहुतेक panels मध्ये ती VNC (virtual network computing) किंवा serial console म्हणून दिलेली असते. ही console network stack च्या खालील virtual machine शी जोडते. त्यामुळे sshd settings आणि firewall rules चा तिच्यावर परिणाम होत नाही.

1. panel मधून server 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. आवश्यक असलेल्या खात्यासाठी passwd ubuntu चालवा. त्यानंतर panel मधून reboot करा.

root साठी आधीपासून पासवर्ड सेट केलेला असेल आणि तोच हरवला असेल, तर recovery shell तो पासवर्ड मागते आणि ही पद्धत पुढे चालत नाही. त्याऐवजी provider ची rescue image boot करा. त्यानंतर वास्तविक disk 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

या पृष्ठावरील /dev/vda1 तंतोतंत कॉपी करण्याऐवजी lsblk मधून partition layout तपासा. root partition सर्वांत मोठा असतो. UEFI image मध्ये त्याच्या बाजूला एक लहान EFI partition असतो. त्यात /etc directory अजिबात नसते.

SSH password स्वीकारणे बंद झाल्यावर काय करावे

तुमच्याकडे अजून उपलब्ध असलेल्या session मधून काम करा. कोणतीही session शिल्लक नसेल, तर console वापरा.

Permission denied, please try again. याचा अर्थ सर्व्हरने password authentication उपलब्ध करून दिले, पण तुम्ही पाठवलेला password नाकारला. नेहमीची कारणे म्हणजे caps lock सुरू असणे किंवा console चा keyboard layout password सेट करताना वापरलेल्या layout पेक्षा वेगळा असणे.

Permission denied (publickey). याचा अर्थ सर्व्हरने password authentication उपलब्ध करून दिले नाही. त्यामुळे प्रभावी मूल्य PasswordAuthentication no आहे. हा no मुख्य file मध्ये किंवा drop-in मध्ये असू शकतो. त्यामुळे दोन्ही तपासा. sshd configuration च्या सुरुवातीला /etc/ssh/sshd_config.d/ अंतर्गत असलेल्या files वाचतो आणि प्रत्येक keyword साठी त्याला मिळणारे पहिले मूल्य ठेवतो. त्यामुळे drop-in /etc/ssh/sshd_config वर override करतो. Ubuntu 24.04 वर SSH enabled ठेवून ISO मधून install केलेल्या servers मध्ये हेच नियम उलट दिशेनेही लागू होतात. Installer cloud-init drop-in, 50-cloud-init.conf, ठेवतो. त्यात PasswordAuthentication yes सेट केलेले असते. त्यामुळे main file मध्ये नंतर जोडलेला no दुर्लक्षित केला जातो. प्रभावी मूल्ये वाचा:

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

KbdInteractiveAuthentication yes सोबत PasswordAuthentication no सक्षम असले तरी password स्वीकारला जातो, कारण keyboard-interactive method त्याच PAM stack चा वापर करते. एक method बंद ठेवून दुसरा सुरू ठेवला, तर server key-only असल्यासारखा दिसतो; तरीही तो टाइप केलेले passwords स्वीकारत राहतो.

Key login नाकारल्यावरही तीच line disconnect message मध्ये दिसते. त्यामुळे तुम्ही password ऐवजी key वापरत असाल, तर server ची password setting ही Permission denied (publickey) मागील पाच कारणांपैकी एकच आहे. ssh -v output मधून नेमकी कोणती समस्या आहे ते कळते.

Disconnect message मधील Too many authentication failures याचा अर्थ connection ने server ची MaxAuthTries मर्यादा वापरून संपवली. ही मर्यादा default नुसार 6 attempts आहे. नेहमीचे कारण म्हणजे password पर्यंत पोहोचण्यापूर्वी client ने अनेक keys सादर करणे. एकच method सक्तीने वापरा:

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

एक मिनिटापूर्वी चालू असलेल्या port वर Connection refused दिसत असल्यास, SSH वर fail2ban चे निरीक्षण यामुळे repeated failures नंतर तुमचा address ban झाला असण्याची शक्यता आहे. त्याचा default ban rule packet drop करण्याऐवजी तो reject करतो. त्यामुळे connection timeout होण्याऐवजी refusal लगेच परत येतो. Console मधून sudo fail2ban-client status sshd banned addresses दाखवतो आणि sudo fail2ban-client set sshd unbanip 203.0.113.10 तुमचा address clear करतो.

संकेतशब्द हा संक्रमणाचा टप्पा आहे; keys हे अंतिम ध्येय आहे

SSH वर कार्य करणारा संकेतशब्द इंटरनेटवरील प्रत्येक scanner ला अंदाजाने तपासता येतो. key based authentication वापरा. त्यानंतर असे अंदाज लावणे निरर्थक ठरते. key pair तयार करा, public key स्थापित करा आणि इतर कोणताही बदल करण्यापूर्वी दुसऱ्या terminal मधून key ने login होत असल्याची खात्री करा. SSH key व्यवस्थापनाची मूलतत्त्वे येथे generation, authorized_keys आणि passphrases यांचे वर्णन आहे.

त्यानंतर password authentication बंद करा. तुम्ही संपादित केलेल्या file वर अवलंबून न राहता sudo sshd -T वापरून ते बंद असल्याची खात्री करा. VPS वरील SSH hardening मध्ये बदलण्यासारख्या उर्वरित sshd settings चे वर्णन आहे. नवीन VPS वरील पहिली दहा मिनिटे fresh server वर हे बदल कोणत्या क्रमाने करायचे ते सांगते.

त्यानंतर एक password जतन ठेवा. sshd config मध्ये त्रुटी असलेल्या key-only server ला फक्त provider console द्वारे access करता येते. त्या console साठी username आणि password आवश्यक असतो. तुम्ही सुरक्षितपणे जतन केलेला strong password असलेले account पाच मिनिटांत दुरुस्ती करता येईल की पुन्हा installation करावे लागेल, हे ठरवते.

FAQ

माझ्या VPS वरील root password मला माहीत नसेल, तर तो कसा बदलू?

sudo चालवू शकणाऱ्या user म्हणून लॉग इन करा आणि sudo passwd root चालवा. जुना password विचारला जात नाही, कारण sudo ने तुमचे authentication आधीच केलेले असते. त्या सिस्टमवरील कोणत्याही account कडून sudo चालवता येत नसेल, तर provider console उघडा, GRUB recovery menu मध्ये reboot करा, root shell entry निवडा, mount -o remount,rw / चालवा आणि त्यानंतर passwd चालवा. root ला आधीपासून password असल्यास आणि तुम्ही तोच विसरला असल्यास, recovery shell तो password विचारेल. अशा वेळी provider ची rescue image वापरावी लागते; disk mount करून chroot करावा लागतो.

passwd मध्ये "Authentication token manipulation error" असे का दिसते?

या संदेशाची दोन कारणे असू शकतात. सामान्य कारण म्हणजे Current password: prompt ला दिलेले चुकीचे उत्तर. त्याखालील passwd: password unchanged line मध्ये काहीही लिहिले गेले नसल्याचे स्पष्ट होते. दुसरे कारण म्हणजे write करता न येणारी filesystem. Recovery mode मध्ये ही समस्या येते, कारण तेथे / read-only mount केलेले असते. mount -o remount,rw / चालवा आणि पुन्हा प्रयत्न करा.

माझा Linux password बदलल्यावर sudo password देखील बदलतो का?

होय. sudo चा स्वतःचा password नसतो. तो PAM मार्फत SSH आणि su वापरत असलेल्या त्याच /etc/shadow entry विरुद्ध तुमचे authentication करतो. त्यामुळे प्रत्येक account साठी एकच password असतो. म्हणूनच password बदलल्यानंतर दिसणारा पहिला sudo prompt ही खरी चाचणी असते. कार्यरत session असतानाच तो prompt सक्तीने दाखवण्यासाठी sudo -k && sudo -v चालवा.

माझा password बदलल्यावर माझ्या SSH keys किंवा उघड्या sessions वर परिणाम होईल का?

Password change किंवा passwd -l यामुळे परिणाम होत नाही. Public key authentication password hash तपासत नाही. त्यामुळे यापैकी कोणतीही कृती केल्यानंतर keys कार्यरत राहतात. chage -d 0 मात्र वेगळे आहे. Key login नंतर sshd PAM account checks चालवत राहतो. हे checks /etc/shadow मधील password aging fields वाचतात. त्यामुळे password expired असल्यास key login वेगळा password मागतो आणि scripted SSH commands अयशस्वी होतात. आधीपासून उघड्या असलेल्या sessions सुरूच राहतात, कारण SSH credentials फक्त login वेळी तपासतो. Live session मध्ये बदलणारी एकमेव गोष्ट म्हणजे sudo. त्याचा 15 minute timestamp संपल्यानंतर ते नवीन password एकदा विचारते.

पुढील login वेळी user ने password बदलावा यासाठी सक्ती कशी करावी?

sudo chage -d 0 deploy चालवा किंवा sudo passwd -e deploy चालवा. दोन्ही कृती एकच परिणाम करतात. Stored last-change date epoch वर सेट केली जाते. PAM password expired मानतो. त्यानंतरच्या interactive login वेळी shell सुरू होण्यापूर्वी नवीन password सेट करावा लागतो. SSH द्वारे scripts वापरणाऱ्या account वर हे करू नका. अशा वेळी non-interactive command Password change required but no TTY available. सह अयशस्वी होते आणि चालतच नाही.