Linux पर AnyConnect: लॉगिन क्रम को सुरक्षित रूप से स्क्रिप्ट करना

Cisco AnyConnect के साथ आने वाला vpn क्लाइंट बातचीत की तरह व्यवहार करता है: यह एक प्रॉम्प्ट छापता है, एक पंक्ति की प्रतीक्षा करता है, फिर अगला छापता है। उस बातचीत को किसी फ़ाइल या पाइप से खिलाएँ और वही बाइनरी बिना निगरानी के चलती है। तकनीक एक रीडायरेक्ट और उत्तरों की क्रमबद्ध सूची है, और स्क्रिप्ट भरोसेमंद है या नहीं यह रीडायरेक्ट नहीं, वही सूची तय करती है।

व्यवहार में दो चीज़ें इसे तोड़ती हैं। जब गेटवे कुछ अतिरिक्त पूछता है तो प्रॉम्प्ट का क्रम बदल जाता है, और संग्रहीत पासवर्ड एक टाइपिंग गलती को खाता लॉकआउट में बदल देता है। क्रम को संस्करणित डेटा की तरह देखें जिसे किसी भी गेटवे बदलाव के बाद तुलना कर सकें। दोबारा कोशिश करने के बजाय ज़ोर से विफल हों, क्योंकि लूप ही वह तरीका है जिससे गलत टाइप किया गया पासवर्ड लॉक हुए खाते में बदल जाता है।

एक क्रम, उसी क्रम में जिसमें क्लाइंट पूछता है

क्लाइंट को एक बार इंटरैक्टिव रूप से चलाएँ और हर प्रॉम्प्ट को उसी क्रम में लिखें जिसमें वह दिखता है। वही ट्रांसक्रिप्ट उत्तर-फ़ाइल बन जाती है। जब आप फ़ाइल को बाइनरी में रीडायरेक्ट करते हैं तो पहली पंक्ति को स्वयं कनेक्शन कमांड होना चाहिए, इसीलिए क्रम उपयोगकर्ता नाम के बजाय होस्टनाम से शुरू होता है।

connect vpn.example.com
0
<username>
<password>
y
exit

खाली 0 तब पहला कनेक्शन प्रोफ़ाइल चुनता है जब गेटवे सूची देता है; जो इंडेक्स आपका गेटवे छापता है वही इस्तेमाल करें। y लॉगिन बैनर स्वीकार करता है, इसलिए बैनर न हो तो वह पंक्ति हटा दें और जहाँ आपका गेटवे अतिरिक्त प्रश्न पूछता है वहाँ एक पंक्ति जोड़ें। अंत में exit वही है जो अंतिम उत्तर खर्च होने पर क्लाइंट को साफ़ तौर पर समाप्त होने देता है।

/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

गैर-इंटरैक्टिव मोड यहाँ वैकल्पिक नहीं है। -s के बिना क्लाइंट टर्मिनल पर कब्ज़ा कर सकता है और रीडायरेक्ट किए गए इनपुट को अनदेखा कर सकता है; इसके साथ उत्तर स्ट्रीम से पढ़े जाते हैं और प्रक्रिया लौट आती है। जहाँ बाइनरी को बढ़े हुए विशेषाधिकार चाहिए, वहाँ कॉल को sudo -n में लपेटें ताकि स्क्रिप्ट पासवर्ड प्रॉम्प्ट पर अटकने के बजाय तुरंत विफल हो।

उत्तर-फ़ाइल कहाँ रिसती है

पासवर्ड वाली फ़ाइल एक क्रेडेंशियल है, इसलिए उसे क्रेडेंशियल की अनुमतियाँ दें: मोड 600, उस खाते के स्वामित्व में जो कार्य चलाता है, और कभी भी साझा या सिंक की गई निर्देशिका में नहीं। बाद में ठीक करने के बजाय मोड पहले से लागू करके बनाएँ, क्योंकि लिखने और chmod के बीच फ़ाइल कुछ पल के लिए सभी के पढ़ने योग्य होती है।

install -m 600 /dev/null ~/.config/anyconnect.txt
chmod 700 ~/.config

दूसरा आधा argv है। तर्क के रूप में दिया गया पासवर्ड हर उस स्थानीय उपयोगकर्ता को दिखता है जो प्रक्रियाएँ सूचीबद्ध करता है, और यह शेल इतिहास में भी पहुँच जाता है। इसके बजाय इसे फ़ाइल डिस्क्रिप्टर या पर्यावरण चर से पढ़ें, और पेलोड को कोट करें ताकि शेल उसके भीतर कुछ भी विस्तारित न कर सके।

printf '%s\n' 'connect vpn.example.com' '0' "$VPN_USER" "$VPN_PASS" 'y' 'exit' \
  | sudo -n /opt/cisco/anyconnect/bin/vpn -s

कोटिंग पर ध्यान दें। दोहरे कोट के भीतर ! वाला पासवर्ड क्लाइंट के देखने से पहले ही इंटरैक्टिव शेल द्वारा विस्तारित हो सकता है, और विफलता प्रोटोकॉल समस्या जैसी दिखने वाली सामान्य event-not-found त्रुटि के रूप में आती है।

टनल सिद्ध करें, फिर बंद करें

कनेक्टेड स्थिति केवल यह सिद्ध करती है कि क्लाइंट मानता है कि उसका सत्र है। ऐसा होस्ट चुनें जो केवल कॉर्पोरेट नेटवर्क के भीतर से उत्तर दे और कुछ और करने से पहले उसे एक बार जाँचें। वहाँ विफलता रूटिंग या नीति की खराबी है, और लॉगिन दोबारा चलाने से वह नहीं बदलेगी।

/opt/cisco/anyconnect/bin/vpn state
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 10 https://<internal-host>/
/opt/cisco/anyconnect/bin/vpn disconnect

डिस्कनेक्ट से पहले और बाद में स्टेट आउटपुट जाँचें। पुराने सत्र के साथ छोड़ा गया क्लाइंट अगले कनेक्शन से इनकार कर सकता है जबकि स्क्रिप्ट अभी भी सफलता की रिपोर्ट करती है, और यह विफलता-प्रकार अदृश्य है यदि आप केवल एग्ज़िट कोड देखें। दूसरी रीडिंग पर अकेले भरोसा करने के बजाय दोनों की तुलना करें। शेल प्रोफ़ाइल में एलियास रोज़मर्रा के उपयोग के लिए पर्याप्त हैं, जबकि निर्धारित किया गया कोई भी काम किसी अन्य बिना निगरानी वाले काम जितनी ही क्रेडेंशियल और पहचान समीक्षा का हक़दार है।

जब स्थिर सूची सुरक्षित रहना बंद कर दे

उत्तर-फ़ाइल आज के प्रॉम्प्ट क्रम को कूटबद्ध करती है। बदला हुआ बैनर, ज़बरदस्ती पासवर्ड परिवर्तन या दूसरे-कारक की चुनौती उसे ऐसे लूप में बदल देती है जो खाता लॉक कर सकता है, इसलिए स्क्रिप्ट को पुनः आरंभ करने के बजाय पहले अप्रत्याशित उत्तर पर बाहर निकलना चाहिए।

क्लाइंट ने जो छापा उसे कैप्चर करें, गैर-शून्य स्थिति लौटाएँ और निर्णय कॉलर पर छोड़ें। जहाँ गेटवे दूसरा कारक माँगता है, ईमानदार उत्तर यह है कि उस प्रोफ़ाइल के लिए बिना निगरानी वाला लॉगिन उपलब्ध नहीं है, यह नहीं कि क्रम को एक और पंक्ति चाहिए।

रोटेशन भी उसी समीक्षा का हिस्सा है। यदि क्रेडेंशियल संग्रहीत है, तय करें कि कौन उसे पढ़ सकता है, वह कब बदलता है और होस्ट के पुनर्निर्माण पर उसे क्या हटाता है। जो स्क्रिप्ट एक साल चलती है क्योंकि किसी ने पासवर्ड को छुआ नहीं, वह डिज़ाइन नहीं है, बल्कि रोटेशन नीति की प्रतीक्षा करती एक दुर्घटना है।

जो प्रोफ़ाइल AnyConnect नहीं हैं

Cisco की दो पुरानी क्रेडेंशियल शैलियाँ इससे मिला दी जाती हैं। vpnc प्रोफ़ाइल IPSec ID माँगता है, जो वास्तव में समूह का नाम है, फिर समूह रहस्य, फिर आपके अपने क्रेडेंशियल, और तीनों उसी से आते हैं जो गेटवे चलाता है। पुराना Cisco IPsec AnyConnect से अलग प्रोटोकॉल है, इसलिए vpnc केवल-AnyConnect सेवा तक नहीं पहुँच सकता; openconnect --protocol=anyconnect उस काम के लिए खुला क्लाइंट है।

.pcf फ़ाइल पुराने क्लाइंट प्रोफ़ाइल का वर्णन करती है। इसमें मौजूद होस्ट, समूह का नाम और समूह पासवर्ड Cisco IPsec बोलने वाले क्लाइंट में हाथ से फिर से दर्ज किए जा सकते हैं, हालाँकि फ़ाइल कोई सार्वभौमिक आयात नहीं है और कोई भी गैर-डिफ़ॉल्ट पोर्ट या टनलिंग मोड आमतौर पर स्थानांतरण में गायब हो जाता है।

गेटवे वास्तव में क्या देता है उससे शुरू करें, फिर वह क्लाइंट चुनें जो उस प्रोटोकॉल को बोलता है। दूसरी साइट से प्रोफ़ाइल कॉपी करना ही वह रास्ता है जिससे लोग ऐसे क्रेडेंशियल डीबग करने पहुँचते हैं जो कभी समस्या ही नहीं थे।