क्या SSH ProxyCommand की सुरक्षा दिखने से कमजोर है?

SSH ProxyCommand, उस रिमोट कमांड से पहले होने वाला स्थानीय प्रोग्राम निष्पादन है जिसे आप चलाना चाहते थे। यह बात कहने पर साफ लगती है, फिर भी समीक्षाओं में इसे अक्सर ट्रांसपोर्ट की छोटी जानकारी मान लिया जाता है: एजेंट ssh host uptime मांगता है, समीक्षक होस्ट और रिमोट कमांड जांचता है, और क्लाइंट चुपचाप एक स्थानीय शेल कमांड शुरू कर देता है जिसे मंजूरी के फैसले में किसी ने शामिल नहीं किया।

जब कोई स्वायत्त प्रोग्रामिंग एजेंट SSH चला सकता है, तब यह अंतर और महत्वपूर्ण हो जाता है। रिमोट गंतव्य कड़ी सीमा में हो सकता है, जबकि स्थानीय SSH कॉन्फ़िगरेशन में वर्षों से जमा एलियास, includes, सशर्त नियम, प्रॉक्सी हेल्पर और जंप-होस्ट चेन हो सकती हैं। सुरक्षित समीक्षा की शुरुआत SSH की क्लाइंट-साइड कार्रवाई से करें, फिर नेटवर्क तक आगे बढ़ें।

रिमोट सत्र बनने से पहले ProxyCommand चलता है

ProxyCommand, SSH क्लाइंट को स्थानीय कमांड शुरू करने और उसके मानक इनपुट व आउटपुट को SSH सर्वर तक ट्रांसपोर्ट के रूप में इस्तेमाल करने के लिए कहता है। कमांड गंतव्य पर नहीं चलती। वह ssh शुरू करने वाली मशीन पर, उस स्थानीय खाते के तहत चलती है और SSH के इच्छित सर्वर से प्रमाणित होने से पहले चलती है।

एक सामान्य प्रविष्टि बेअसर लग सकती है:

Host build-private
    HostName build.internal.example
    ProxyCommand /usr/local/bin/connect-private %h %p

जब कोई ssh build-private चलाता है, SSH %h और %p को फैलाता है, फिर /usr/local/bin/connect-private build.internal.example 22 शुरू करता है। हेल्पर सॉकेट खोल सकता है, दूसरा क्लाइंट चला सकता है, टोकन फ़ाइल पढ़ सकता है, लाइब्रेरी लोड कर सकता है, पर्यावरण चर देख सकता है या शेल स्क्रिप्ट चला सकता है। इसके बाद SSH क्लाइंट को केवल बाइट स्ट्रीम दिखती है। आपकी मंजूरी स्क्रीन SSH कनेक्शन बताए, पर पहली अहम कार्रवाई स्थानीय प्रोग्राम शुरू करना हो सकती है।

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

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

होस्ट एलियास, सिर्फ होस्ट से बहुत अधिक चुन सकता है

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

पहले उन कॉन्फ़िगरेशन की सूची बनाएं जिन्हें SSH पढ़ता है। सामान्य OpenSSH क्लाइंट में /etc/ssh/ssh_config, Include से पहुंची फ़ाइलें और ~/.ssh/config शामिल हैं। डिस्ट्रीब्यूशन पैकेजिंग और कमांड-लाइन विकल्प इस सूची को बदल सकते हैं, इसलिए invocation भी जांचें। जो कॉलर -F /some/file देता है, उसने समीक्षा का पूरा दायरा बदल दिया है।

किसी ठोस गंतव्य के लिए हल हुआ कॉन्फ़िगरेशन छापने को ssh -G इस्तेमाल करें। नियंत्रित टेस्ट एलियास के लिए यह उपयोगी रिकॉर्ड है:

ssh -G build-private | grep -E '^(hostname|user|port|proxycommand|proxyjump|identityfile) '

आउटपुट का रूप ऐसा होता है:

hostname build.internal.example
user deploy
port 22
proxycommand /usr/local/bin/connect-private %h %p
identityfile ~/.ssh/id_deploy

ssh -G बताता है कि SSH ने क्या चुना। इससे कई चौंकाने वाली गलतियां पकड़ी जाती हैं: बहुत व्यापक Host * प्रविष्टि, पुराना include, या ऐसा एलियास जो अपेक्षा से अलग खाते पर जाता है। यह साबित नहीं करता कि हेल्पर सुरक्षित है। समीक्षक को हर शर्त का कारण समझने लायक ढंग से भी शायद न बताए, इसलिए हर संबंधित निर्देश को उसकी स्रोत फ़ाइल तक खोजें।

होस्ट इनपुट को तभी डेटा मानें, जब कॉन्फ़िगरेशन उसे डेटा बनाए रखे। यदि एजेंट मनमाने एलियास दे सकता है, तो वह स्थानीय खाते की पढ़ने योग्य किसी भी मिलान वाली Host stanza को चुन सकता है। यदि वह मनमाने -o विकल्प या कॉन्फ़िगरेशन पथ दे सकता है, तो अक्सर एलियास समीक्षा को पूरी तरह बायपास कर सकता है। मुक्त रूप वाला SSH कमांड स्वीकार करने वाला रैपर कोई वास्तविक सीमा नहीं है।

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

शेल एक्सपैंशन कॉन्फ़िगरेशन को इनपुट सीमा में बदल देता है

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

जोखिम वाला पैटर्न वह हेल्पर है जो मिले हुए मानों से अपनी शेल कमांड बनाता है। इस कॉन्फ़िगरेशन पर विचार करें:

Host *
    ProxyCommand sh -c 'relay --target %h --port %p --token \"$RELAY_TOKEN\"'

इसके कई अलग सवाल हैं। क्या हर संभव हल हुए होस्टनाम में केवल अपेक्षित होस्टनाम सिंटैक्स है? क्या relay, --target को एक मान की तरह पार्स करता है? क्या उपयोगकर्ता-नियंत्रित वातावरण RELAY_TOKEN सेट कर सकता है या खोज पथ बदल सकता है? क्या बाहरी शेल को ऐसी कमांड स्ट्रिंग मिलती है जिसमें relay शुरू होने से पहले अर्थ बदलने वाले कैरेक्टर हैं? केवल इतना कहना कि होस्टनाम SSH से आया है, इन सवालों का जवाब नहीं है।

प्रतिशत टोकन सुरक्षित टेम्पलेटिंग सिस्टम नहीं हैं। OpenSSH कई विकल्पों में %h, %p, %r और %n जैसे टोकन फैलाता है। %n मूल होस्ट आर्ग्युमेंट है, जबकि %h कॉन्फ़िगरेशन प्रोसेसिंग के बाद SSH द्वारा इस्तेमाल होस्टनाम है। यह अंतर आसानी से छूट जाता है। %n इस्तेमाल करने वाले प्रॉक्सी कमांड को, कैनॉनिकल DNS नाम की अपेक्षा के बजाय, मानवीय एलियास या मनमाना मांगा गया टेक्स्ट मिल सकता है। %h वाला कमांड भी HostName या कैनॉनिकलाइज़ेशन से बदला हुआ मान देख सकता है।

आमतौर पर समाधान मूल सेटअप से कम चतुर होता है। तय executable path वाला छोटा समर्पित हेल्पर इस्तेमाल करें, उसे सीमित सिंटैक्स दें और इस सिंटैक्स से बाहर की हर चीज अस्वीकार करने दें। हेल्पर को दूसरी शेल लाइन बनाने के बजाय कनेक्शन API या आर्ग्युमेंट-ऐरे प्रोसेस लॉन्चर इस्तेमाल करने दें। यदि शेल स्क्रिप्ट अनिवार्य हो, तो इंटरपोलेशन से पहले इनपुट सत्यापित करें, उस शेल के लिए हर expansion को quote करें और स्वीकृत सेट इतना छोटा रखें कि ऑडिटर उसका परीक्षण कर सके।

पार्सिंग के बदले eval न इस्तेमाल करें। टीमें इसे इसलिए चुनती हैं क्योंकि इससे कॉन्फ़िगरेशन-आधारित रैपर लचीला लगता है। इससे एक छूटा हुआ quote स्थानीय निष्पादन दोष भी बन जाता है। लचीलापन समीक्षा किए हुए कॉन्फ़िगरेशन फ़ॉर्मेट में होना चाहिए, टेक्स्ट को फिर से पार्स करने वाले शेल में नहीं।

ProxyJump एक शेल हटाता है, भरोसे की समस्या नहीं

ProxyJump, जिसे अक्सर -J या ProxyJump लिखा जाता है, SSH को एक या अधिक SSH जंप होस्ट से होकर गंतव्य तक पहुंचने के लिए कहता है। सामान्य bastion रूटिंग में, केवल दूसरा ssh -W कमांड शुरू करने वाले हाथ से लिखे ProxyCommand के बजाय इसे चुनें। यह इच्छित टोपोलॉजी बताता है और उसे कस्टम शेल कमांड में रखने से बचाता है।

उदाहरण:

Host build-private
    HostName build.internal.example
    User deploy
    ProxyJump bastion-admin

Host bastion-admin
    HostName bastion.example
    User relay

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

OpenSSH दोनों सेटिंग की अनुमति देता है, लेकिन दोनों लागू होने पर ProxyCommand, ProxyJump पर प्राथमिकता लेता है। यह एक खराब कॉन्फ़िगरेशन आश्चर्य है। समीक्षक को होस्ट-विशिष्ट ब्लॉक में साफ ProxyJump दिख सकता है, जबकि कोई व्यापक पहले या बाद का मिलान नियम प्रॉक्सी कमांड दे रहा हो। एक stanza से निष्कर्ष निकालने के बजाय ssh -G से प्रभावी परिणाम जांचें।

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

Include और Match exec चयन के दौरान स्थानीय लॉजिक चला सकते हैं

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

Match शर्तें जोड़ता है। Match host, user, localnetwork और संबंधित शर्तें लागू विकल्प बदलती हैं। Match exec को अधिक स्पष्ट चेतावनी चाहिए: SSH लिखी हुई स्थानीय कमांड चलाता है और उसके exit status से तय करता है कि ब्लॉक मेल खाता है या नहीं। इसलिए कॉन्फ़िगरेशन पढ़ने से स्थानीय executable चल सकता है।

यह उदाहरण सीमा दिखाता है:

Match exec \"/usr/local/bin/on-corporate-network\"
    ProxyJump corp-bastion

यदि हेल्पर तय, root-owned प्रोग्राम हो और उसका परिणाम सरल हो, तो यह शर्त उचित हो सकती है। शेल चलाने, लिखने योग्य प्रोजेक्ट फ़ाइल पढ़ने, नेटवर्क सेवा से संपर्क करने या PATH पर निर्भर होने पर यह नाज़ुक हो जाती है। केवल ssh -G चलाने की योजना के कारण सक्रिय क्रेडेंशियल वाले वर्कस्टेशन पर अज्ञात Match exec नियम न जांचें। पहले कमांड पढ़ें और जरूरत हो तो अलग खाते या मशीन का उपयोग करें।

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

घटना की शुरुआत अक्सर सुविधा वाले हेल्पर से होती है

वास्तविक विफलता के लिए दुर्भावनापूर्ण दिखने वाला कॉन्फ़िगरेशन जरूरी नहीं। कल्पना कीजिए कि किसी डेवलपर ने निजी टेस्ट नेटवर्क तक पहुंचने के लिए सालों पहले यह जोड़ा था:

Host test-*
    ProxyCommand connect-testnet %h %p

connect-testnet कभी निजी bin डायरेक्टरी में bootstrap स्क्रिप्ट से स्थापित हुआ था। स्क्रिप्ट कंपनी VPN क्लाइंट चलाती है, फिर PATH पर मिले रिले कमांड को चलाती है। बाद में बिल्ड एजेंट डेवलपर के खाते में चलता है। वह ssh test-cache मांग सकता है। अपेक्षित कार्रवाई टेस्ट मशीन पर केवल पढ़ने वाली कमांड है।

पहले SSH, test-* से मेल खाता है। दूसरे, स्थानीय शेल connect-testnet शुरू करता है। तीसरे, स्क्रिप्ट VPN क्लाइंट और वह executable शुरू करती है जो इस समय PATH खोज में जीतता है। इन स्थानीय चरणों के बाद ही SSH नामित होस्ट के साथ अपना प्रोटोकॉल शुरू करता है। केवल रिमोट कमांड दर्ज करने वाला ऑडिट उस व्यवहार को खो देता है जिसने स्थानीय मशीन की स्थिति बदली और नेटवर्क रूट चुना।

दोष यह नहीं कि शेल स्क्रिप्ट प्रतिबंधित हैं। दोष स्थानीय सुविधा चेन को रिमोट सेवा का हिस्सा मानना है। एजेंट की test-cache चुनने की क्षमता ने स्थानीय कोड चुना। दुर्भावनापूर्ण एजेंट अधिक व्यापक पैटर्न से मेल खाने वाले एलियास खोज सकता है, पर सामान्य एजेंट भी ऐसा नाम अनुमान से देकर वही समस्या शुरू कर सकता है जो संयोग से मौजूद हो।

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

केवल गंतव्य नहीं, कनेक्शन तरीका मंजूर करें

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

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

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

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

डिस्पोज़ेबल क्रेडेंशियल से हल हुए पथ का परीक्षण करें

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

अधिकांश होस्ट एलियास के लिए संक्षिप्त समीक्षा क्रम पर्याप्त है:

1. ssh -G alias चलाएं और हल हुई hostname, user, port, proxycommand, proxyjump और identity सेटिंग सहेजें。
2. उन मानों की आपूर्ति करने वाले हर Include और हर मिलान वाले Host या Match ब्लॉक को खोजें。
3. प्रॉक्सी या मैच पथ में आने वाले हर स्थानीय executable को पढ़ें, जिनमें स्क्रिप्ट और उनकी कॉन्फ़िगरेशन फ़ाइलें शामिल हैं。
4. डिस्पोज़ेबल क्रेडेंशियल से कनेक्शन चलाएं और वास्तविक जंप होस्ट, होस्ट कुंजियां और स्थानीय प्रोसेस जांचें。
5. परीक्षण के बाद टेस्ट क्रेडेंशियल रद्द करें और अपेक्षित रूट को एलियास के पास दर्ज करें。

सिर्फ सफल कनेक्शन पर भरोसा न करें। सफलता साबित करती है कि बाइट किसी SSH सर्वर तक पहुंचीं। यह नहीं साबित करती कि उन्हें सही प्रोग्राम ने पहुंचाया, इच्छित होस्ट ने लिया या पहले कोई स्थानीय प्रभाव नहीं हुआ।

यहां थोड़ी रुकावट उचित है। यदि कोई ProxyCommand के पीछे का executable समझा नहीं सकता, तो किसी को एजेंट को वह एलियास चलाने की मंजूरी नहीं देनी चाहिए। उसे बदलें, हटाएं या रूट को एजेंट की पहुंच से बाहर रखें, जब तक कोई उसका स्वामी न बने।

छोटी SSH सतह, चतुर क्लाइंट कॉन्फ़िगरेशन से बेहतर है

एजेंट के लिए सबसे सुरक्षित SSH सेटअप में कम नामित गंतव्य, तय पहचान, स्पष्ट जंप होस्ट और कोई मनमाना कॉन्फ़िगरेशन फ्लैग नहीं होता। इसके लिए सामान्य प्रयोजन की नीति भाषा नहीं चाहिए। सीमित इंटरफ़ेस और ऐसा कॉन्फ़िगरेशन चाहिए जो जांचने पर भी साधारण रहे।

इनमें से कुछ भी बदले तो फिर समीक्षा करें: SSH क्लाइंट अपडेट, नई bootstrap स्क्रिप्ट, कॉन्फ़िगरेशन-मैनेजमेंट rollout, जोड़ी गई include डायरेक्टरी, नया एजेंट runtime या नया जंप होस्ट। ये बदलाव अक्सर अलग-अलग रिपॉज़िटरी में आते हैं। इसी वजह से कनेक्शन पथ बिना किसी की नज़र पड़े कमजोर होता जाता है।

अंतिम मानक सरल रखें: रिमोट कमांड चलने से पहले, आपको SSH द्वारा शुरू हर स्थानीय executable, संपर्क किए हर होस्ट, इस्तेमाल हर पहचान और उस रूट को मंजूरी देने वाले व्यक्ति का नाम बता पाना चाहिए। यदि आप किसी एलियास के लिए यह नहीं कर सकते, तो वह स्वायत्त उपयोग के लिए तैयार नहीं है।