AI coding agents के लिए bastion host access, सही तरीके से

Bastion host AI coding agents को private infrastructure तक पहुंचने का अधिक सुरक्षित रास्ता दे सकता है, लेकिन तभी जब आप इसे access boundary के एक हिस्से की तरह देखें। SSH config file में दिखाई देने वाला jump box अपने-आप कोई control नहीं है। एजेंट इसे bypass कर सकता है, कोई credential उधार ले सकता है, tunnel खोल सकता है या ऐसा audit record छोड़ सकता है जिससे केवल यह साबित हो कि किसी चीज़ ने jump box से connection बनाया था।

Autonomous work के लिए बेहतर design अधिक सख्त है: एजेंट एक controlled entry point तक पहुंचे, entry point केवल ज्ञात destinations तक पहुंचे, credentials एजेंट के context से बाहर रहें और आपके records उस host को अलग पहचानें जिसे एजेंट ने मांगा था और उस host को भी जिसने वास्तव में connection स्वीकार किया। यह अंतर पहली incident review तक अनावश्यक लग सकता है। तब यही evidence और दिलासा देने वाली कहानी के बीच का फर्क बन जाता है।

Bastion route बदलता है, agent का अधिकार नहीं

Bastion host access design network reachability सीमित करता है, लेकिन privileged account तक पहुंचने के बाद एजेंट क्या कर सकता है, यह कम नहीं करता। Teams अक्सर इन दोनों कामों को इसलिए मिला देती हैं क्योंकि दोनों में SSH शामिल है। ये अलग controls हैं और इन्हें अलग-अलग fail होना चाहिए।

Jump host तब उपयोगी होता है जब private targets administration traffic केवल उसी host या subnet से स्वीकार करते हैं। इससे operators को egress limits लगाने, connection evidence जमा करने और investigation के दौरान access बंद करने की एक जगह मिलती है। इससे हर workstation, build runner और agent sandbox को sensitive networks में direct routes देने की जरूरत भी नहीं रहती।

यह autonomous client से जुड़े चार अहम सवालों का जवाब नहीं देता:

• क्या एजेंट किसी दूसरे route से target तक सीधे पहुंच सकता है?
• क्या target account के पास requested job से अधिक permissions हैं?
• क्या एजेंट ऐसा tunnel बना सकता है जो बिना review का रास्ता दे?
• क्या बाद में final machine और remote command की पहचान की जा सकती है?

अगर पहले सवाल का जवाब हां है, तो ProxyJump enforcement नहीं, केवल convenience setting है। अगर दूसरे का जवाब हां है, तो bastion ने केवल उस जगह को बदला है जहां overpowered credential network में प्रवेश करता है।

मैंने teams को carefully maintained jump box बनाने के बाद CI subnet को “troubleshooting के लिए” broad SSH egress देते देखा है। उस subnet में चल रहे एजेंट को exploit या कोई चालाक तरीका नहीं चाहिए। वह final address पर सीधे connection कर सकता है। Architecture इसलिए विफल हुआ क्योंकि network ने bypass की अनुमति दी, SSH ने खराब व्यवहार नहीं किया।

Roles को साफ रखें। Agent environment केवल entry host से connect करे। Entry host केवल intended target networks और ports से connect करे। Final host सीमित उद्देश्य वाले account को authorize करे। हर layer ऐसे records बनाए जो अलग सवाल का जवाब दें।

ProxyJump final command नहीं दिखाता

SSH jump host आमतौर पर final host पर agent द्वारा चलाए गए command को inspect नहीं कर सकता। Teams जब bastion से “full command logs” का वादा करती हैं, तो अक्सर यही बात छूट जाती है।

OpenSSH, ssh_config(5) में ProxyJump को इस तरह document करता है कि पहले jump host से connection बनता है और फिर ultimate destination तक forwarding setup होती है। सामान्य OpenSSH उपयोग में client jump host से target तक TCP connection बनाने को कहता है और फिर उसी byte stream के भीतर end-to-end SSH session चलाता है। Final SSH transport client और target के बीच encrypted रहता है।

Bastion अक्सर यह जान सकता है कि उसने 10.42.8.19:22 से connection बनाया। वह bastion पर इस्तेमाल account, source, timing और forwarding request का destination log कर सकता है। लेकिन उसे अपने-आप यह पता नहीं चलता कि encrypted session ने बाद में systemctl restart api, cat /etc/shadow या interactive shell चलाया।

इससे तीन अलग observations बनती हैं, जिन्हें लोग अक्सर एक समझ लेते हैं:

1. Requested destination वह है जो एजेंट ने दिया, जैसे prod-api-01।
2. Connection destination वह address और port है जिसे proxy ने वास्तव में खोला।
3. Execution destination उस server identity और account को कहते हैं जिसने final SSH authentication स्वीकार की।

ये अलग हो सकते हैं। DNS बदलने के बाद alias अलग तरह से resolve हो सकता है। Compromised या पुरानी known-host entry connection को संदिग्ध बना सकती है। Proxy rule किसी friendly alias को unexpected address पर भेज सकती है। केवल prod-api-01 log करने से यह साबित नहीं होता कि command किस server पर चला।

यही separation commands पर भी लागू होती है। Client-side gateway transport से पहले requested command दर्ज कर सकता है। Final-host wrapper उस command को दर्ज कर सकता है जिसे OpenSSH exec request के लिए भेजता है। Bastion TCP target दर्ज कर सकता है। इन observations को session identifier और time window से correlate करें। यह दावा न करें कि किसी एक layer को सब कुछ दिखाई देता है।

अगर आपको एक ऐसी जगह चाहिए जो हर remote command को inspect और authorize कर सके, तो jump box के जरिए ordinary end-to-end SSH सही primitive नहीं है। इसके बजाय purpose-built remote execution service, restricted command endpoint या target-side wrapper इस्तेमाल करें जो केवल इच्छित operation स्वीकार करे। इससे flexibility घटेगी, लेकिन ऐसी visibility का दावा नहीं होगा जो आपके पास है ही नहीं।

Network rules approved path को अनिवार्य बनाएं

Controlled entry point तभी काम करता है जब आसपास का network alternative paths को unavailable बनाए। Approval dialogs या log formats पर चर्चा करने से पहले reachability से शुरुआत करें।

Agent runtime को outbound SSH केवल bastion के address और port तक चाहिए। उसे production subnets, public management interfaces या किसी दूसरे jump host तक broad route नहीं मिलना चाहिए जिसे design का हिस्सा ही नहीं माना गया। यहां DNS भी महत्वपूर्ण है। अगर एजेंट raw target addresses resolve और connect कर सकता है, तो friendly hostname convention आपकी रक्षा नहीं करता।

Bastion को छोटी egress allowlist चाहिए। अगर वह TCP port 22 पर दो private ranges के hosts administer करता है, तो केवल उन्हीं ranges और port को allow करें। उसे arbitrary outbound access देकर host को bastion न कहें। ऐसा entry host जो हर service, database और public endpoint तक पहुंच सकता है, agent account के दुरुपयोग पर general relay बन जाता है।

Final targets को SSH administration केवल bastion path से स्वीकार करनी चाहिए। Cloud security groups, host firewalls और network ACLs इसमें मदद कर सकते हैं। एक से अधिक controls तभी रखें जब ownership स्पष्ट रख सकें। जिस rule को कोई maintain नहीं करता, वह defense नहीं है।

Route को केवल सफल command से नहीं, denial cases से भी test करें। यही checks उसी user, container या VM से चलाएं जिसमें agent चलता है:

nc -vz bastion.internal.example 22
nc -vz 10.42.8.19 22
ssh -o ConnectTimeout=5 prod-api-01 true

पहला connection काम करना चाहिए। Final host से direct connection विफल होना चाहिए। SSH command केवल इसलिए काम करनी चाहिए क्योंकि configured route bastion का इस्तेमाल करती है। अगर nc उपलब्ध नहीं है, तो अपने environment का सामान्य TCP test command इस्तेमाल करें। लक्ष्य SSH configuration को direct route छिपाने से रोकते हुए network path test करना है।

Firewall changes, नए subnets और agent runner में बदलाव के बाद यह test दोहराएं। यह छोटा test असामान्य रूप से उपयोगी है। इससे वह सामान्य समस्या पकड़ में आती है जिसमें SSH config सही दिखती है, लेकिन network अभी भी सीधा connection स्वीकार करता है।

Agent को ऐसा identity दें जिसे revoke किया जा सके

Agent को shared administrator key देकर यह उम्मीद न करें कि bastion इसे सुरक्षित बना देगा। Copied private key लंबे समय तक चलने वाला authorization decision है।

हर agent process या run को ऐसा identity दें जिसे attribute और revoke किया जा सके। यह short-lived SSH certificate, सीमित job के लिए registered ephemeral key या ऐसा credential हो सकता है जिसे action gateway संभालता है और agent की ओर से SSH चलाता है। सही विकल्प आपके environment पर निर्भर है, लेकिन agent को reusable secret अपने transcript, workspace, shell history या tool output में नहीं लिखना चाहिए।

अगर आप पहले से SSH certificate authority चलाते हैं, तो SSH certificates उपयोगी हैं। Certificate में short validity period, target account के लिए principal और source address restrictions जैसे critical options रखे जा सकते हैं। Target अलग-अलग public keys की बढ़ती सूची संभालने के बजाय CA पर भरोसा कर सकता है। इससे issuance और expiry की समीक्षा आसान होती है।

Certificates broad account को narrow नहीं बनाते। root के लिए certificate expiry तक root credential ही रहता है। Certificates command intent का प्रमाण भी नहीं देते। इन्हें issuance और lifetime mechanism की तरह देखें।

Gateway exposure pattern को और स्पष्ट रूप से बदलता है। Sallyport अपने sp-ssh helper के जरिए SSH चला सकता है, जबकि SSH key encrypted vault में रहती है और agent process तक नहीं पहुंचती। इससे private key agent transcript से सुरक्षित रहती है, लेकिन teams को फिर भी जांचना चाहिए कि intended jump route, target identity और command evidence कैसे record होते हैं।

Approval को agent द्वारा chat window में लिखे वाक्य से नहीं, identifiable process से जोड़ें। Process signed हो सकता है, किसी समय शुरू हुआ हो, local user से जुड़ा हो और running session के रूप में revoke किया जा सकता हो। Natural-language explanation उपयोगी context है, लेकिन access-control boundary नहीं।

ऐसे एक credential से बचें जिसे सभी automated work साझा करते हों। जब target-side log में deploy लिखा हो, तो दूसरे record से invoking agent run की पहचान भी होनी चाहिए। अगर हर run वही key और account इस्तेमाल करता है, तो incident review archaeology बन जाती है।

Execution claim, route fact और result दर्ज करें

Agent SSH audit record में हर field का अर्थ साफ होना चाहिए। इससे audit system ऐसे claims करने से बचता है जिन्हें वह support नहीं कर सकता।

Action request के समय agent run identity, requested host alias, requested remote account, command text या structured operation और caller ने TTY या forwarding मांगी थी या नहीं, दर्ज करें। यह execution claim है। इससे पता चलता है कि caller ने क्या करने की कोशिश की।

Route boundary पर entry host identity, resolved destination address, destination port और connection outcome दर्ज करें। यह route fact है। Proxy connection खोले तो वह बता सकता है कि कहां खोला। Encrypted bytes से final command का अनुमान लगाना सत्यापित नहीं किया जा सकता।

Final host पर target host की stable identity, authenticated account, authentication fingerprint या certificate serial, server को मिला exec request हो तो command, exit status और संबंधित local service logs दर्ज करें। यह execution evidence है। सामान्य SSH endpoint में final host ही remote command देख सकता है, क्योंकि end-to-end design में वही आखिरी endpoint है।

ऐसा event shape इस्तेमाल करें जिससे missing evidence साफ दिखाई दे:

{
  "run_id": "run_7c31",
  "requested": {
    "host": "prod-api-01",
    "user": "deploy",
    "command": "sudo systemctl restart api",
    "tty": false
  },
  "route": {
    "bastion": "bastion.internal.example",
    "destination_ip": "10.42.8.19",
    "destination_port": 22
  },
  "final_host": {
    "host_fingerprint": "SHA256:example",
    "authenticated_user": "deploy",
    "command_observed": true,
    "exit_status": 0
  }
}

इस example में requested.command को final host के observation से जानबूझकर अलग रखा गया है। अगर session interactive था, तो command_observed को false करें और कारण बताएं। बिना explanation के खाली field देखकर कोई मान सकता है कि tool ने command capture कर लिया था।

सामान्य command execution के लिए sshd_config(5) में ForceCommand documented है। यह matching account या match block के लिए command force करता है। Target-side wrapper exec request में SSH_ORIGINAL_COMMAND पढ़ सकता है, allowed operation validate कर सकता है और approved program चलाने से पहले audit record लिख सकता है। Shell handling सावधानी से करें। Untrusted command string को eval से न चलाएं और interactive shell के लिए SSH_ORIGINAL_COMMAND मौजूद मानकर न चलें।

Hash chaining और append-only storage audit events में बाद के बदलाव का पता लगाने में मदद करते हैं। वे कमजोर event content को ठीक नहीं करते। ऐसा perfectly preserved record जिसमें केवल “SSH connected” लिखा हो, फिर भी कमजोर evidence है।

SSH configuration को inspectable बनाएं

लोगों के लिए host aliases रखें, लेकिन agent को configuration देने से पहले देखें कि OpenSSH वास्तव में क्या करेगा। ssh -G matching Host entries process करने के बाद effective client configuration दिखाता है।

यह example एक named target को named bastion से route करता है और अक्सर चौंकाने वाले options बंद करता है:

Host agent-bastion
    HostName bastion.internal.example
    User agent-gateway
    IdentityFile ~/.ssh/agent_gateway
    IdentitiesOnly yes

Host prod-api-01
    HostName 10.42.8.19
    User deploy
    ProxyJump agent-bastion
    StrictHostKeyChecking yes
    UserKnownHostsFile ~/.ssh/agent_known_hosts
    ForwardAgent no
    RequestTTY no

फिर rendered settings जांचें:

ssh -G prod-api-01 | grep -E '^(hostname|user|proxyjump|forwardagent|requesttty) '

Output का आकार इस तरह होना चाहिए:

user deploy
hostname 10.42.8.19
requesttty no
forwardagent no
proxyjump agent-bastion

यह बताता है कि client कैसे व्यवहार करने की योजना बना रहा है। यह साबित नहीं करता कि network direct SSH रोकता है, target अपेक्षित host key पेश करता है या bastion egress सीमित करता है। इन सबको अलग-अलग test करें।

Agent को arbitrary ssh flags freely देने न दें। Agent command-line options से configuration override कर सकता है, raw IP address दे सकता है, ProxyJump बदल सकता है या forwarding options जोड़ सकता है, खासकर तब जब execution layer shell string को सीधे pass करती हो। जहां संभव हो, destination, account और permitted SSH options को structured action inputs में रखें। अगर raw command स्वीकार करते हैं, तो उसे untrusted source से आए shell script जैसा code मानें।

Host key verification पर विशेष ध्यान दें, क्योंकि agents अपने-आप retry करते हैं और अक्सर error को task obstacle समझते हैं। Trusted host fingerprints को controlled process से preload करें। Strict checking चालू रखें। Deployment अटकने पर agent को known-host entries हटाने या बदली हुई keys स्वीकार करने की आदत न सिखाएं। Host key change के कारण की operator को पुष्टि करनी चाहिए।

Forwarding और shells review के बाहर रास्ते बनाते हैं

Autonomous agents के लिए forwarding और interactive shells बंद रखें, जब तक किसी खास task को इनकी जरूरत न हो। दोनों bounded remote command को broader access channel में बदल सकते हैं।

Local forwarding client को ऐसा local port खोलने देता है जो SSH के जरिए internal service तक पहुंचता है। Remote forwarding remote endpoint को client side की ओर path expose करने देता है। Dynamic forwarding SOCKS proxy बनाता है। Agent forwarding credentials को दूसरे host पर उपलब्ध कराता है। Human administrator के लिए इनमें से हर feature वैध हो सकता है, लेकिन हर feature यह दावा कमजोर करता है कि bastion ही एकमात्र controlled route है।

OpenSSH server restrictions देता है, जिन्हें final target या bastion account पर रखना चाहिए, केवल agent client configuration में नहीं। sshd_config(5) में DisableForwarding documented है और authorized_keys में no-port-forwarding, no-agent-forwarding, no-X11-forwarding और no-pty जैसे options उपलब्ध हैं। अपने OpenSSH version के supported controls इस्तेमाल करें और वास्तविक connection attempt से उन्हें verify करें।

Restricted account में authorized key entry इस तरह हो सकती है:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... agent-run

यह line उस public key के features सीमित करती है। यह account द्वारा चलाए जा सकने वाले commands को सीमित नहीं करती। Command scope महत्वपूर्ण हो तो इसे constrained account, ForceCommand wrapper या service-specific interface के साथ जोड़ें।

Interactive shells के लिए सीधा नियम रखें: autonomous agent को default रूप से shell न दें। Shell commands, pipelines, redirections, background processes और copied credentials की पूरी sequence स्वीकार करता है। Initial action request का command field पूरे session का वर्णन नहीं करेगा। Forced wrapper shell को रोक सकता है, लेकिन इसे test करें, क्योंकि account configuration और SSH subsystem requests के साथ shell behavior बदलता है।

कुछ maintenance jobs को सच में tunnel या shell चाहिए। इन्हें named operator approval और short expiry वाले explicit exception paths की तरह संभालें। General agent credential के भीतर exception छिपाने से temporary access permanent बन जाता है।

Command string filters से बेहतर हैं target restrictions

Shell command prefixes की simple allowlist bypass करना आसान और maintain करना कठिन है। यह लोकप्रिय इसलिए है क्योंकि सटीक लगती है: systemctl restart api allow करें, बाकी reject करें। Shell grammar इस भरोसे को कमजोर बनाती है।

मान लें filter उन text को स्वीकार करता है जो systemctl restart api से शुरू होता है। Caller shell operator जोड़ सकता है, अलग executable path इस्तेमाल कर सकता है, environment variable के जरिए behavior बदल सकता है या ऐसे wrapper का लाभ उठा सकता है जो string को अलग तरह से parse करता है। सावधानी से बनाया parser भी उस command के हर प्रभाव को नहीं जान सकता जो किसी दूसरे program को चलाती है।

जहां काम का आकार स्थिर हो, structured operations इस्तेमाल करें। Deployment runner application name और release identifier स्वीकार कर सकता है। Maintenance endpoint fixed list से service name स्वीकार कर सकता है। Restricted wrapper छोटे operation name को fixed argv array से map कर सकता है। हर मामले में shell से बचें।

जब free-form commands जरूरी हों, तो साफ स्वीकार करें कि आप उस account को remote shell authority दे रहे हैं। इसे record करें, credential पर time limit लगाएं, target environment सीमित करें और अलग approval level मांगें। String filter को command authorization के रूप में प्रस्तुत न करें।

Target account के पास operating-system permission boundary भी होनी चाहिए। Unrestricted sudo चला सकने वाला deploy account अतिरिक्त typing वाला administrator account ही है। उसे केवल automation के लिए आवश्यक service actions, files और directories दें। उसकी sudo rules को code की तरह review करें, हर command path और argument pattern समेत।

व्यावहारिक test यह है कि क्या service restart करने वाले task पर लगा agent production secrets पढ़ सकता है, reverse tunnel बना सकता है, SSH authorization बदल सकता है या audit collector बदल सकता है। अगर ऐसा संभव है, तो account scope गलत है, भले हर connection सही bastion से होकर गया हो।

Incident response live route रोकने से शुरू होती है

जब agent संदिग्ध व्यवहार करे, तो intent reconstruct करने से पहले उसका live access revoke करें। अगर action boundary उपलब्ध है तो active session वहीं बंद करें, bastion पर source block करें और संबंधित credential को फिर authenticate होने से रोकें। किसी के files rotate या evidence रखने वाले host को restart करने से पहले logs सुरक्षित करें।

फिर अलग-अलग records से timeline बनाएं। Agent के requested action से शुरुआत करें। उसे bastion connection destination और time से match करें। फिर final host authentication और command evidence से match करें। देखें कि TTY, forwarding request या alternate destination दिखाई दिया या नहीं। Discrepancy अपने-आप malicious नहीं होती, लेकिन यह बताती है कि किस control की जांच करनी है।

“Agent issue ठीक कर सके” कहकर उसे स्थायी रूप से अधिक access न दें। यह panic में किया जाने वाला आम कदम है। अगर agent पहले ही अपेक्षा से अलग व्यवहार कर चुका है, तो account broad करना या direct route खोलना आवश्यक evidence हटा देगा और एक और incident बनाएगा।

Production की जरूरत पड़ने से पहले छोटा drill चलाएं। Harmless SSH command के दौरान test agent revoke करें, पुष्टि करें कि नए requests fail होते हैं और देखें कि records requested host, actual route, target identity और exit outcome दिखाते हैं। अगर यह पता लगाने के लिए group chat की जरूरत पड़े कि क्या हुआ, तो access design अभी भी बहुत अस्पष्ट है।

Bastion तब अपनी जगह सही साबित करता है जब वह route लागू करे, तेज revocation दे और audit trail में स्पष्ट fact जोड़े। पहले route configure करें, credentials agent से बाहर रखें और final-host evidence वहां collect करें जहां final commands दिखाई देते हैं। इससे कम सब कुछ security-themed नाम वाली SSH convenience है।