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

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

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

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

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

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

ابھی ایک دوسرا SSH سیشن کھولیں اور اسے کنیکٹ رہنے دیں۔ اس گائیڈ میں پیش آنے والی تقریباً ہر خرابی کو دو منٹ میں ٹھیک کیا جا سکتا ہے اگر ایک تصدیق شدہ (authenticated) شیل کھلا ہو، جبکہ آخری سیشن بند ہونے کے بعد آپ کو کنسول تک رسائی کے لیے فزیکل وزٹ کرنا پڑ سکتا ہے۔

جو شیل پہلے سے کھلا ہو وہ اس اکاؤنٹ کا پاس ورڈ تبدیل، لاک یا ایکسپائر کرنے کے بعد بھی کام کرتا رہتا ہے، کیونکہ SSH صرف لاگ ان کے وقت اسناد (credentials) کی جانچ کرتا ہے اور دوبارہ نہیں کرتا۔ اس کا استثنا 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 drop-in فائل اس اکاؤنٹ کو بغیر پاس ورڈ کے sudo چلانے کی اجازت دیتی ہے۔

sudo passwd کا استعمال کرتے ہوئے کسی دوسرے صارف کا پاس ورڈ تبدیل کرنا

sudo passwd deploy

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

اکاؤنٹ کو لاک کرنا ایک الگ عمل ہے۔ sudo passwd -l deploy ذخیرہ شدہ ہیش (stored hash) کے شروع میں ایک ! لگا دیتا ہے، جس کی وجہ سے کوئی بھی پاس ورڈ اس سے میچ نہیں کرتا۔ sudo passwd -u deploy اسے ہٹا دیتا ہے۔ اکاؤنٹ کی حالت جانچنے کے لیے sudo passwd -S deploy کا استعمال کریں۔

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

sudo usermod --expiredate 1 deploy

یہ کمانڈ اکاؤنٹ کی میعاد ختم ہونے کی تاریخ 1970 میں سیٹ کر دیتی ہے، لہذا sshd کسی بھی قسم کا کریڈینشل پیش کیے جانے پر لاگ ان سے انکار کر دیتا ہے۔ اسے واپس درست کرنے کے لیے sudo usermod --expiredate '' deploy استعمال کریں۔

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

کیا VPS پر root کے لیے پاس ورڈ کی ضرورت ہے؟

Ubuntu میں root اکاؤنٹ مقفل (locked) آتا ہے۔ /etc/shadow میں ہیش (hash) کی جگہ ! موجود ہوتا ہے، اور sudo passwd -S root ایک ایسی لائن پرنٹ کرتا ہے جو root L سے شروع ہوتی ہے۔ جب تک آپ خود پاس ورڈ سیٹ نہ کریں، کوئی بھی root کے طور پر پاس ورڈ کے ذریعے لاگ ان نہیں ہو سکتا، اسی لیے سرور امیج آپ کو sudo کی صلاحیت رکھنے والا ایک صارف فراہم کرتی ہے۔ VPS پر کم سے کم استحقاق والے صارف اکاؤنٹس کے ذریعے کام کرنا ہی وہ طریقہ کار ہے جسے برقرار رکھنا چاہیے۔

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/ میں drop-in فائلیں موجود ہوں تو یہی واحد درست جواب ہوتا ہے۔

chpasswd کے ذریعے اسکرپٹ سے پاس ورڈ سیٹ کرنا

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

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

یہ طریقہ کام کرتا ہے، لیکن یہ آپ کے شیل ہسٹری اور CI (continuous integration) لاگز میں سادہ متن (plaintext) میں پاس ورڈ ڈال دیتا ہے۔ اس کے بجائے پہلے اسے ہیش کریں:

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

openssl passwd -6 دو بار پاس ورڈ مانگتا ہے بغیر اسے اسکرین پر دکھائے، اور پھر SHA-512 کرپٹ ہیش پرنٹ کرتا ہے جو $6$ سے شروع ہوتا ہے۔ -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 پیکیج اس میتھڈ کے نام کو نہیں جانتا۔ یہ ہیشز ریلیز اپ گریڈ کے بعد بھی برقرار رہتے ہیں، لہذا 24.04 سرور کو 26.04 پر منتقل کرنا آپ کو کسی کا پاس ورڈ ری سیٹ کرنے پر مجبور نہیں کرتا۔

پاس ورڈ کی تبدیلی کی تصدیق کیسے کریں؟

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

sudo passwd -S deploy

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

دوسرا فیلڈ اسٹیٹ (state) ہے: P قابل استعمال پاس ورڈ کے لیے، L لاک شدہ کے لیے، اور NP بغیر پاس ورڈ کے لیے۔ تاریخ وہ ہے جب پاس ورڈ آخری بار تبدیل ہوا تھا، لہذا اس پر آج کی تاریخ ہونی چاہیے۔ اس کے بعد کے نمبر aging فیلڈز ہیں جن کی تفصیل نیچے دی گئی ہے۔

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

sudo -k && sudo -v

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

اصل ٹیسٹ آپ کے لیپ ٹاپ سے ایک نیا 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 پاس ورڈ کو expired سمجھتا ہے۔ اگلی انٹرایکٹو لاگ ان پر، شیل تک رسائی دینے سے پہلے، موجودہ پاس ورڈ اور پھر ایک نیا پاس ورڈ طلب کیا جاتا ہے۔ sudo passwd -e deploy بالکل یہی کام کرتا ہے۔

اسے صرف ان اکاؤنٹس کے لیے استعمال کریں جو پاس ورڈ کے ساتھ انٹرایکٹو لاگ ان کرتے ہیں۔ پاس ورڈ کا expired ہونا key-based لاگ ان کو بھی متاثر کرتا ہے، کیونکہ sshd اس وقت بھی PAM اکاؤنٹ کا مرحلہ چلاتا ہے جب authentication کسی 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 تک ہیں۔ Minimum days (chage -m) وہ وقت ہے جس تک صارف کو دوبارہ پاس ورڈ تبدیل کرنے کے لیے انتظار کرنا پڑتا ہے، یہ کسی کو زبردستی تبدیلی کے فوراً بعد پرانے پاس ورڈ پر واپس جانے سے روکتا ہے۔ Maximum days (chage -M) وہ مدت ہے جس تک پاس ورڈ کارآمد رہتا ہے۔ Warning days (chage -W) وہ وقت ہے جب لاگ ان کے دوران انتباہ (warning) ظاہر ہونا شروع ہو جاتا ہے۔ Inactive days (chage -I) میعاد ختم ہونے کے بعد کی وہ مہلت ہے جس کے بعد پاس ورڈ مکمل طور پر ناقابل قبول ہو جاتا ہے۔ Account expiry (chage -E) ایک حتمی تاریخ ہے، اور یہ پاس ورڈ سے آزاد ہے۔

sudo chage -M 90 -W 14 deploy

اسے صرف تب سیٹ کریں جب کوئی پالیسی اس کا تقاضا کرے۔ NIST (امریکی نیشنل انسٹی ٹیوٹ آف اسٹینڈرڈز اینڈ ٹیکنالوجی) نے 2017 سے معمول کے مطابق پاس ورڈ کی میعاد ختم کرنے کے خلاف مشورہ دیا ہے، کیونکہ یہ لوگوں کو ایک ہی پاس ورڈ کی قابلِ پیشگوئی تبدیلیاں کرنے پر مجبور کرتا ہے، اور جب سمجھوتہ (compromise) کے شواہد موجود ہوں تو پاس ورڈ تبدیل کرنے پر مجبور کرنے کی سفارش کرتا ہے۔ پاس ورڈ مینیجر میں محفوظ ایک طویل منفرد پاس ورڈ، اور ساتھ میں key-based 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 آپ کا پاس ورڈ قبول کرنا بند کر دے تو کیا کریں

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

Permission denied, please try again. کا مطلب ہے کہ سرور نے پاس ورڈ کی تصدیق (authentication) کی پیشکش کی لیکن آپ کے بھیجے گئے پاس ورڈ کو مسترد کر دیا۔ عام وجوہات میں Caps Lock کا آن ہونا، یا کنسول کا کی بورڈ لے آؤٹ ہونا ہے جو اس لے آؤٹ سے مختلف ہے جسے آپ نے پاس ورڈ سیٹ کرتے وقت استعمال کیا تھا۔

Permission denied (publickey). کا مطلب ہے کہ سرور نے کبھی پاس ورڈ کی تصدیق کی پیشکش ہی نہیں کی۔ PasswordAuthentication no کہیں سیٹ کیا گیا ہے، اور Ubuntu 22.04 اور بعد کے ورژنز میں یہ عام طور پر /etc/ssh/sshd_config.d/ کے تحت ایک drop-in فائل میں موجود ہوتا ہے جو مرکزی فائل کو اوور رائیڈ (override) کر دیتی ہے۔ مؤثر اقدار (effective values) پڑھیں:

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

KbdInteractiveAuthentication yes کے ساتھ PasswordAuthentication no اب بھی پاس ورڈ کو قبول کرنے دیتا ہے، کیونکہ keyboard-interactive طریقہ کار وہی PAM اسٹیک چلاتا ہے۔ ایک کو بند کر کے دوسرے کو کھلا چھوڑ دینا ہی وہ طریقہ ہے جس سے ایک ایسا سرور جو صرف کیز (keys) والا لگتا ہے، ٹائپ کیے گئے پاس ورڈز کو قبول کرتا رہتا ہے۔

یہی لائن وہ ہے جو مسترد شدہ کی لاگ ان (rejected key login) پر بھی پرنٹ ہوتی ہے، لہذا اگر آپ پاس ورڈ کے بجائے کی (key) پیش کر رہے تھے، تو سرور کی پاس ورڈ سیٹنگ Permission denied (publickey) کے پیچھے موجود پانچ نقائص میں سے صرف ایک ہے، اور ssh -v آؤٹ پٹ آپ کو بتاتا ہے کہ آپ کو کون سا مسئلہ درپیش ہے۔

ڈس کنیکٹ پیغام میں Too many authentication failures کا مطلب ہے کہ آپ کے کلائنٹ نے پاس ورڈ تک پہنچنے سے پہلے کئی کیز پیش کیں، اور سرور 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 آپ کے ایڈریس کو کلیئر کر دیتا ہے۔

پاس ورڈز ایک ابتدائی قدم ہیں، جبکہ کیز (keys) حتمی منزل ہیں

SSH پر کام کرنے والا پاس ورڈ ایسا پاس ورڈ ہے جسے انٹرنیٹ پر موجود ہر اسکینر اندازے سے معلوم کرنے کی کوشش کرتا ہے۔ کی بیسڈ (key-based) تصدیق پر منتقل ہو جائیں تاکہ اندازے لگانے کی اہمیت ختم ہو جائے۔ ایک کی پیئر (key pair) جنریٹ کریں، پبلک حصہ انسٹال کریں، اور کسی دوسری ٹرمینل ونڈو سے تصدیق کریں کہ کی (key) آپ کو لاگ ان کر رہی ہے، اس سے پہلے کہ آپ کوئی اور تبدیلی کریں۔ SSH کی مینجمنٹ کی بنیادی باتیں میں جنریشن، authorized_keys اور پاس فریزز (passphrases) کا احاطہ کیا گیا ہے۔

اس کے بعد پاس ورڈ کی تصدیق کو بند کر دیں، اور اس کی تصدیق sudo sshd -T کے ذریعے کریں، بجائے اس کے کہ صرف اس فائل پر بھروسہ کریں جسے آپ نے ایڈٹ کیا ہے۔ VPS پر SSH کو محفوظ بنانا ان باقی sshd سیٹنگز پر کام کرتا ہے جنہیں تبدیل کرنا فائدہ مند ہے، اور نئے VPS پر ابتدائی دس منٹ انہیں اس ترتیب میں رکھتا ہے جس میں ایک نئے سرور پر عمل کیا جانا چاہیے۔

اس کے بعد ایک پاس ورڈ ضرور رکھیں۔ خراب sshd کنفیگریشن والا کی-اونلی (key-only) سرور صرف پرووائیڈر کنسول کے ذریعے ہی قابل رسائی ہوتا ہے، اور وہ کنسول صارف کا نام اور پاس ورڈ مانگتا ہے۔ ایک مضبوط پاس ورڈ والا اکاؤنٹ، جسے آپ نے محفوظ کر رکھا ہو، وہی چیز ہے جو پانچ منٹ کی اصلاح اور دوبارہ انسٹالیشن کے درمیان فرق پیدا کرتی ہے۔

FAQ

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

ایسے صارف کے طور پر لاگ ان کریں جو sudo چلا سکتا ہو اور sudo passwd root چلائیں۔ یہ پرانے پاس ورڈ کے بارے میں پوچھے بغیر نیا پاس ورڈ سیٹ کر دیتا ہے، کیونکہ sudo آپ کو پہلے ہی تصدیق (authenticate) کر چکا ہوتا ہے۔ اگر سرور پر کوئی بھی اکاؤنٹ 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 یا کھلے ہوئے سیشنز ختم ہو جائیں گے؟

نہیں۔ پبلک کی اتھنٹیکیشن کبھی بھی /etc/shadow کو نہیں پڑھتی، لہذا پاس ورڈ تبدیل کرنے، passwd -l کے بعد، اور chage -d 0 کے بعد بھی keys کام کرتی رہتی ہیں۔ جو سیشنز پہلے سے کھلے ہیں وہ کھلے ہی رہیں گے، کیونکہ SSH صرف لاگ ان کے وقت اسناد (credentials) چیک کرتا ہے۔ لائیو سیشن کے اندر صرف ایک چیز تبدیل ہوتی ہے اور وہ ہے sudo، جو 15 منٹ کا ٹائم اسٹیمپ ختم ہونے کے بعد نیا پاس ورڈ مانگتا ہے۔

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

sudo chage -d 0 deploy چلائیں، یا sudo passwd -e deploy، جو وہی کام کرتا ہے۔ آخری تبدیلی کی تاریخ epoch پر منتقل ہو جاتی ہے، PAM پاس ورڈ کو ایکسپائر سمجھتا ہے، اور اگلا انٹرایکٹو لاگ ان شیل شروع ہونے سے پہلے نیا پاس ورڈ سیٹ کرنے کا مطالبہ کرتا ہے۔ ایسا اس اکاؤنٹ کے ساتھ نہ کریں جو SSH کے ذریعے اسکرپٹس کے لیے استعمال ہوتا ہے: بصورت دیگر نان-انٹرایکٹو کمانڈ Password change required but no TTY available. کے ساتھ ناکام ہو جائے گی اور کبھی نہیں چلے گی۔