Ubuntu پر VPS کا root پاس ورڈ کیسے تبدیل کریں

Ubuntu پر اپنے VPS کے root پاس ورڈ کو کیسے تبدیل کریں

Ubuntu پر اپنے VPS (virtual private server) کے root پاس ورڈ کو تبدیل کرنے کے لیے ایسے صارف کے طور پر SSH (secure shell) سیشن کھولیں جو sudo چلا سکتا ہو، پھر sudo passwd root چلائیں۔ یہ نیا پاس ورڈ دو مرتبہ مانگتا ہے اور پرانا پاس ورڈ نہیں مانگتا، کیونکہ sudo پہلے ہی آپ کی شناخت کی تصدیق کر چکا ہے۔ اس کے بجائے اپنا login پاس ورڈ تبدیل کرنے کے لیے passwd بغیر arguments کے چلائیں۔ اس صورت میں یہ پہلے موجودہ پاس ورڈ مانگتا ہے۔

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

پورا عمل یہی ہے۔ ذیل میں ان صورتوں کی وضاحت ہے جہاں عموماً مسئلہ پیش آتا ہے: اس سیشن سے محروم ہونے سے پہلے نئے پاس ورڈ کے کام کرنے کی تصدیق کرنا جو مسئلہ حل کر سکتا ہے، script سے پاس ورڈ set کرنا، کسی پاس ورڈ کو جان بوجھ کر expire کرنا، اور پاس ورڈ پہلے ہی ضائع ہو جانے پر دوبارہ access حاصل کرنا۔

دوسرا سیشن کھولیں، پھر password تبدیل کریں

اب دوسرا SSH سیشن کھولیں اور اسے connected رہنے دیں۔ اس گائیڈ میں تقریباً ہر failure اس وقت دو منٹ میں درست ہو جاتی ہے جب ایک authenticated shell ابھی بھی active ہو۔ آخری سیشن بند ہونے کے بعد console تک جانا پڑ سکتا ہے۔

جو shell پہلے سے open ہو، وہ اس کے متعلقہ account کو change، lock یا expire کرنے کے بعد بھی کام کرتی رہتی ہے، کیونکہ SSH credentials کو login کے وقت check کرتا ہے اور اس کے بعد دوبارہ check نہیں کرتا۔ استثنا sudo ہے۔ timestamp expire ہونے کے بعد یہ PAM (pluggable authentication modules) کے ذریعے آپ کا password دوبارہ check کرتا ہے۔ یہ مدت default طور پر آخری prompt کے 15 منٹ بعد ختم ہوتی ہے۔ اس لیے نئے password کا پہلا حقیقی test login کے وقت نہیں، بلکہ اگلی بار sudo کے password طلب کرنے پر ہوتا ہے۔

پہلا سیشن open رکھتے ہوئے دوسرے سیشن میں نیا password test کریں۔

passwd سے اپنا password تبدیل کریں

passwd

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

passwd: password updated successfully ہی وہ واحد output ہے جس کا مطلب ہے کہ /etc/shadow میں موجود hash تبدیل کر دیا گیا ہے۔ اس کے علاوہ کوئی بھی output پرانا password برقرار رہنے کی نشاندہی کرتا ہے۔

یہاں دو failures ہوتی ہیں۔ passwd: Authentication token manipulation error کے بعد passwd: password unchanged کا آنا اس بات کی نشاندہی کرتا ہے کہ آپ نے موجودہ password غلط درج کیا ہے، یا /etc/shadow رکھنے والا filesystem لکھنے کے قابل نہیں ہے، جو recovery mode میں معمول کی حالت ہے۔ You must choose a longer password.، /etc/pam.d/common-password میں موجود pam_unix سے پیدا ہوتا ہے، جو عام users کے لیے length اور similarity checks نافذ کرتا ہے۔

زیادہ تر VPS images میں default account (ubuntu، یا provider کی جانب سے فراہم کردہ کوئی بھی نام) کے پاس کوئی password نہیں ہوتا، صرف SSH key ہوتی ہے۔ passwd کے پاس جانچنے کے لیے کوئی موجودہ password نہیں ہوتا، اس لیے وہ پہلے prompt سے آگے نہیں بڑھ سکتا۔ اس کے بجائے sudo passwd $USER استعمال کریں، کیونکہ image کی sudoers drop-in file اس account کو password کے بغیر sudo چلانے کی اجازت دیتی ہے۔

sudo passwd سے کسی دوسرے صارف کا پاس ورڈ تبدیل کریں

sudo passwd deploy

root سے پرانا پاس ورڈ نہیں پوچھا جاتا، اور pam_unix وہ strength checks نظرانداز کرتا ہے جو عام صارفین پر لاگو ہوتے ہیں۔ اس لیے root ایسا پاس ورڈ مقرر کر سکتا ہے جو صارف خود اپنے لیے مقرر نہیں کر سکتا تھا۔

اکاؤنٹ کو lock کرنا الگ کارروائی ہے۔ sudo passwd -l deploy محفوظ شدہ hash کے آغاز میں ! شامل کرتا ہے، اس لیے کوئی پاس ورڈ اس سے مطابقت نہیں رکھتا۔ sudo passwd -u deploy اسے ہٹا دیتا ہے۔ sudo passwd -S deploy سے موجودہ state دوبارہ پڑھیں۔

پاس ورڈ lock کرنے سے اس صارف کا login بند نہیں ہوتا۔ اس کے ~/.ssh/authorized_keys میں موجود کوئی بھی key اب بھی کام کرتی ہے، کیونکہ public key authentication کبھی /etc/shadow نہیں پڑھتا۔ کسی account کو مکمل طور پر روکنے کے لیے خود account کو expire کریں:

sudo usermod --expiredate 1 deploy

اس سے account expiry کی تاریخ 1970 پر مقرر ہو جاتی ہے، لہٰذا sshd پیش کی جانے والی credential سے قطع نظر login مسترد کر دیتا ہے۔ اسے واپس کرنے کے لیے sudo usermod --expiredate '' deploy استعمال کریں۔

passwd -d سے گریز کریں۔ یہ account کو lock کرنے کے بجائے خالی پاس ورڈ مقرر کرتا ہے، اور جس پرانے release میں PAM stack کے اندر nullok اب بھی موجود ہو، وہاں خالی پاس ورڈ ہر شخص استعمال کر سکتا ہے۔

کیا VPS پر root کے لیے password ضروری ہے؟

Ubuntu میں root account locked ہوتا ہے۔ /etc/shadow میں hash کی جگہ ! موجود ہوتا ہے، اور sudo passwd -S root ایسی line دکھاتا ہے جو root L سے شروع ہوتی ہے۔ جب تک آپ root کے لیے password set نہ کریں، کوئی بھی password کے ذریعے root کے طور پر login نہیں کر سکتا۔ اسی لیے image آپ کو sudo کی صلاحیت رکھنے والا user فراہم کرتی ہے۔ root کے بجائے VPS پر کم سے کم مراعات والے user accounts کے ذریعے کام کرنے کا طریقہ برقرار رکھیں۔

root password set کرنے سے ایک مخصوص سہولت ملتی ہے: provider console کے ذریعے داخل ہونے کا راستہ۔ یہ console network stack کے نیچے virtual machine سے منسلک ہوتا ہے، اس لیے sshd کی configuration غلط ہونے یا firewall rule میں مسئلہ ہونے کے باوجود کام کرتا رہتا ہے۔ تاہم اس کی ایک قیمت بھی ہے۔ جب root کے لیے password موجود ہو تو GRUB recovery menu کا root shell وہ password طلب کرتا ہے۔ یوں بھولا ہوا password reset کرنے کا tool اسی password کے پیچھے چلا جاتا ہے۔

root password set کرنے سے root کو SSH کے ذریعے login کرنے کی اجازت نہیں ملتی۔ Ubuntu میں PermitRootLogin prohibit-password موجود ہوتا ہے، جس کا مطلب ہے کہ صرف keys استعمال ہوتی ہیں۔ معلوم کریں کہ آپ کا server حقیقت میں کیا استعمال کر رہا ہے:

sudo sshd -T | grep -i permitrootlogin

sshd -T ہر Include line کے حل ہونے کے بعد مؤثر configuration دکھاتا ہے۔ اس لیے جب /etc/ssh/sshd_config.d/ drop-in files رکھتا ہو تو یہی واحد قابلِ اعتماد جواب ہے۔

اسکرپٹ کے ذریعے chpasswd سے پاس ورڈ مقرر کریں

passwd ٹرمینل سے input لیتا ہے اور اسے اسکرپٹ کے ذریعے نہیں چلایا جا سکتا۔ chpasswd standard input سے ہر سطر میں ایک user:password pair پڑھتا ہے۔

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 پاس ورڈ دو مرتبہ طلب کرتا ہے اور اسے ظاہر نہیں کرتا، پھر $6$ سے شروع ہونے والا SHA-512 crypt hash پرنٹ کرتا ہے۔ -e، chpasswd کو بتاتا ہے کہ دوسرا field پہلے ہی hashed ہے، اس لیے اسے جوں کا توں /etc/shadow میں copy کر دیا جاتا ہے۔ اس hash کو repository یا CI variable میں محفوظ رکھنا محفوظ ہے، اور plaintext اس machine سے باہر نہیں جاتا جہاں آپ نے اسے type کیا تھا۔

Ubuntu 24.04 نئے پاس ورڈز کو yescrypt ($y$) سے hash کرتا ہے جب passwd انہیں مقرر کرتا ہے، جبکہ openssl passwd -6 آپ کو SHA-512 دیتا ہے۔ login کے وقت دونوں کی verification ہو جاتی ہے، کیونکہ libxcrypt دونوں formats پڑھتا ہے۔ انہیں ملانا درست ہے، اور openssl passwd -6 ہر Ubuntu LTS release پر یکساں کام کرتا ہے؛ chpasswd -c YESCRYPT ایسا نہیں کرتا، کیونکہ 20.04 کا پرانا shadow package اس method name کو نہیں جانتا۔ یہ hashes release upgrade کے بعد بھی برقرار رہتے ہیں، اس لیے 24.04 server کو 26.04 پر منتقل کرنے سے کسی کا پاس ورڈ reset کرنا ضروری نہیں ہوتا۔

پاس ورڈ واقعی تبدیل ہوا ہے یا نہیں، یہ کیسے جانچیں؟

پہلے metadata دیکھیں، پھر login کے ذریعے اس کی تصدیق کریں۔

sudo passwd -S deploy

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

دوسرا field state ظاہر کرتا ہے: قابل استعمال پاس ورڈ کے لیے P، locked پاس ورڈ کے لیے L، اور بالکل پاس ورڈ نہ ہونے کی صورت میں NP۔ تاریخ بتاتی ہے کہ پاس ورڈ آخری بار کب تبدیل ہوا تھا، اس لیے اس میں آج کی تاریخ ہونی چاہیے۔ اس کے بعد موجود numbers نیچے بیان کیے گئے aging fields ہیں۔

سب سے محفوظ live test خود sudo ہے۔ sudo -k cached timestamp ختم کر دیتا ہے، جبکہ sudo -v نیا prompt لازمی دکھاتا ہے۔ اگر نیا پاس ورڈ وہاں قبول ہو جائے تو PAM نے اسے قبول کیا ہے، اور آپ کے موجودہ session میں کوئی تبدیلی نہیں ہوئی۔

sudo -k && sudo -v

کسی دوسرے account کی جانچ کے لیے unprivileged shell سے su - deploy چلائیں۔ sudo su - deploy نہ چلائیں، کیونکہ root سے کبھی پاس ورڈ نہیں مانگا جاتا اور اس test سے کچھ ثابت نہیں ہوتا۔ غلط پاس ورڈ پر su: Authentication failure ظاہر ہوتا ہے۔

اصل test آپ کے 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 پیش کی، لیکن آپ کا درج کیا ہوا پاس ورڈ مسترد کر دیا۔

اگلے لاگ اِن پر password تبدیل کرنے کے لیے chage استعمال کریں

sudo chage -d 0 deploy

-d 0 آخری تبدیلی کی تاریخ کو epoch پر مقرر کرتا ہے، اس لیے PAM password کو expired سمجھتا ہے۔ اگلے interactive لاگ اِن پر shell دینے سے پہلے موجودہ password، پھر نیا password طلب کیا جاتا ہے۔ sudo passwd -e deploy بھی بالکل یہی کام کرتا ہے۔

اسے صرف ان accounts کے لیے استعمال کریں جو password کے ذریعے interactive لاگ اِن کرتے ہیں۔ Expired password key-based لاگ اِن کو بھی متاثر کرتا ہے، کیونکہ authentication کے لیے key استعمال ہونے کے باوجود sshd، PAM کا account stage چلاتا ہے۔ اس کے بعد scripted 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) سے مراد پاس ورڈ کی میعاد ختم ہونے کے بعد رعایتی مدت ہے، جس کے اختتام پر پاس ورڈ مکمل طور پر ناقابلِ قبول ہو جاتا ہے۔ اکاؤنٹ کی میعاد (chage -E) ایک قطعی تاریخ ہوتی ہے اور یہ پاس ورڈ سے الگ ہوتی ہے۔

sudo chage -M 90 -W 14 deploy

اسے صرف اس وقت مقرر کریں جب پالیسی میں اس کی ضرورت ہو۔ NIST (امریکہ کا National Institute of Standards and Technology) نے 2017 سے معمول کے مطابق پاس ورڈ کی میعاد ختم کرنے کے خلاف مشورہ دیا ہے، کیونکہ اس سے لوگ ایک ہی پاس ورڈ کی قابلِ پیش گوئی تبدیلیاں استعمال کرنے لگتے ہیں۔ NIST اس کے بجائے اس وقت پاس ورڈ تبدیل کرنے پر مجبور کرنے کی سفارش کرتا ہے جب پاس ورڈ کے compromise ہونے کا ثبوت موجود ہو۔ password manager میں محفوظ کیا گیا طویل اور منفرد پاس ورڈ، اس کے ساتھ key based SSH، 90 دن کے cycle سے زیادہ مؤثر ہے۔

جب root password کھو جائے تو کیا کریں

اگر machine پر کوئی بھی account sudo چلا سکتا ہو تو password 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 سے server reboot کریں اور console monitor کریں۔
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 موجود ہے اور آپ نے وہی 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

Partition layout lsblk سے معلوم کریں؛ اس صفحے سے /dev/vda1 نقل نہ کریں۔ root partition سب سے بڑی partition ہوتی ہے۔ UEFI image میں اس کے ساتھ ایک چھوٹی EFI partition ہوتی ہے، جس میں /etc directory بالکل نہیں ہوتی۔

جب SSH آپ کا پاس ورڈ قبول کرنا بند کر دے تو کیا کریں

اس session سے کام کریں جو اب بھی موجود ہے۔ اگر کوئی session باقی نہیں رہا تو console استعمال کریں۔

Permission denied, please try again. کا مطلب ہے کہ سرور نے password authentication پیش کی، لیکن آپ کی بھیجی ہوئی قدر مسترد کر دی۔ عام وجوہات میں caps lock کا فعال ہونا یا console کا keyboard layout اس layout سے مختلف ہونا شامل ہے جس کے ذریعے آپ نے پاس ورڈ مقرر کیا تھا۔

Permission denied (publickey). کا مطلب ہے کہ سرور نے password authentication پیش ہی نہیں کی۔ PasswordAuthentication no کہیں نہ کہیں set ہے، اور Ubuntu 22.04 اور اس کے بعد کے ورژنز میں یہ عموماً /etc/ssh/sshd_config.d/ کے تحت موجود drop-in file میں ہوتی ہے، جو main file کی settings کو override کرتی ہے۔ مؤثر values دیکھیں:

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

KbdInteractiveAuthentication yes کو PasswordAuthentication no کے ساتھ فعال رکھنے سے بھی پاس ورڈ کے ذریعے login ممکن رہتا ہے، کیونکہ keyboard-interactive method وہی PAM stack چلاتا ہے۔ ایک method کو بند اور دوسرے کو فعال رکھنا اس بات کی وجہ ہے کہ بظاہر key-only سرور typed passwords قبول کرتا رہتا ہے۔

Disconnect message میں Too many authentication failures کا مطلب ہے کہ client نے password تک پہنچنے سے پہلے کئی keys پیش کیں، اور سرور MaxAuthTries تک پہنچ گیا، جو default طور پر 6 ہے۔ صرف ایک method زبردستی استعمال کریں:

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

ایک ایسے port پر Connection refused جو ایک منٹ پہلے کام کر رہا تھا، عموماً اس بات کی نشاندہی کرتا ہے کہ fail2ban کا SSH پر نظر رکھنا repeated failures کے بعد آپ کے 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 کرتا ہے۔

Passwords عارضی مرحلہ ہیں، keys آخری حالت ہیں

SSH پر کام کرنے والا password وہ password ہے جسے انٹرنیٹ پر موجود ہر scanner اندازے سے آزما سکتا ہے۔ key based authentication استعمال کریں، پھر یہ guessing اہم نہیں رہے گی۔ key pair بنائیں، public key انسٹال کریں، اور دوسری terminal سے تصدیق کریں کہ key کے ذریعے login ہو رہا ہے، اس سے پہلے کہ کوئی اور تبدیلی کریں۔ SSH keys کے انتظام کی بنیادی باتیں میں generation، authorized_keys اور passphrases کا احاطہ کیا گیا ہے۔

اس کے بعد password authentication بند کریں، اور ترمیم کی گئی file پر بھروسا کرنے کے بجائے sudo sshd -T سے اس کی تصدیق کریں۔ VPS پر SSH کو harden کرنا ان sshd settings کا جائزہ لیتا ہے جنہیں تبدیل کرنا مفید ہے، جبکہ نئے VPS کے پہلے دس منٹ ایک fresh server پر انہیں نافذ کرنے کی ترتیب بتاتا ہے۔

اس کے بعد ایک password ضرور محفوظ رکھیں۔ ٹوٹے ہوئے sshd config والے key-only server تک صرف provider console کے ذریعے رسائی ممکن ہوتی ہے، اور اس console کے لیے username اور password درکار ہوتے ہیں۔ ایک ایسا account جس کا strong password آپ نے محفوظ کر رکھا ہو، پانچ منٹ میں fix کرنے اور دوبارہ installation کے درمیان فرق پیدا کرتا ہے۔

FAQ

اگر مجھے پرانا پاس ورڈ معلوم نہ ہو تو اپنے VPS پر root پاس ورڈ کیسے تبدیل کروں؟

ایسے صارف کے طور پر لاگ ان کریں جو sudo چلا سکتا ہو، پھر sudo passwd root چلائیں۔ یہ پرانا پاس ورڈ پوچھے بغیر نیا پاس ورڈ مقرر کرتا ہے، کیونکہ sudo پہلے ہی آپ کی تصدیق کر چکا ہے۔ اگر سسٹم پر کوئی بھی اکاؤنٹ sudo نہ چلا سکتا ہو تو provider console کھولیں، GRUB recovery menu میں reboot کریں، root shell entry منتخب کریں، mount -o remount,rw / چلائیں، پھر passwd چلائیں۔ اگر root کے لیے پہلے سے پاس ورڈ مقرر ہے اور آپ وہی بھول گئے ہیں تو recovery shell وہ پاس ورڈ مانگے گا۔ ایسی صورت میں باقی راستہ provider کی rescue image استعمال کرنا ہے، جس میں disk کو mount کرکے chroot کیا جاتا ہے۔

passwd یہ پیغام "Authentication token manipulation error" کیوں دکھاتا ہے؟

یہ پیغام دو وجوہات کی بنا پر آتا ہے۔ عام وجہ Current password: prompt پر غلط جواب دینا ہے، اور اس کے نیچے موجود passwd: password unchanged لائن تصدیق کرتی ہے کہ کچھ بھی نہیں لکھا گیا۔ دوسری وجہ ایسی filesystem ہے جس پر لکھا نہیں جا سکتا۔ recovery mode میں یہی مسئلہ درپیش ہوتا ہے، کیونکہ وہاں / read-only mount ہوتی ہے۔ mount -o remount,rw / چلائیں اور دوبارہ کوشش کریں۔

کیا میرا Linux پاس ورڈ تبدیل کرنے سے sudo پاس ورڈ بھی تبدیل ہو جاتا ہے؟

ہاں۔ sudo کا اپنا کوئی پاس ورڈ نہیں ہوتا۔ یہ PAM کے ذریعے اسی /etc/shadow entry کے خلاف آپ کی تصدیق کرتا ہے جسے SSH اور su بھی استعمال کرتے ہیں، اس لیے ہر اکاؤنٹ کے لیے ایک ہی پاس ورڈ ہوتا ہے۔ اسی وجہ سے تبدیلی کے بعد پہلا sudo prompt اصل جانچ ہوتا ہے۔ جب تک آپ کا session فعال ہے، اس prompt کو لازمی دکھانے کے لیے sudo -k && sudo -v چلائیں۔

کیا پاس ورڈ تبدیل کرنے سے میری SSH keys یا کھلے ہوئے sessions متاثر ہوں گے؟

نہیں۔ Public key authentication کبھی /etc/shadow کو نہیں پڑھتی، اس لیے پاس ورڈ تبدیل کرنے، passwd -l کے بعد، اور chage -d 0 کے بعد بھی keys کام کرتی رہیں گی۔ پہلے سے کھلے ہوئے sessions بھی فعال رہیں گے، کیونکہ SSH credentials صرف login کے وقت چیک کرتا ہے۔ فعال session میں صرف sudo کا رویہ تبدیل ہوتا ہے؛ 15 منٹ کا timestamp ختم ہونے کے بعد یہ نیا پاس ورڈ ایک بار مانگتا ہے۔

میں کسی صارف کو اگلے login پر پاس ورڈ تبدیل کرنے پر کیسے مجبور کروں؟

sudo chage -d 0 deploy چلائیں، یا sudo passwd -e deploy چلائیں؛ دونوں ایک ہی کام کرتے ہیں۔ محفوظ شدہ last-change date کو epoch پر منتقل کر دیا جاتا ہے، PAM پاس ورڈ کو expired سمجھتا ہے، اور اگلے interactive login پر shell شروع ہونے سے پہلے نیا پاس ورڈ مقرر کرنا ضروری ہوتا ہے۔ یہ کام ایسے اکاؤنٹ کے ساتھ نہ کریں جسے scripts SSH کے ذریعے استعمال کرتی ہوں۔ ایسی صورت میں non-interactive command Password change required but no TTY available. کے ساتھ fail ہو جاتی ہے اور چلتی ہی نہیں۔