OpenVPN سسٹم ڈی کا پاس ورڈ درخواست کا انتظار کر رہا ہے: کیا جواب دینا چاہیے؟
سسٹم ڈی کا پاس ورڈ پرامپٹ کسی سروس کی درخواست ہے، گیٹ وے کا فیصلہ نہیں۔ طے کریں کہ کون سا راز مانگا جا رہا ہے اور کس نے جواب دینا چاہیے۔
ٹرمینل میں systemd-tty-ask-password-agent کے بارے میں پیغام ظاہر ہوتا ہے، اور ٹنل قائم نہیں ہے۔ دلکش تشریح یہ ہے کہ VPN نے پاس ورڈ مسترد کیا اور اب کچھ اصلاح کا انتظار کر رہا ہے۔ زیادہ درست یہ ہے کہ کسی سروس نے systemd سے متعامل اِن پٹ طلب کی ہے، اور درخواست کا ابھی جواب نہیں دیا گیا۔ کون سی سروس نے پوچھا اور کون سا راز چاہیے، یہ دو سوال ہیں جو آپ کچھ بھی لکھنے سے پہلے طے کر سکتے ہیں۔
کس نے جواب دینا چاہیے، یہ دو شرطیں طے کرتی ہیں
پہلی شرط یہ ہے کہ کیا آپ نے یہ انسٹینس جان بوجھ کر شروع کیا تھا۔ آپ کے کسی عمل کے بعد آنے والی درخواست آپ کی ہے، اور بغیر متعلقہ عمل کے ظاہر ہونے والی درخواست کسی اور چیز کی ہے۔ دوسری یہ ہے کہ راز اکاؤنٹ کی توثیق ہے یا کلید کی حفاظت، کیونکہ یہ الگ الگ جگہوں پر رہتے ہیں اور الگ کوڈ راستوں سے گزرتے ہیں۔ عمل کرنے سے پہلے دیکھیں تو دونوں جواب جرنل میں نظر آتے ہیں۔
جب دونوں جواب واضح ہوں تو فیصلہ سادہ ہے: سروس کے اپنے معاون پرامپٹ راستے سے جواب دیں۔ جب کوئی ایک غیر واضح ہو تو درست قدم تحقیق کرنا ہے، ایسے پرامپٹ میں پاس ورڈ لکھنا نہیں جسے آپ منسوب نہیں کر سکتے۔
یہی پورا اصول ہے، اور احکام سے پہلے یہ کہنا مناسب ہے۔ نیچے سب کچھ اسی سے نکلتا ہے۔
کچھ بھی لکھنے سے پہلے درخواست کی فہرست دیکھیں
ایجنٹ کسی کو جواب دیے بغیر فہرست بنا سکتا ہے کہ کیا باقی ہے۔ sudo systemd-tty-ask-password-agent --list باقی درخواستیں چھاپتا ہے، اور وہی آؤٹ پٹ وہ ثبوت ہے جو پرامپٹ کو یونٹ سے جوڑنے کے لیے درکار ہے۔ اسناد دینے سے پہلے اسے پڑھیں، اور درخواستوں کی تفصیلات کسی بھی عوامی تشخیصی پیسٹ سے باہر رکھیں۔
فہرست کو اس عمل سے اور اس یونٹ سے جوڑیں جس کی وہ ملکیت ہے۔ اگر فہرست میں کچھ بھی آپ کے عمل سے نہیں ملتا، تو جو پرامپٹ آپ نے دیکھا وہ کسی اور سروس کا ہے اور اسے حل کرنا آپ کا کام نہیں۔ فہرست میں یونٹ کا نام ہی پرامپٹ اور سروس کے درمیان واحد قابلِ بھروسہ ربط ہے۔
ایسی درخواست کا جواب نہ دیں جسے آپ منسوب نہیں کر سکتے۔ انتظار کی قیمت تاخیر ہے، جبکہ غلط پرامپٹ کا جواب دینے کی قیمت غلط جگہ پر اسناد ہے۔
انسٹینس کو واقعی کون سا راز درکار ہے؟
auth-user-pass VPN سروس سے اکاؤنٹ کی توثیق سے متعلق ہے، اور اسناد کی فائل کے بغیر دستاویزی رویہ کنسول پر پوچھنا ہے۔ askpass اس کے بجائے وہ پاس فریز حاصل کرتا ہے جو محفوظ کلید مواد کھولتی ہے، اور یہ عمل پس منظر میں جانے سے پہلے کرتا ہے۔ یہ مختلف عمر والے مختلف راز ہیں۔
فائل کی صورتیں بھی مختلف ہیں۔ اکاؤنٹ کی صورت ایک صارف نام کی سطر اور ایک پاس ورڈ کی سطر کی توقع کرتی ہے، جبکہ کلید کی پاس فریز فائل پہلی سطر کو اپنا پاس ورڈ سمجھ کر پڑھتی ہے۔ دوسرے کردار کی اسناد فائل کی ترکیب نقل کرنا عام طور پر حل کے بجائے ایک اور پرامپٹ پیدا کرتا ہے۔ غلط شکل کی فائل فائل نہ ہونے سے بدتر ہے، کیونکہ ناکامی ایسی جگہ منتقل ہو جاتی ہے جہاں کوئی نگرانی نہیں کرتا۔
یہ طے کرنے سے پہلے کہ کیا لکھنا ہے، دیکھیں کہ انسٹینس کون سی ہدایت استعمال کرتا ہے۔ ہدایت کا نام ہی بتاتا ہے کہ پرامپٹ کس راز کے لیے ہے۔
--query کیا کرتا ہے جو --list نہیں کرتا
--query کال کرنے والے ٹرمینل پر ہر باقی درخواست پر کارروائی کرتا ہے، جو ایک پرامپٹ کا جواب دینے سے کہیں زیادہ وسیع عمل ہے۔ یہ OpenVPN کا انتخاب کنندہ نہیں ہے، اور مصروف مشین پر یہ دوسرے یونٹوں کی درخواستوں کا بھی جواب دے سکتا ہے۔ نگرانی کا موڈ اس سے بھی وسیع ہے، کیونکہ یہ درخواستیں آتے ہی ان پر کارروائی جاری رکھتا ہے۔
وہ سب سے تنگ طریقہ استعمال کریں جو کام کرے۔ ایک سروس کے لیے، اس سروس کا اپنا پرامپٹ بہاؤ عالمی ایجنٹ سے تنگ ہے، اور جواب کو پوچھنے والے یونٹ سے منسلک رکھتا ہے۔
ایک بار اطلاع ظاہر ہونے کی وجہ سے ایک بار کی درخواست کو بے نگرانی عالمی ایجنٹ بنانا — اسی طرح عارضی تکلیف مستقل ڈیزائن بن جاتی ہے۔ یہی احتیاط پورے ہوسٹ پر پاس ورڈ اطلاع یونٹوں کو غیر فعال کرنے پر بھی لاگو ہوتی ہے۔
فیصلہ کریں، پھر انتخاب درج کریں
بے نگرانی تعیناتی کے لیے، کنکشن کے مالک کے ساتھ اسناد کا ماخذ، فائل کی اجازتیں اور تجدید کا شیڈول طے کریں۔ متعامل دوسرے عنصر کے لیے کسی شخص یا مخصوص سروس شناخت کی ضرورت ہو سکتی ہے۔ پرامپٹ کو دبانے سے وہ توثیق پیدا نہیں ہوتی، اور auth-user-pass ہٹانے سے صرف وہی سروس ٹوٹتی ہے جسے اس کی ضرورت ہے۔
تعامل کے بعد اسی انسٹینس کا اگلا واقعہ دیکھیں اور نجی وسیلہ آزمائیں۔ اگر کچھ باقی نہ ہو، تو ہوسٹ پر ہر OpenVPN یونٹ شروع کرنے کے بجائے انسٹینس کی حالت پر واپس جائیں۔