OpenVPN systemd च्या पासवर्ड विनंतीची वाट पाहत आहे: उत्तर द्यावे का?

टर्मिनलमध्ये 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 युनिट सुरू करण्याऐवजी इन्स्टन्सच्या स्थितीकडे परत जा।