ناقابلِ بھروسا VPN پر آپ کا SSH پاس ورڈ اصل میں کون دیکھتا ہے؟

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

کچھ بھی لکھنے سے پہلے وصول کنندہ کا نام لیں

پاس ورڈ کا خانہ تصدیق کے پیغام کے اندر سفر کرتا ہے، اور وہ پیغام خفیہ کردہ ترسیل کے اندر سفر کرتا ہے۔ رازداری ترسیل کی خاصیت ہے، یعنی یہ اس پر منحصر ہے کہ تحفظ پر بات چیت ہوئی ہے اور وہ اُسی ہوسٹ کے ساتھ ہوئی ہے جس کا آپ نے ارادہ کیا تھا۔ لوگ بالکل یہی دوسرا نصف چھوڑ دیتے ہیں۔ کسی دھوکے باز کی طرف خفیہ کردہ رابطہ بیک وقت رازدارانہ اور بے کار ہوتا ہے۔ VPN میں لاگ ان SSH ہوسٹ کے بارے میں کچھ ثابت نہیں کرتا، اور فراہم کنندہ کی ساکھ کلید کی جانچ کا نعم البدل نہیں ہے۔

دونوں سمتوں کو ذہن میں الگ رکھیں۔ ہوسٹ کی کلید بتاتی ہے کہ آپ کس سرور تک پہنچے۔ پاس ورڈ یا کلید کی تصدیق بتاتی ہے کہ سرور کس صارف کو قبول کرتا ہے۔ دوسرے کی بہتری پہلے کو کبھی درست نہیں کرتی۔

ہوسٹ کی شناخت، ریکارڈ اور بات چیت کی جانچ کریں

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

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

سرور کی طرف، جن فنگر پرنٹس کو آپ شائع کرنا چاہتے ہیں اُنہیں یادداشت سے نقل کرنے کے بجائے چھاپیں۔ اُنہیں چینل سے باہر تقسیم کرنا ہی اصل بات ہے؛ ہوسٹ نام والے اُسی چیٹ چینل سے چسپاں کیا گیا فنگر پرنٹ صرف یہ ثابت کرتا ہے کہ دونوں ایک ہی جگہ سے آئے ہیں۔

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

سرور واقعی کن طریقوں کو قبول کرتا ہے، پڑھیں

سرور کن تصدیقی طریقوں کی اجازت دیتا ہے، یہ جاننا بتاتا ہے کہ پاس ورڈ اصل میں کس لیے ہے۔ جو ہوسٹ صرف عوامی کلیدیں قبول کرتا ہے اُس کے پاس بچانے کے قابل پاس ورڈ کی تبدیلی نہیں، اور جو ہوسٹ اب بھی پاس ورڈ قبول کرتا ہے وہ وراثتی طے شدہ کے بجائے سوچے سمجھے فیصلے کا حقدار ہے۔

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

کسی صارف کو کلید کی تصدیق پر منتقل کرنا اُس صارف کا پاس ورڈ اُس تبدیلی سے ہٹا دیتا ہے۔ یہ بھنگ ہوئے ورک اسٹیشن کو محفوظ نہیں کرتا، اور ناقابلِ بھروسا دور دراز سیشن کو بے ضرر نہیں کرتا۔ یہ مختلف کنٹرول والے مختلف خطرات ہیں۔ ایجنٹ کی ترسیل کا بھی فیصلہ کریں۔ ناقابلِ بھروسا ہوسٹ کو ایجنٹ بھیجنا اُس ہوسٹ کو سیشن کے دوران آپ کی کلیدیں استعمال کرنے کی صلاحیت دیتا ہے، اور یہ اُس پاس ورڈ والے سوال سے بڑا انکشاف ہے جس سے سب کچھ شروع ہوا تھا۔

ہوسٹ کلید کی وارننگ کو واقعے کے مرحلے کی طرح نمٹائیں

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

اگر ہوسٹ قانونی طور پر دوبارہ بنایا گیا تھا، تو پرانا اندراج صرف نئے فنگر پرنٹ کی تصدیق کے بعد ہٹائیں، پھر دوبارہ جڑیں اور بات چیت دوبارہ جانچیں۔ تبدیلی کو تاریخ اور وجہ کے ساتھ درج کریں، کیونکہ اگلا شخص وہی وارننگ دیکھے گا اور اُسے جاننا ضروری ہے کہ یہ حل ہو چکی ہے۔

یہ رہنما کیا نہیں سمیٹتا

ٹریفک دیکھنے والا VPN آپریٹر آپ کی مشین پر مقامی اختیارات رکھنے والے سافٹ ویئر کے برابر نہیں ہے۔ اینڈ پوائنٹ کا بھنگ، دشمن براؤزر ایکسٹینشن یا کی بورڈ لاگر SSH کی بات چیت سے نیچے ہوتے ہیں، اور کوئی سرنگ یہ نہیں بدلتی۔ اگر ورک اسٹیشن مشکوک ہو، تو کسی اور اخراج سے دوبارہ جڑ کر رازداری پرکھنے کے بجائے واقعے کا طریقہ کار اپنائیں۔ دوبارہ جڑنا ثابت کرتا ہے کہ نیٹ ورکی راستہ بدلا ہے، اور اینڈ پوائنٹ کے بارے میں کچھ نہیں۔

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