सुरक्षित AI agent workflows के लिए Stateless SSH helpers

स्वायत्त coding agents को एक रन का SSH session अगले रन तक नहीं ले जाना चाहिए। हर कार्रवाई के लिए नया स्थानीय execution context बनाना मुश्किल करता है कि पिछला रन बाद वाले रन को authority, identity या अस्पष्ट side effects दे सके। इससे reviewers को सबूत की एक साफ़ इकाई भी मिलती है: इस process ने इस host पर यह command मांगी और helper ने यह result लौटाया।

इससे SSH harmless नहीं हो जाता। नया connection deployment को वापस नहीं लेता, background process बंद नहीं करता और बहुत ज्यादा access वाले server account की सुरक्षा नहीं करता। Stateless execution एक सीमित, लेकिन व्यावहारिक समस्या हल करता है: यह स्थानीय carryover हटाता है, जिसे agents अक्सर अनजाने में exploit कर लेते हैं।

Stateless SSH helpers स्थानीय carryover हटाते हैं, रिमोट state नहीं

Stateless SSH helper एक कार्रवाई के लिए जरूरी connection बनाता है, वह कार्रवाई चलाता है, उसका result लौटाता है और बाद की calls के लिए authenticated transport बचाकर नहीं रखता। अगली कार्रवाई फिर नए helper process और नए connection attempt के साथ शुरू होती है।

यह अंतर महत्वपूर्ण है, क्योंकि लोग अक्सर «stateless SSH» कहकर यह मतलब लेते हैं कि «कहीं भी कुछ persist नहीं होता»। यह गलत है। SSH में state कई जगह रह सकती है:

• Client master connection, multiplexing socket, known-hosts entry, agent socket, configuration या temporary files रख सकता है।
• Remote host working directory, shell history, uploaded artifact, lock file, service process, package cache और बदला हुआ database रख सकता है।
• Authorization system account, SSH certificate, public key और permissions रख सकता है।

Stateless helper पहली category से जुड़ा है। यह बाद के agent call को पहले call का live connection या स्थानीय credential context चुपचाप inherit नहीं करने देता। Remote side फिर भी असली computer है और उसके असली परिणाम हो सकते हैं।

इसीलिए «fresh server» के बजाय «fresh connection» बेहतर operational phrase है। Helper नया है, server नहीं।

मान लें कि agent deployment check चलाता है और reviewer के अगले proposed change को अस्वीकार करने के बाद बंद हो जाता है। अगर पहले run ने multiplexing socket छोड़ा था, तो उसी machine पर कोई दूसरा process पहले से authenticated channel से जुड़ सकता है। अगला process उस security boundary को पार कर चुका है जिसे operators हर run पर लागू मान रहे थे। Stateless helper के साथ दूसरे process को नई कार्रवाई मांगनी होगी और intended authorization path से फिर गुजरना होगा।

इसका लाभ कुछ हद तक security का है और कुछ हद तक diagnosis का। जब incident reviewer को घंटों तक खुला shared connection मिलता है, तो उसे पता लगाना पड़ता है कि कई processes में से किसने उसका इस्तेमाल किया। जब हर request connection lifecycle की मालिक होती है, तो record में शुरुआत और अंत स्वाभाविक रूप से दिखाई देते हैं।

Connection sharing run-level attribution से टकराता है

OpenSSH connection sharing को जानबूझकर support करता है। इसके ssh_config manual में ControlMaster को ऐसे विकल्प के रूप में बताया गया है जो कई sessions को एक network connection साझा करने देता है। ControlPersist clients के exit होने के बाद भी master connection को background में खुला रख सकता है। ये विकल्प एक terminal से कई commands चलाने वाले administrator के लिए उपयोगी हैं। लेकिन अलग authority और अलग records चाहने वाले agent runs के लिए ये खराब default हैं।

यह आम configuration देखें:

Host build-box
  HostName 10.0.0.24
  User deploy
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 15m

पहला SSH invocation ~/.ssh के भीतर authenticated master socket बनाता है। बाद के invocations, जिनके पास उस socket तक पहुंच है, पंद्रह मिनट की persistence window में उसका connection reuse कर सकते हैं। मूल process बंद होने के बाद शुरू हुआ agent process अपने transcript में independent connection जैसा दिख सकता है, जबकि असल में वह पहले बनाए गए transport पर चल रहा होता है।

इससे चार अलग समस्याएं पैदा होती हैं।

पहली, approval का अर्थ बदल जाता है। अगर किसी व्यक्ति ने किसी खास agent process को check चलाने की अनुमति दी थी, तो यह अनुमति अपने-आप उस नए process पर लागू नहीं होनी चाहिए जिसे वही socket मिल गया हो।

दूसरी, destination identity को सही समय पर जांचना कठिन हो जाता है। SSH host verification master connection बनते समय होती है। बाद के clients उसका result inherit करते हैं। बाद की call की समीक्षा करने वाले व्यक्ति को यह जानने के लिए पुरानी connection event ढूंढनी पड़ती है कि host verification कब और कैसे हुई थी।

तीसरी, logs request और transport के बीच का सरल संबंध खो देते हैं। Traditional SSH server log एक login दर्ज कर सकता है, जबकि application-level records कई commands दिखा सकते हैं। दोनों सही हो सकते हैं, लेकिन ऐसे समय में correlation का काम बढ़ जाता है जब किसी के पास अतिरिक्त समय नहीं होता।

चौथी, socket खुद एक asset बन जाता है। OpenSSH ssh_config में चेतावनी देता है कि जो भी व्यक्ति control socket तक पहुंच सकता है, वह connection तक पहुंच सकता है। File permissions मदद करती हैं, लेकिन shared authenticated channel को hostile या सिर्फ confused workspace के लिए उपयुक्त नहीं बनातीं।

जिन calls को साफ attribution चाहिए, उनके लिए multiplexing बंद करें। Direct invocation में यह फैसला स्पष्ट किया जा सकता है:

ssh -o ControlMaster=no -o ControlPath=none deploy@build-box 'id; hostname'

Expected output command का अपना shape दिखाएगा, जैसे:

uid=1004(deploy) gid=1004(deploy) groups=1004(deploy)
build-box

यह command केवल यह साबित करती है कि किस account और host ने उत्तर दिया। यह साबित नहीं करती कि account के पास उचित rights थे या मांगा गया task सुरक्षित था। फिर भी reviewer के पास एक connection attempt से मिलाने के लिए एक action होता है।

ControlMaster line न दिखने को पूरा fix न समझें। Global SSH configuration इसे सेट कर सकती है, wrapper इसे जोड़ सकता है और कोई process ControlPath को अनपेक्षित जगह पर भेज सकता है। Execution boundary को repository की dotfiles पर भरोसा करने के बजाय अपनी SSH options खुद सेट करनी चाहिए।

हर agent run को अपनी authority boundary चाहिए

Agent run तेज़ typist वाला human terminal session नहीं है। उसे issues, pull requests, generated test output, copied log text और उन source files से नई instructions मिल सकती हैं जिन्हें उसने खुद नहीं लिखा। इनमें से कोई भी सामग्री उसे ऐसी commands की ओर ले जा सकती है जो मूल intent का हिस्सा नहीं थीं।

इससे convenience features का अर्थ बदल जाता है। Session बनाए रखने वाला व्यक्ति आम तौर पर जानता है कि वह session बचाकर रख रहा है। Agent शायद बाद का task इस बात से अनजान होकर शुरू करे कि पुराना channel अभी उपलब्ध है। उसका tool interface केवल «run command» दिखाता है, जबकि underlying client चुपचाप socket खोजकर पिछली authority हासिल कर लेता है।

Agent process को approval पाने वाली इकाई मानें। उसके exit होते ही access भी समाप्त हो जाना चाहिए। अगर नया process शुरू होता है, चाहे उसे वही editor या orchestrator क्यों न चला रहा हो, protected host तक पहुंचने से पहले नई authorization decision जरूरी होनी चाहिए।

यह तरीका शुरुआत में कई developers को जरूरत से ज्यादा सख्त लगता है। बार-बार approvals देखकर वे broad allowlist बना देते हैं। इससे परेशानी दूर होती है, लेकिन उपयोगी boundary भी हट जाती है। बेहतर design संबंधित actions को एक स्पष्ट run में रखता है, reviewer द्वारा उसकी identity देखने के बाद उस run को access देता है और run खत्म होते ही access हटा देता है।

Code-signing identity यहां महत्वपूर्ण है, लेकिन यह हर सवाल का जवाब नहीं देती। इससे reviewer जान सकता है कि process किस signed program ने शुरू किया। इससे यह पता नहीं चलता कि program भरोसेमंद instructions पर काम कर रहा है या उसके वर्तमान repository में malicious prompt मौजूद है। Approval को किसी ज्ञात process को सीमित अवधि की authority से जोड़ना चाहिए, उस process द्वारा कभी पढ़ी जाने वाली हर instruction को मंजूरी नहीं देनी चाहिए।

साफ boundary retries को भी सही तरीके से संभालती है। Network failure नई request शुरू कर सकता है। Gateway को दर्ज करना चाहिए कि पहली action execution से पहले या transport के दौरान विफल हुई, फिर retry को दूसरी action के रूप में log करना चाहिए। Retries को एक अस्पष्ट success record में मिला देने से incident responders के लिए जरूरी information गायब हो जाती है।

Agent forwarding credential boundary को तोड़ देता है

SSH agent forwarding remote host को आपके local authentication agent से challenges sign कराने का रास्ता देता है। इससे private key file उस host पर copy नहीं होती, लेकिन यह अंतर जितना सुरक्षित सुनाई देता है, उतना है नहीं।

OpenSSH का ssh manual चेतावनी देता है कि remote host पर file permissions bypass करने की क्षमता रखने वाले users forwarded agent तक पहुंच सकते हैं। उस host का root user connection खुला रहने तक forwarded socket का इस्तेमाल करके कहीं और authenticate कर सकता है। उसे private key material नहीं मिलता, लेकिन वह उसके पीछे मौजूद authority का इस्तेमाल कर सकता है। Autonomous agent के लिए आम तौर पर यही वह जोखिम है जिससे आप बचना चाहते थे।

ऐसी calls से बचें:

ssh -A deploy@build-box 'git fetch && ./deploy.sh'

-A flag local authentication agent को forward करता है। अगर deployment script दूसरी machine तक पहुंचती है, तो remote host forwarded socket के ज़रिए signatures मांग सकता है। Compromised build machine या untrusted contributor द्वारा बदली गई script को दूसरे environment तक अनपेक्षित रास्ता मिल जाता है।

इसके बजाय destination task से जुड़ा credential इस्तेमाल करें। इसका अर्थ restricted public key वाला deploy account, किसी एक environment के लिए जारी short-lived SSH certificate या ऐसा remote service account हो सकता है जो केवल जरूरी artifact fetch कर सके। सटीक mechanism आपके infrastructure पर निर्भर करता है। अनुशासन वही रहता है: एक agent की approved action को remote machine से general authentication access में न बदलें।

कुछ teams nested SSH की सुविधा के कारण forwarding जारी रखती हैं। उनके पास bastion host होता है और वहां से private hosts तक जाना पड़ता है। जहां संभव हो, ProxyJump या tightly controlled gateway route इस्तेमाल करें। इससे client connection establishment के नियंत्रण में रहता है, बजाय इसके कि powerful local agent socket intermediate host पर रख दिया जाए।

Forwarding ports पर भी यही संदेह रखें। Local, remote और dynamic forwarding किसी approved command को ऐसे खुले tunnel में बदल सकते हैं जो action के उपयोगी काम खत्म होने के बाद भी खुला रहे। Stateless helper को forwarding features अस्वीकार करनी चाहिए या उनके लिए अलग approval लेना चाहिए, जब तक requested task को उनकी सचमुच जरूरत न हो।

सटीक remote account गलत instructions से होने वाले नुकसान को सीमित करता है

जब remote login कुछ भी कर सकता हो, तब fresh local state मदद नहीं करती। Agent जिस remote login तक पहुंचता है, उसका स्पष्ट काम और उसी के अनुरूप permissions होनी चाहिए।

Deployment host पर इसका मतलब ऐसा account हो सकता है जो release symlink बदल सके, एक service restart कर सके और एक deployment directory पढ़ सके। उसे blanket passwordless privilege escalation, हर user's home directory तक access और CI runner बदलने की permission भी नहीं मिलनी चाहिए। ये combinations अक्सर इसलिए बनते हैं क्योंकि किसी को lunch से पहले automation task चलाना था। वे इसलिए बने रहते हैं क्योंकि कोई उन्हें सीमित करने वापस नहीं आता।

OpenSSH authorized_keys format में server operators को कई controls देता है। Manual command= जैसे options दर्ज करता है, जो key authenticate होने पर command को मजबूर करता है, और ऐसे options भी हैं जो port forwarding, X11 forwarding और agent forwarding बंद करते हैं। जब destination का command surface छोटा और स्थिर हो, तो ये controls उपयोगी होते हैं।

उदाहरण के लिए operations team किसी dedicated public key को constrained remote wrapper से जोड़ सकती है:

command="/usr/local/libexec/release-action",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA... agent-release

Forced command को requested arguments की defensive parsing करनी चाहिए। Raw user text को shell में pass न करें। सुरक्षित wrapper verbs का छोटा set स्वीकार करता है, release identifiers को expected format से मिलाता है, audit record लिखता है और matching fixed operation चलाता है। अगर agent को arbitrary shell access चाहिए, तो इसे साफ़ तौर पर स्वीकार करें और account की permissions इस risk के लिए पर्याप्त रूप से सीमित रखें।

Forced command generic policy language नहीं है। यह एक host पर बनाया गया छोटा interface है। इसकी ताकत इसी constraint में है। आप इसे test और review कर सकते हैं और natural-language rules के ढेर को interpret किए बिना जान सकते हैं कि यह कौन-कौन सी actions कर सकता है।

sudo के साथ सावधान रहें। किसी script को अनुमति देने वाली line भी broad access बन सकती है, अगर script arbitrary paths स्वीकार करती हो, writable directory से configuration load करती हो, editor चलाती हो या user-controlled environment variable के ज़रिए कोई दूसरा program call करती हो। पूरी call chain पढ़ें। Permission line review की शुरुआत है, अंत नहीं।

Action record में who, what, where और result का जवाब होना चाहिए

उपयोगी audit trail केवल इतना नहीं बताता कि SSH हुआ था। उससे व्यक्ति को बिना अनुमान लगाए action reconstruct कर पाना चाहिए और यह स्पष्ट होना चाहिए कि कौन-सा agent run उसका मालिक था।

Agent run identifier, उसकी process authority, reviewer decision, destination, remote account, requested command या operation, time, outcome और output के reference को record करें। जहां design इसकी अनुमति दे, resolved host identity भी capture करें। Denial को भी record करें। Denied action इस बात का evidence है कि boundary ने अपेक्षा के अनुसार काम किया और damage होने से पहले गलत instruction का संकेत दे सकती है।

Commands को खास handling चाहिए। Raw command में passwords, access tokens, query values और private paths हो सकते हैं। सब कुछ redact करने पर record बेकार हो जाता है, जबकि सब कुछ रखने पर log दूसरा secret store बन सकता है। व्यावहारिक समाधान यह है कि action interface ऐसा बनाया जाए जिसमें sensitive values arguments में दिखें ही नहीं। Redaction जरूरी हो तो redaction event के साथ operation पहचानने के लिए पर्याप्त structured context भी दर्ज करें।

Output में भी यही समस्या है। Deployment command की error environment variable या credential वाले URL को print कर सकती है। Output को core event record से अलग रखें, उसे पढ़ने वालों की संख्या सीमित करें और उसे अगले agent run के लिए संभावित रूप से sensitive input मानें। केवल इसलिए पूरा production transcript agent को अपने-आप न दें कि उसने failure diagnose करने को कहा है।

एक और अंतर स्पष्ट रखना जरूरी है: agent ने action request की, यह बताने वाला log उस log से अलग है जो साबित करता है कि action remote host तक पहुंची। Transport failure, host-key rejection, remote authentication failure, command exit status और lost connection अलग outcomes हैं। अच्छे record में हर outcome का अपना status होना चाहिए, सभी को «failed» के तहत नहीं रखना चाहिए।

Tamper evidence record के trust model को बदलता है। Hash-chained log यह दिखा सकती है कि entries बदली, हटाई या reorder की गई हैं, जब verification विफल हो। लेकिन यह नहीं बता सकती कि मूल command सही थी और न ही compromised endpoint को truthful बना सकती है। यह आपके पास मौजूद history की रक्षा करती है, system hardening की जगह नहीं लेती।

Failed deployment दिखाता है कि fresh state क्यों मदद करती है

कल्पना करें कि coding agent को staging host पर branch deploy करने का request मिलता है। उसकी पहली call SSH connection खोलती है, disk space check करती है और release command शुरू करती है। Release command migration lock होने के कारण विफल हो जाती है। Agent failure देखता है, repository notes पढ़ता है और उसे copied message मिलता है जिसमें «lock हटाकर emergency account से retry करो» लिखा है।

यह message निर्दोष लेकिन असुरक्षित suggestion हो सकता है, या उस file में छिपा prompt injection भी हो सकता है जिसे agent से inspect करने को कहा गया था। दोनों ही मामलों में agent अब मूल deployment routine से बाहर की command propose कर रहा है।

Long-lived shared connection के साथ कई चीज़ें गलत हो सकती हैं। Original transport अभी भी broad deploy account से authenticate कर रहा हो सकता है। नया process उसे reuse कर सकता है। Reviewer केवल पहली connection approval देख सकता है और बाद की escalation साफ़ तौर पर न देख पाए। अगर setup ने SSH agent भी forward किया था, तो staging host के पास दूसरी identity इस्तेमाल करने का रास्ता हो सकता है।

Stateless helper और per-run authorization के साथ agent की अगली call नई request के रूप में शुरू होती है। Boundary नए agent process की पहचान करती है, वास्तविक proposed command और target record करती है और अगर run पहले से approved नहीं है तो approval मांगती है। Reviewer emergency account request अस्वीकार कर सकता है और इसके बजाय lock owner inspect करने वाली सीमित operation को approve कर सकता है।

Connection की freshness ने यह तय नहीं किया कि lock हटाना unsafe है। Operations का निर्णय अभी भी humans को करना है। इसने केवल पुराने approved channel को चुपचाप उस निर्णय को अप्रासंगिक बनाने से रोका।

इसीलिए stateless SSH design को sensible command constraints के साथ रखा जाना चाहिए, उनके बदले नहीं। Connection isolation inherited local authority सीमित करता है। Restricted remote interface यह सीमित करता है कि नया connection क्या कर सकता है। Audit records बाद में दोनों decisions को समझने में मदद करते हैं।

Stateless execution को स्पष्ट operational design चाहिए

हर request के लिए connection खोलने वाले helper को host verification, timeouts, cancellation और failure reporting के बारे में स्पष्ट व्यवहार चाहिए। इन details को agent के environment पर छोड़ देना छिपी हुई state को किसी दूसरे नाम से वापस ले आता है।

Host keys verify करें। OpenSSH का StrictHostKeyChecking=yes client को unknown या बदली हुई key वाले hosts को interactive सवाल पूछने के बजाय reject करने देता है। Protected automated action के लिए सामान्यतः यही सही posture है। Trusted host keys को controlled process के ज़रिए provision करें और destination match न होने पर fail closed करें।

Bounded timeouts इस्तेमाल करें। अटका हुआ SSH connection अनिश्चित समय तक आधा-अधूरा session बनकर उपलब्ध नहीं रहना चाहिए, उसे अंततः recorded failure लौटानी चाहिए। जहां operating system अनुमति दे, helper को cancellation पर child processes भी समाप्त करने चाहिए और यह बताना चाहिए कि termination की पुष्टि हो पाई या नहीं। जब transport उस समय टूटे जब server command शुरू कर चुका हो, तब remote command को cancelled न बताएं।

Request shape छोटा और inspectable रखें। Action boundary SSH request को destination, account, command, समर्थित होने पर working directory और timeout जैसे structured fields में दिखा सकती है। उसे shell configuration का ऐसा blob स्वीकार नहीं करना चाहिए जो identity files, proxy behavior, control socket paths और forwarding options को review के बिना बदल दे।

Gateway SSH credential अपने पास रख सकता है और agent action मांग सकता है। Sallyport अपने bundled stateless sp-ssh helper के ज़रिए SSH के लिए यही model अपनाता है: agent को SSH key नहीं मिलती, app खुद action करती है।

Boundary को session approval और per-call approval में भी अंतर रखना चाहिए। Session approval ऐसे bounded agent run के लिए उपयुक्त है जिसमें reviewer expected work की sequence स्वीकार करता है। Per-call approval उन credentials या destinations के लिए ठीक है जिनके हर इस्तेमाल पर अलग human decision चाहिए। ऐसा न दिखाएं कि दोनों choices एक जैसा control देती हैं। वे interruption और granularity के बीच अलग trade-off चुनती हैं।

Boundary पर भरोसा करने से पहले hidden reuse की जांच करें

आप test कर सकते हैं कि आपका setup सचमुच independent connections बनाता है या नहीं। इसे nonproduction environment में ऐसे account के साथ करें जिसके पास sensitive access न हो।

पहले दो अलग agent या helper processes शुरू करें और हर एक से id जैसी harmless command चलाएं। SSH server के authentication log और अपने action log को देखें। आपको दो connection attempts दिखाई देने चाहिए जिन्हें दो अलग process records से map किया जा सके।

फिर client side पर multiplexing sockets देखें। macOS और Linux जैसे systems पर broad inspection इस तरह हो सकती है:

find ~/.ssh -type s -print

अगर यह control socket से जुड़ा path दिखाए, तो पता लगाएं कि उसे किस configuration ने बनाया। Shared machine पर socket को बिना सोचे delete न करें। पहले owner और active clients पता करें। Isolated helper के execution path से connection-sharing settings हटाएं, बाद में cleanup पर निर्भर न रहें।

अंत में एक approved action चलाएं, agent process बंद करें और दूसरा process शुरू करें। दूसरे process को पहले process की authorization, authentication transport या बिना नई decision के remote shell चलाने की क्षमता inherit नहीं करनी चाहिए। Denied path को approved path जितनी ही सावधानी से test करें। Teams अक्सर पाती हैं कि happy path isolated है, लेकिन error handler direct SSH command पर वापस चला जाता है।

आखिरी जांच एक परिचित failure पकड़ती है: सावधान gateway normal requests संभालता है, लेकिन retry script या diagnostic tool दबाव बढ़ने पर उसे bypass कर देता है। यह bypass आम तौर पर कोई व्यक्ति service जल्दी बहाल करने की कोशिश में जोड़ता है। बाद में यही वह रास्ता बन जाता है जिसे agent पहली कोशिश विफल होने पर खोज लेता है।

हर SSH action के लिए fresh state कोई औपचारिकता नहीं है। यह autonomous work को ऐसी boundary देती है जिसे लोग inspect, approve, revoke और investigate कर सकते हैं। Remote account को सीमित रखें, forwarded credentials को अस्वीकार करें, outcomes को सटीक रूप से record करें और हर नए agent process से उसकी अपनी access अर्जित करवाएं।