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 सुरू असताना दोन मिनिटांत दुरुस्त करता येते. शेवटचे सत्र बंद झाल्यानंतर मात्र console पर्यंत जावे लागू शकते.

आधीच उघडलेला shell त्याच्याशी संबंधित account मध्ये बदल, lock किंवा expire केल्यानंतरही कार्यरत राहतो. कारण SSH login वेळी credentials तपासते आणि त्यानंतर पुन्हा तपासत नाही. याला अपवाद sudo आहे. त्याचा timestamp कालबाह्य झाल्यावर ते PAM (pluggable authentication modules) मार्फत तुमचा password पुन्हा तपासते. हे default नुसार शेवटच्या prompt नंतर 15 minutes ने होते. त्यामुळे नवीन 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 सामान्य वापरकर्त्यांसाठी लागू असलेल्या पासवर्डची मजबुती तपासण्या वगळते. त्यामुळे root असा पासवर्ड सेट करू शकतो, जो वापरकर्ता स्वतःसाठी सेट करू शकला नसता.

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

पासवर्ड लॉक केल्याने त्या वापरकर्त्याचे login थांबत नाही. त्याच्या ~/.ssh/authorized_keys मधील कोणतीही key अद्याप कार्य करते, कारण public key authentication /etc/shadow वाचत नाही. खाते पूर्णपणे थांबवण्यासाठी स्वतः 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

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

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

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

passwd पासवर्ड सेट करते तेव्हा Ubuntu 24.04 नवीन पासवर्डसाठी yescrypt ($y$) वापरते, तर openssl passwd -6 तुम्हाला SHA-512 देते. Login वेळी दोन्हींची पडताळणी होते, कारण libxcrypt दोन्ही formats वाचते. त्यांना एकत्र वापरणे योग्य आहे. तसेच openssl passwd -6 प्रत्येक Ubuntu LTS release वर सारखेच कार्य करते; chpasswd -c YESCRYPT मात्र तसे करत नाही: 20.04 मधील जुन्या shadow package ला त्या method name ची माहिती नाही. हे hashes release jump नंतरही कायम राहतात. त्यामुळे 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 वरही परिणाम होतो, कारण authentication साठी key वापरली असली तरी sshd PAM account stage चालवतो. Script मधील ssh deploy@203.0.113.10 'systemctl restart app' यानंतर या error मुळे fail होते आणि थांबते:

Password change required but no TTY available.

त्या line नंतरचे कोणतेही काम चालत नाही. Job मध्ये फक्त 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) म्हणजे 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 सुरू असणे किंवा password सेट करताना वापरलेल्या keyboard layout पेक्षा console वरील keyboard layout वेगळा असणे.

Permission denied (publickey). याचा अर्थ सर्व्हरने password authentication उपलब्ध करून दिले नाही. PasswordAuthentication no कुठेतरी set केलेले आहे. Ubuntu 22.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये ते सहसा /etc/ssh/sshd_config.d/ अंतर्गत असलेल्या drop-in file मध्ये असते आणि मुख्य file मधील setting override करते. प्रभावी values वाचा:

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

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

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

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

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

एका मिनिटापूर्वी कार्यरत असलेल्या port वर Connection refused दिसत असल्यास, repeated failures नंतर fail2ban SSH वर लक्ष ठेवून तुमचा address ban केलेला असण्याची शक्यता आहे. त्याचा default ban rule packet drop करण्याऐवजी reject करतो. त्यामुळे refusal timeout होण्याऐवजी लगेच परत येतो. 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 म्हणून login करा आणि sudo passwd root चालवा. जुन्या password ची मागणी न करता हा command नवीन password सेट करतो, कारण sudo ने तुमचे authentication आधीच केलेले असते. त्या server वरील कोणतेही account sudo चालवू शकत नसल्यास, provider console उघडा, GRUB recovery menu मध्ये reboot करा, root shell entry निवडा, mount -o remount,rw / चालवा आणि नंतर passwd चालवा. root कडे आधीपासून password असल्यास आणि तुम्ही तोच विसरला असल्यास recovery shell त्या password ची मागणी करते. अशा वेळी disk mount करून chroot केलेली provider ची rescue image वापरणे हा उरलेला मार्ग आहे.

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

माझा password बदलल्यावर SSH keys किंवा सुरू असलेली sessions बंद होतील का?

नाही. Public key authentication /etc/shadow कधीही वाचत नाही. त्यामुळे password बदलल्यानंतर, passwd -l नंतर आणि chage -d 0 नंतरही keys कार्यरत राहतात. आधीच सुरू असलेली sessions सुरूच राहतात, कारण SSH credentials फक्त login वेळी तपासते. सुरू असलेल्या session मध्ये बदलणारी एकमेव गोष्ट म्हणजे sudo. त्याचा 15 minute timestamp संपल्यानंतर ते नवीन password एकदा विचारते.

पुढील login वेळी एखाद्या user ने password बदलणे सक्तीचे कसे करायचे?

sudo chage -d 0 deploy किंवा sudo passwd -e deploy चालवा. दोन्ही commands एकच परिणाम करतात. 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. मुळे अयशस्वी होतो आणि चालतच नाही.