SSH config Match blocks और agent approval

SSH की मंज़ूरी तभी सार्थक है, जब मंज़ूर किया गया connection वही हो जिसे SSH वास्तव में बनाएगा। बात सुनने में सीधी लगती है, लेकिन स्थिति तब बदल जाती है जब एजेंट ssh prod चलाता है, host alias किसी अलग HostName को चुनता है, कोई Match block remote user बदल देता है और ProxyJump session को ऐसे bastion से भेज देता है जिसका request में कहीं ज़िक्र नहीं था।

जब कोई व्यक्ति terminal देख रहा हो, तब SSH configuration की ज़्यादातर गलतियां संभाली जा सकती हैं। व्यक्ति अनजान host-key prompt देख लेता है, root@... पर ध्यान दे देता है या याद रखता है कि office network पर prod का मतलब कुछ और है। Autonomous agent में ऐसी शंका अपने-आप नहीं आती। वह दिए गए alias का इस्तेमाल करता है और config का ठीक-ठीक पालन करता है।

इसीलिए एजेंट को SSH access देने से पहले SSH config के Match blocks की security review ज़रूरी है। उद्देश्य aliases, bastions या conditional config पर रोक लगाना नहीं है। उद्देश्य यह सुनिश्चित करना है कि requested action, effective SSH configuration और इंसान द्वारा मंज़ूर किया गया connection एक ही चीज़ का वर्णन करें।

Host alias input है, identity नहीं

ssh app-prod से यह पता नहीं चलता कि SSH कहां connect करेगा, कौन-सा account इस्तेमाल करेगा, कौन-सी key पेश करेगा या traffic पहले किसी दूसरी machine से गुज़रेगा। इससे केवल यह पता चलता है कि OpenSSH किस configuration argument से शुरुआत करेगा।

यह अंतर अक्सर धुंधला हो जाता है, क्योंकि aliases रोज़मर्रा के command-line काम को आसान बनाते हैं। app-prod जैसा छोटा नाम किसी खास user और nonstandard port वाले पूरी तरह qualified hostname की तुलना में टाइप करना आसान है। एजेंट को भी यह देना आसान है। लेकिन alias केवल एक handle है। उसका अर्थ उन सभी matching settings से बनता है जिन्हें SSH अपनी configuration files में पढ़ता है।

OpenSSH पहले command-line options, फिर user की ~/.ssh/config और उसके बाद system-wide config पढ़ता है। ज़्यादातर single-value options के लिए SSH को जो पहली value मिलती है, वही इस्तेमाल होती है। OpenSSH के ssh_config(5) manual का व्यावहारिक नियम साफ़ है: specific declarations पहले और general defaults बाद में रखें। ऊपर की ओर रखा broad Host * block बाद में आने वाले अधिक सावधान conditional rule को चुपचाप निष्प्रभावी कर सकता है।

शुरुआत ऐसी inventory से करें जिसमें agent द्वारा इस्तेमाल किए जा सकने वाले हर alias को reviewer के लिए जांचने योग्य रूप में दर्ज किया गया हो:

Destination column में production न लिखें। वह actual target लिखें जिसे SSH इस्तेमाल करता है। default user न लिखें। deploy, ubuntu, ec2-user या server को मिलने वाला वास्तविक account लिखें। Route में jump host है, तो उसका नाम लिखें। अगर अलग-अलग networks पर alias अलग तरह से काम करता है, तो उसकी अपनी row होनी चाहिए, क्योंकि वह अलग effective connection है।

उपयोगी अंतर यह है: alias configuration entry की पहचान करता है, जबकि destination remote endpoint की पहचान करता है। दोनों को एक समझने से गलत approvals होती हैं। Reviewer agent को staging-api पर session खोलने की मंज़ूरी दे सकता है और फिर भी actual endpoint को लेकर गलत हो सकता है, क्योंकि alias में पुराना या conditional behavior मौजूद है।

इसी वजह से aliases को operational purpose बताना चाहिए, उसे छिपाना नहीं चाहिए। prod-readonly, prod-deploy और prod-breakfix reviewer को सही जगह रुककर सोचने पर मजबूर करते हैं। prod नाम का एक alias जो conditional blocks के ज़रिए users, keys और routes चुनता है, कुछ keystrokes बचाता है लेकिन review की स्थायी समस्या पैदा करता है।

Match blocks executable connection logic हैं

Match block hosts के किसी group का label नहीं है। यह ssh_config का conditional section है, जो बदलता है कि कौन-से directives लागू होंगे। Conditions में requested host, original host, remote user, local user, canonicalization state, local network, requested command और exec command शामिल हो सकते हैं, जिसे SSH local shell के ज़रिए चलाता है।

यह शक्ति उपयोगी है। इसका अर्थ यह भी है कि config में ऐसा behavior हो सकता है जो केवल पास के Host alias को देखने पर दिखाई नहीं देता।

इस configuration पर ध्यान दें:

Host prod-api
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion

Match originalhost prod-api user root
    IdentityFile ~/.ssh/breakfix_ed25519
    IdentitiesOnly yes

जो reviewer केवल Host prod-api block पढ़ता है, उसे deploy के रूप में deployment connection दिखाई देता है। अगर caller ssh -l root prod-api चलाता है, तो Match originalhost prod-api user root condition लागू हो सकती है। Identity setting प्रभावी होगी या नहीं, यह इस बात पर भी निर्भर करता है कि पहले identity settings कहां मिलीं और option कई values स्वीकार करता है या नहीं। महत्वपूर्ण बात सरल है: connection alias बदलने से नहीं, command-line user argument बदलने से बदल गया।

Agent use के लिए ऐसे Match user rules से बचें जो अधिक privileged identity या route देते हैं। यह तरीका व्यवस्थित लगता है, क्योंकि behavior को account name के आधार पर group किया जाता है। लेकिन calling tool इसे -l, user@host या generated command से आसानी से बदल सकता है। Intended User को purpose-specific alias में सीधे रखें।

अधिक सुरक्षित version हर intent को स्पष्ट बनाता है:

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes

Host prod-breakfix
    HostName api-01.prod.example.net
    User ops
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_breakfix_ed25519
    IdentitiesOnly yes

इससे privileged access harmless नहीं बनता। Requested connection साफ़ दिखाई देने लगता है। Agent को prod-breakfix चलाने के लिए अलग authorization चाहिए। केवल username बदलने से वह गलती से इस behavior में नहीं पहुंच सकता।

Agent-facing config में Match exec पर और भी कम भरोसा करें। SSH configuration evaluate करते समय यह local shell command चलाता है। Teams इसका इस्तेमाल network detection, inventory lookups या credential selection के लिए करती हैं। इससे SSH connection attempt local code path बन जाता है, जो environment dependencies पर निर्भर है। Human work के लिए यह flexibility चाहिए, तो ऐसे aliases को agent द्वारा चलाए जा सकने वाले set से बाहर रखें। Connection review के लिए किसी arbitrary shell command को reverse-engineer नहीं करना चाहिए।

पहली matching value आपका exception निष्प्रभावी कर सकती है

SSH config की सबसे लगातार आने वाली गलती invalid stanza नहीं है। असली समस्या यह है कि valid stanza ऐसे broad rule के बाद रखी गई है जिसने option पहले ही set कर दिया।

मान लें कि production के लिए bastion ज़रूरी बनाने की कोशिश में developer यह लिखता है:

Host *
    User deploy
    ProxyJump dev-bastion

Host prod-*
    ProxyJump prod-bastion

उम्मीद समझ में आती है: prod-* अधिक specific दिखता है, इसलिए उसे जीतना चाहिए। OpenSSH blocks को specificity के आधार पर sort नहीं करता। वह उन्हें file order में process करता है और कई directives के लिए पहली मिली value इस्तेमाल करता है। prod-api में dev-bastion ही रहेगा, क्योंकि पहले वाला Host * पहले ही ProxyJump दे चुका है।

Specific blocks पहले रखें:

Host prod-*
    ProxyJump prod-bastion

Host *
    User deploy
    ServerAliveInterval 30

यह केवल style का मामला नहीं है। गलत bastion से होकर जाने वाला route session को गलत network path पर रख सकता है। Broad User deploy default किसी production alias को ऐसे account से authenticate करा सकता है जिसका उस host पर कोई काम नहीं है। Broad `IdentityFile intended key से पहले अनपेक्षित credential पेश कर सकता है।

First-value rule को जरूरत से ज्यादा सामान्य नियम न मानें। कुछ directives जानबूझकर multiple values स्वीकार करते हैं और IdentityFile इसका आम उदाहरण है। Configured identities उस set में जुड़ सकती हैं जिसे SSH consider करता है। इससे अलग समस्या पैदा होती है: narrow alias सही identity का नाम दे सकता है, फिर भी पहले की configuration या local SSH agent के ज़रिए दूसरी identities उपलब्ध रह सकती हैं।

Automated connections के लिए identity selection को स्पष्ट और उबाऊ रखें:

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes
    ProxyJump prod-bastion

IdentitiesOnly yes OpenSSH को बताता है कि वह केवल SSH configuration में configured या command line पर दी गई identities इस्तेमाल करे, न कि agent से उपलब्ध हर identity को आज़माता रहे। यह sloppy config को ठीक नहीं करता। लेकिन local agent में loaded unrelated key को accidental candidate बनने से रोकता है।

एक लोकप्रिय सलाह है कि सारे defaults Host * में रखें और केवल जरूरत पड़ने पर override करें। Keepalive intervals जैसी harmless settings के लिए यह ठीक है। लेकिन user selection, routes, identity files, ports, ProxyCommand और host rewriting के लिए यह खराब practice है। Authority को प्रभावित करने वाले defaults कम रखें। थोड़ी repetition उस स्थिति को समझाने से सस्ती है जिसमें agent सही machine तक गलत path से पहुंचा हो।

ProxyJump एक और connection बनाता है, जिसकी समीक्षा ज़रूरी है

ProxyJump destination connection को केवल सजाता नहीं है। SSH पहले jump host से connect करता है और फिर उसी jump host से destination तक TCP forwarding path बनाता है। कई proxies को list करके क्रम से traverse किया जा सकता है। OpenSSH manual यह भी चेतावनी देता है कि destination-host configuration आम तौर पर jump hosts पर लागू नहीं होती।

यहीं reviews अक्सर विफल होती हैं। Config prod-api के लिए बहुत precise हो सकती है और prod-bastion के बारे में पूरी तरह अस्पष्ट।

Host prod-api
    HostName 10.40.8.17
    User deploy
    ProxyJump prod-bastion

Host prod-bastion
    HostName bastion.prod.example.net
    User jump
    IdentityFile ~/.ssh/bastion_ed25519
    IdentitiesOnly yes

यह दो authentication decisions और दो host identities हैं:

1. SSH local client को bastion.prod.example.net पर jump के रूप में authenticate करता है।
2. Bastion TCP stream को 10.40.8.17 तक forward करता है।
3. SSH उसी stream के ज़रिए destination पर deploy के रूप में authenticate करता है।

Jump host की key, user, port और host-key record अलग हो सकती है। उसे wildcard alias या conditional block भी चुन सकता है, जिसे कोई इसलिए जांचता नहीं क्योंकि agent ने केवल prod-api request किया था।

हर hop की समीक्षा ssh -G से करें, केवल final alias की नहीं:

ssh -G prod-api | egrep '^(hostname|user|port|proxyjump|identityfile|identitiesonly) '
ssh -G prod-bastion | egrep '^(hostname|user|port|identityfile|identitiesonly) '

Output में हर line पर एक option होता है। एक स्वस्थ review में ऐसा रूप दिख सकता है:

hostname api-01.prod.example.net
user deploy
port 22
proxyjump prod-bastion
identityfile ~/.ssh/prod_deploy_ed25519
identitiesonly yes

इसके बाद bastion को अलग से verify करें। अगर prod-api edge-bastion,prod-bastion जैसी comma-separated chain इस्तेमाल करता है, तो दोनों aliases के लिए command चलाएं। Chain कोई एक opaque route नहीं है। यह कई अलग SSH client configurations हैं।

Host * या Host *.internal जैसे wide pattern में generic jump route define न करें। इससे temporary hosts, staging environments और महीनों बाद जोड़े गए aliases भी पकड़ में आ जाते हैं। Jump route उन्हीं aliases में define करें जिन्हें उसकी ज़रूरत है। अगर कई production aliases को इसकी ज़रूरत है, तो production aliases के लिए reserved narrow pattern इस्तेमाल करें और उसे casually reuse न करें।

ProxyCommand भी जांचें। OpenSSH ProxyJump और ProxyCommand को competing options मानता है: जो पहले specify होता है, वह दूसरे की बाद की instances को प्रभावी होने से रोकता है। कोई config bastion का इस्तेमाल करती हुई दिख सकती है, लेकिन वास्तव में पहले वाला proxy command चल रहा हो सकता है। Reviewer को दोनों settings flag करनी चाहिए, क्योंकि दोनों network connection के origin और destination तक पहुंचने का तरीका बदलती हैं।

User selection मंज़ूर की जा रही authority बदल देता है

Remote account requested action का हिस्सा है। [email protected] और [email protected] एक ही server तक पहुंच सकते हैं, लेकिन दोनों की authority, shell profile, forced commands, sudo rights और audit trail अलग हो सकती है।

SSH remote user कई जगहों से ले सकता है: command में user@host, ssh -l user host, User directive या, अगर कुछ और उपलब्ध न हो, local username। केवल «कौन-सा host?» पूछने वाली config review अधूरी है।

जब agent का कोई defined job हो, तो user को pin करने वाले aliases इस्तेमाल करें:

Host inventory-read
    HostName inventory.prod.example.net
    User inventory_ro
    IdentityFile ~/.ssh/inventory_ro_ed25519
    IdentitiesOnly yes

Host inventory-deploy
    HostName inventory.prod.example.net
    User deploy
    IdentityFile ~/.ssh/inventory_deploy_ed25519
    IdentitiesOnly yes

Agent को generic hostname न दें और यह न मानें कि prompt या wrapper उसे सही account तक सीमित रखेगा। Command generator [email protected] की तरह ही आसानी से [email protected] भी बना सकता है। Config को authorized path आसान और privileged paths स्पष्ट रूप से अलग रखने चाहिए।

उन alternate forms की जांच करें जिन्हें कोई tool generate कर सकता है:

ssh -G inventory-read | grep '^user '
ssh -G -l ops inventory-read | grep '^user '
ssh -G ops@inventory-read | grep '^user '

अगर दूसरी या तीसरी command ऐसा account देती है जिसे agent को इस्तेमाल नहीं करना चाहिए, तो configuration को reviewed न मानें। Calling interface ठीक करें या उस alias को अलग करें। इन variants में से किसी एक के तहत Match user block भी सक्रिय हो सकता है, इसलिए visual inspection के बजाय explicit testing ज़रूरी है।

Teams को root access अलग नाम वाले emergency alias के लिए रखना चाहिए और उसे सामान्य agent permissions से बाहर रखना चाहिए। User root को Match condition के पीछे छिपाना उसे साफ़ लिखने से भी खराब है। Incident के समय condition ढूंढना पड़ेगा और caller कभी-कभी command-line parameter बदलकर उसे satisfy कर सकता है।

IdentityFile केवल key path नियंत्रित नहीं करता

IdentityFile देखने में file-selection setting लगता है। व्यवहार में यह तय करता है कि SSH कौन-सा credential पेश कर सकता है और server किन remote authorization rules को evaluate करेगा।

एक आम failure ऐसा दिखता है:

Host *
    IdentityFile ~/.ssh/id_ed25519

Host prod-*
    IdentityFile ~/.ssh/prod_ed25519

Operator सोचता है कि production prod_ed25519 इस्तेमाल करेगा। SSH के candidate list में दोनों identity files हो सकती हैं, क्योंकि IdentityFile multiple entries स्वीकार करता है। अगर SSH agent में अतिरिक्त keys हैं और IdentitiesOnly मौजूद नहीं है, तो वे भी पेश की जा सकती हैं। कुछ servers repeated offers को जल्दी reject करते हैं और कुछ ऐसी unintended identity स्वीकार कर लेते हैं जो access दे देती है। दोनों में intent साफ़ नहीं रहता।

Agent-facing alias में एक credential purpose स्पष्ट होना चाहिए और offers सीमित होने चाहिए:

Host reports-export
    HostName reports.prod.example.net
    User exporter
    IdentityFile ~/.ssh/reports_export_ed25519
    IdentitiesOnly yes

इसके बाद stanza पर भरोसा करने के बजाय effective configuration देखें:

ssh -G reports-export | grep '^identityfile '
ssh -G reports-export | grep '^identitiesonly '

एक से अधिक identityfile lines होना अपने-आप गलत नहीं है। Certificate-based setups और planned key rotation इसके उचित कारण हो सकते हैं। लेकिन सूची में दी गई हर identity उसी authority boundary से जुड़ी होनी चाहिए। अगर एक alias personal administrator key, पुरानी deployment key और production automation key, तीनों पेश कर सकता है, तो उसका authorization story साफ़ नहीं है।

इसे ठीक करने के लिए private keys को agent की files, environment, prompt या generated script में न रखें। इससे configuration ambiguity केवल credential exposure में बदलती है। Sallyport SSH keys को अपने encrypted vault में रखता है और अपने helper के ज़रिए SSH actions चलाता है, लेकिन वह अस्पष्ट SSH config को सही नहीं बना सकता। Operator द्वारा agent process को मंज़ूरी देने से पहले alias, route, user और identity intent फिर भी स्पष्ट होने चाहिए।

यही नियम key names पर भी लागू होता है। ~/.ssh/id_ed25519 जैसा path intended use के बारे में कुछ नहीं बताता। prod_deploy_ed25519 बेहतर है, लेकिन config को पूरी बात फिर भी बतानी चाहिए: कौन-सा host group, कौन-सा user और कौन-सा route इसे इस्तेमाल करता है। File names review में मदद करते हैं, उसकी जगह नहीं लेते।

Canonicalization से एक alias दो बार match कर सकता है

Hostname canonicalization उन कम दिखाई देने वाले तरीकों में से एक है जिनसे SSH configuration बदलती है। CanonicalizeHostname yes enabled होने पर OpenSSH unqualified name लेकर configured domain suffixes जोड़ सकता है, उसे resolve कर सकता है और फिर नए target name के साथ configuration को दोबारा process कर सकता है। Match canonical इस बाद वाले pass पर लागू होता है। Match final final parse मांगता है और उसी pass में match करता है। Canonicalization enabled होने पर canonical और final conditions साथ match होती हैं।

बड़े internal networks में यह उपयोगी हो सकता है। लेकिन इससे short alias conditional configuration trap बन सकता है।

CanonicalizeHostname yes
CanonicalDomains corp.example.net

Host build
    User ci

Match canonical host *.prod.example.net
    ProxyJump prod-bastion

Caller ssh build चलाता है। पहले pass में build दिखाई देता है। अगर canonicalization इसे build.prod.example.net के रूप में resolve करती है, तो SSH configuration को फिर parse करता है और Match canonical host *.prod.example.net block production route set कर सकता है। Connection इसलिए नहीं बदला कि caller ने अलग alias मांगा था। यह DNS और दूसरे parsing pass के कारण बदला, जिसने बाद के rules को दिखने वाला host बदल दिया।

OpenSSH manual दो conditions के बीच अंतर बताता है, जिन्हें लोग अक्सर एक जैसा समझते हैं:

• Match originalhost caller द्वारा दिए गए host token की जांच करता है।
• Match host HostName substitution या canonicalization के बाद target की जांच करता है।

जब behavior को जानबूझकर named alias से बांधना हो, तो originalhost इस्तेमाल करें। जब behavior actual resolved destination पर निर्भर होना चाहिए, तो host इस्तेमाल करें। Privilege changes के लिए इनमें से किसी को भी casually न इस्तेमाल करें।

Bastions के साथ canonicalization का एक और महत्वपूर्ण पहलू है। CanonicalizeHostname yes आम तौर पर ProxyCommand या ProxyJump वाले connections पर लागू नहीं होता। CanonicalizeHostname always इसे proxied connections तक बढ़ाता है। इसका अर्थ है कि एक जैसे दिखने वाले दो aliases केवल इस वजह से अलग rewrite rules अपना सकते हैं कि उनमें से एक jump host इस्तेमाल करता है।

Agent permissions के लिए आम तौर पर सबसे आसान policy ही बेहतर है: agent को दिए जाने वाले aliases के लिए canonicalization बंद करें और explicit fully qualified HostName values इस्तेमाल करें। अगर environment में canonicalization ज़रूरी है, तो agent जिस exact network context में चलता है, उसमें हर allowed alias की जांच करें। यह न मानें कि short hostname home network, corporate network, VPN और office Wi-Fi पर एक ही तरह resolve होगा।

Match localnetwork भी यही चिंता पैदा करता है। OpenSSH document करता है कि local network address security-sensitive configuration के लिए भरोसेमंद नहीं है, खासकर DHCP-configured networks पर। Convenience settings के लिए यह ठीक है। इसका इस्तेमाल agent को अधिक privileged identity देने, bastion छोड़ने या production तक पहुंचने का निर्णय लेने के लिए न करें।

Authorization से पहले connection render करें

SSH config को prose से testable रूप में बदलने का सबसे तेज़ तरीका ssh -G है। यह host और Match rules process करने के बाद SSH द्वारा इस्तेमाल की जाने वाली configuration print करता है और connection खोले बिना exit हो जाता है।

Agent जिस exact alias और arguments का इस्तेमाल करेगा, उन्हीं के साथ इसे चलाएं। केवल command का हाथ से साफ़ किया हुआ version test न करें।

ssh -G prod-deploy | egrep '^(hostname|user|port|proxyjump|proxycommand|identityfile|identitiesonly|canonicalizehostname) '

Serious review के लिए full output को उस repository में fixture के रूप में save करें जो automation का मालिक है। Intentionally named config file इस्तेमाल करें, ताकि test developer की personal settings को चुपचाप inherit न करे:

ssh -F ./agent-ssh-config -G prod-deploy > ./testdata/prod-deploy.effective

Config बदलने पर fixture की समीक्षा करें। उपयोगी diff hostname, user, proxyjump या identity list में बदलाव को approval flow तक पहुंचने से पहले पकड़ लेता है। Full-config diff में noise हो, फिर भी यह किसी pull request में pasted block पर भरोसा करने से बेहतर है।

ssh -vvv का इस्तेमाल तभी करें जब ssh -G expected values दिखाए। Verbose connection logs यह पुष्टि करने में मदद करते हैं कि SSH वास्तव में कौन-सी host keys और authentication methods आज़माता है, लेकिन इनमें configuration decisions network noise के साथ मिल जाते हैं। पहले -G इस सवाल का जवाब देता है, «यह config क्या कहती है?» Reachability troubleshoot करने से पहले आपको यही सवाल हल करना है।

Variations को जानबूझकर test करें:

ssh -F ./agent-ssh-config -G prod-deploy
ssh -F ./agent-ssh-config -G -l ops prod-deploy
ssh -F ./agent-ssh-config -G ops@prod-deploy
ssh -F ./agent-ssh-config -G prod-deploy.prod.example.net

परिणाम या तो expected authority boundary के भीतर रहने चाहिए या fail होने चाहिए। अगर user override account बदल देता है, fully qualified form bastion छोड़ देता है या canonicalization के बाद short name को अलग identity मिल जाती है, तो आपको बंद करने लायक configuration path मिल गया है।

Included files भी जांचें। Include visible ~/.ssh/config को machine-generated, corporate या project-specific rules से भरी directory का केवल front door बना सकता है। उसी local account और config path से effective output test करें, जिसका इस्तेमाल agent करेगा। अपनी shell से test करते समय agent द्वारा किसी दूसरे account का इस्तेमाल करना certainty का झूठा एहसास देता है।

Agent-facing SSH config छोटी और purpose-built रखें

Autonomous coding agent के लिए सबसे अच्छी SSH config आम तौर पर आपकी personal SSH config नहीं होती, भले ही उसमें कुछ comments जोड़ दिए जाएं। Personal configs में shortcuts, client exceptions, पुराने host aliases, local-network behavior, forwarded agents और कभी सुविधाजनक रही identities जमा होती रहती हैं। Agent को narrow connection catalog चाहिए।

एक dedicated config file बनाएं जिसमें केवल approved aliases और उनके लिए ज़रूरी supporting jump hosts हों। Agent या execution wrapper को -F के साथ उसी file की ओर point करें। हर alias का एक काम, explicit HostName, User, route और identity intent हो। Conditional logic तभी रखें जब आप दिखा सकें कि static alias से काम नहीं चल सकता।

एक छोटा example:

Host prod-bastion
    HostName bastion.prod.example.net
    User jump
    IdentityFile ~/.ssh/prod_bastion_ed25519
    IdentitiesOnly yes

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes

Host staging-deploy
    HostName api-01.staging.example.net
    User deploy
    IdentityFile ~/.ssh/staging_deploy_ed25519
    IdentitiesOnly yes

इसमें repetition है। अच्छी बात है। File reviewer को wildcard precedence और conditional state को मन ही मन execute किए बिना बता देती है कि हर connection का मतलब क्या है।

Dedicated config file को policy engine न समझें। Session शुरू होने के बाद कोई command सुरक्षित है या नहीं, यह साबित नहीं किया जा सकता। लेकिन transport connection को review के लिए पर्याप्त concrete बनाया जा सकता है: यह alias, यह endpoint, यह user, यह route, यह identity। यह उपयोगी सीमा है।

Sallyport की per-session authorization और activity records operators को human control point और agent actions का trail देते हैं, लेकिन action के पीछे के facts SSH config ही देती है। अगर prod-deploy कई network paths या accounts में बदल सकता है, तो configuration ने approval को पहले ही कम भरोसेमंद बना दिया है।

Agent को SSH alias इस्तेमाल करने देने से पहले उसे render करें, हर jump host की जांच करें और उन command-line variants को test करें जिन्हें agent बना सकता है। अगर effective connection आपको एक बार भी चौंकाता है, तो मान लें कि वह सबसे गलत समय पर किसी और को भी चौंकाएगा। Alias को तब तक ठीक करें, जब तक वह ऐसी approval की तरह न पढ़े जिसे इंसान सचमुच दे सके।