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

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

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

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

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

پاس ورڈ میں تبدیلی سے پہلے دوسرا سیشن کھولیں

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

جو shell پہلے سے کھلا ہو، وہ اس اکاؤنٹ کو تبدیل، lock یا expire کرنے کے بعد بھی کام کرتا رہتا ہے جس سے وہ وابستہ ہے، کیونکہ SSH لاگ اِن کے وقت credentials چیک کرتا ہے اور دوبارہ چیک نہیں کرتا۔ استثنا sudo ہے۔ اس کے timestamp کی مدت ختم ہونے پر یہ PAM (pluggable authentication modules) کے ذریعے آپ کا پاس ورڈ دوبارہ چیک کرتا ہے۔ پہلے سے طے شدہ طور پر یہ مدت آخری prompt کے 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 میں موجود hash تبدیل کر دیا گیا ہے۔ کسی بھی دوسرے آؤٹ پٹ کا مطلب ہے کہ پرانا پاس ورڈ برقرار ہے۔

یہاں دو خرابیاں پیش آتی ہیں۔ passwd: Authentication token manipulation error کے بعد passwd: password unchanged ظاہر ہونے کا مطلب ہے کہ آپ کا درج کردہ موجودہ پاس ورڈ غلط تھا، یا وہ filesystem جس میں /etc/shadow موجود ہے، اس میں لکھا نہیں جا سکتا۔ recovery mode میں یہی معمول کی حالت ہے۔ You must choose a longer password.، /etc/pam.d/common-password میں موجود pam_unix سے آتا ہے۔ یہ عام users کے لیے لمبائی اور مماثلت کی جانچ لاگو کرتا ہے۔

زیادہ تر VPS images میں default account (ubuntu، یا آپ کے provider کی فراہم کردہ کوئی اور نام) کے پاس کوئی پاس ورڈ نہیں ہوتا، صرف 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 کو مکمل طور پر روکنے کے لیے خود account کو expire کریں:

sudo usermod --expiredate 1 deploy

اس سے account کی expiry تاریخ 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 کے طور پر لاگ اِن نہیں کر سکتا۔ اسی لیے image آپ کو sudo کی صلاحیت رکھنے والا صارف فراہم کرتی ہے۔ root کے بجائے VPS پر کم سے کم مراعات والے صارف اکاؤنٹس کے ذریعے کام کرنا ہی برقرار رکھنے کے قابل طریقہ ہے۔

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

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

sudo sshd -T | grep -i permitrootlogin

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

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

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

Ubuntu 24.04، passwd کے ذریعے نئے پاس ورڈ مقرر کرتے وقت انہیں yescrypt ($y$) سے hash کرتا ہے، جبکہ openssl passwd -6 آپ کو SHA-512 دیتا ہے۔ login کے وقت دونوں کی تصدیق ہو جاتی ہے، کیونکہ libxcrypt دونوں formats پڑھتا ہے۔ انہیں ملانا درست ہے، اور openssl passwd -6 ہر Ubuntu LTS release پر یکساں طریقے سے کام کرتا ہے، لیکن chpasswd -c YESCRYPT ایسا نہیں کرتا: 20.04 کا پرانا shadow package اس method name کو نہیں پہچانتا۔

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

پہلے میٹا ڈیٹا دیکھیں، پھر لاگ اِن کے ذریعے اس کی تصدیق کریں۔

sudo passwd -S deploy

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

دوسرا فیلڈ حالت ظاہر کرتا ہے: قابلِ استعمال پاس ورڈ کے لیے P، مقفل پاس ورڈ کے لیے L، اور مکمل طور پر غیر موجود پاس ورڈ کے لیے NP۔ تاریخ وہ دن ہے جب پاس ورڈ آخری بار تبدیل ہوا تھا، اس لیے اس میں آج کی تاریخ ہونی چاہیے۔ اس کے بعد موجود اعداد، نیچے بیان کردہ عمر سے متعلق فیلڈز ہیں۔

براہِ راست جانچنے کا محفوظ ترین طریقہ خود sudo ہے۔ sudo -k محفوظ شدہ ٹائم اسٹیمپ حذف کرتا ہے، جبکہ sudo -v تازہ پرامپٹ کو لازمی بناتا ہے۔ اگر نیا پاس ورڈ وہاں قبول ہو جائے تو PAM نے اسے قبول کر لیا ہے، اور آپ کے سیشن میں کوئی تبدیلی نہیں ہوئی۔

sudo -k && sudo -v

کسی دوسرے اکاؤنٹ کی جانچ کے لیے، غیر مراعات یافتہ shell سے su - deploy چلائیں۔ sudo su - deploy نہ چلائیں، کیونکہ root سے کبھی پاس ورڈ نہیں پوچھا جاتا اور اس جانچ سے کچھ ثابت نہیں ہوتا۔ غلط پاس ورڈ su: Authentication failure دکھاتا ہے۔

اصل جانچ آپ کے laptop سے نیا SSH لاگ اِن ہے، جبکہ موجودہ سیشن کھلا رہے:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

یہاں Permission denied (publickey). کا مطلب ہے کہ سرور نے پاس ورڈ کے ذریعے authentication کی پیشکش ہی نہیں کی، اس لیے پاس ورڈ تبدیل کرنے سے آپ لاگ اِن نہیں ہو سکیں گے۔ Permission denied, please try again. کا مطلب ہے کہ سرور نے یہ سہولت پیش کی، لیکن آپ کا درج کردہ پاس ورڈ مسترد کر دیا۔

chage کے ذریعے اگلے لاگ اِن پر پاس ورڈ تبدیل کرنے کو لازمی بنائیں

sudo chage -d 0 deploy

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

اسے صرف ان اکاؤنٹس کے لیے استعمال کریں جو پاس ورڈ کے ذریعے interactive لاگ اِن کرتے ہیں۔ میعاد ختم شدہ پاس ورڈ key based لاگ اِن کو بھی متاثر کرتا ہے، کیونکہ key سے تصدیق ہونے کے باوجود sshd، PAM کا account مرحلہ چلاتا ہے۔ اس کے بعد scripted ssh deploy@203.0.113.10 'systemctl restart app' اس پیغام کے ساتھ ناکام ہو جاتا ہے اور رک جاتا ہے:

Password change required but no TTY available.

اس سطر کے بعد کچھ بھی نہیں چلتا، اور 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) وہ وقت متعین کرتے ہیں جب لاگ اِن کے دوران انتباہ دکھانا شروع ہوتا ہے۔ غیرفعال دن (chage -I) پاس ورڈ کی میعاد ختم ہونے کے بعد رعایتی مدت ہے، جس کے بعد پاس ورڈ مکمل طور پر مسترد کر دیا جاتا ہے۔ اکاؤنٹ کی میعاد (chage -E) ایک قطعی تاریخ ہے اور یہ پاس ورڈ سے آزاد ہوتی ہے۔

sudo chage -M 90 -W 14 deploy

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

root پاس ورڈ کھو جانے پر کیا کریں

اگر سرور پر موجود کوئی بھی اکاؤنٹ sudo چلا سکتا ہے تو پاس ورڈ بازیافت کرنے کی ضرورت نہیں: sudo passwd root نیا پاس ورڈ مقرر کر دیتا ہے۔ مشکل صورت یہ ہے کہ کوئی بھی لاگ اِن کام نہ کر رہا ہو۔

ذیل کے تمام مراحل کے لیے provider console درکار ہے، جسے زیادہ تر پینلز میں VNC (virtual network computing) یا serial console کہا جاتا ہے۔ یہ virtual machine سے network stack کے نیچے براہِ راست جڑتا ہے، اس لیے sshd کی ترتیبات اور firewall rules اس پر اثر انداز نہیں ہوتے۔

1. پینل سے server کو reboot کریں اور console کی نگرانی کریں۔
2. GRUB menu کھولیں۔ Cloud images عام طور پر GRUB_TIMEOUT=0 مقرر کرتی ہیں، اس لیے BIOS boot پر reboot شروع ہوتے ہی Shift کو دبائے رکھیں، یا UEFI boot پر Esc کو بار بار دبائیں۔
3. Advanced options for Ubuntu منتخب کریں، پھر اس entry کو منتخب کریں جو (recovery mode) پر ختم ہوتی ہے، اور اس کے بعد 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 چلائیں، پھر پینل سے 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

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

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

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

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

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

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

KbdInteractiveAuthentication yes کو PasswordAuthentication no کے ساتھ فعال رکھنے سے بھی پاس ورڈ کے ذریعے رسائی ممکن رہتی ہے، کیونکہ keyboard-interactive طریقہ وہی PAM stack چلاتا ہے۔ ایک طریقہ بند اور دوسرا فعال چھوڑنے سے ایسا server بنتا ہے جو بظاہر صرف key authentication استعمال کرتا ہے، لیکن ٹائپ کیے گئے پاس ورڈ قبول کرتا رہتا ہے۔

disconnect message میں Too many authentication failures کا مطلب ہے کہ آپ کے client نے password تک پہنچنے سے پہلے کئی keys پیش کیں، اور server کو MaxAuthTries کی حد تک رسائی ہو گئی، جو بطور ڈیفالٹ 6 ہے۔ صرف ایک طریقہ استعمال کرنے پر مجبور کریں:

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

کسی ایسے port پر Connection refused جو ایک منٹ پہلے کام کر رہا تھا، عموماً اس بات کی نشاندہی کرتا ہے کہ SSH کو monitor کرنے والے fail2ban نے بار بار ناکام کوششوں کے بعد آپ کے address پر پابندی لگا دی ہے۔ اس کا default ban rule packet کو drop کرنے کے بجائے reject کرتا ہے، اسی لیے refusal فوراً واپس آتا ہے اور timeout نہیں ہوتا۔ console سے sudo fail2ban-client status sshd پابندی زدہ addresses دکھاتا ہے، جبکہ sudo fail2ban-client set sshd unbanip 203.0.113.10 آپ کا address صاف کرتا ہے۔

پاس ورڈز عبوری مرحلہ ہیں، keys آخری حالت ہیں

SSH پر کام کرنے والا پاس ورڈ ایسا پاس ورڈ ہے جسے انٹرنیٹ پر موجود ہر scanner آزما سکتا ہے۔ key based authentication پر منتقل ہوں، اور یہ اندازے لگانا بے معنی ہو جائے گا۔ ایک key pair بنائیں، public حصے کو انسٹال کریں، اور کچھ بھی تبدیل کرنے سے پہلے دوسرے terminal سے تصدیق کریں کہ key آپ کو لاگ اِن کرتی ہے۔ SSH key management basics میں generation، authorized_keys اور passphrases کا احاطہ کیا گیا ہے۔

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

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

FAQ

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

ایسے صارف کے طور پر لاگ ان کریں جو sudo چلا سکتا ہو، پھر sudo passwd root چلائیں۔ یہ پرانا پاس ورڈ پوچھے بغیر نیا پاس ورڈ مقرر کرتا ہے، کیونکہ sudo پہلے ہی آپ کی تصدیق کر چکا ہے۔ اگر server پر کوئی بھی account 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 line تصدیق کرتی ہے کہ کچھ بھی لکھا نہیں گیا۔ دوسری وجہ ایسا filesystem ہے جس پر لکھا نہیں جا سکتا۔ recovery mode میں یہی مسئلہ پیش آتا ہے، کیونکہ وہاں / read-only کے طور پر mounted ہوتا ہے۔ mount -o remount,rw / چلائیں اور دوبارہ کوشش کریں۔

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

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

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

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

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

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