AI agents के लिए SSH certificates और local credential custody

SSH certificates और local credential custody साथ मिलकर काम करते हैं। Certificate SSH server को public key के बारे में सीमित अवधि वाला signed statement देता है। Local custody matching private credential को AI agent के context, files, subprocesses और logs से बाहर रखती है। इनमें से किसी एक को दूसरे का विकल्प मानने पर ऐसी कमी रह जाती है जो सबसे खराब समय पर सामने आती है।

इस design का लोकप्रिय रूप कहता है कि 15 मिनट का certificate सब कुछ सुरक्षित बना देता है। ऐसा नहीं है। अगर agent private key पढ़ सकता है, तो certificate expire होने तक वह key इस्तेमाल करता रह सकता है, issuance तक पहुंच हो तो दूसरा certificate मांग सकता है, या workspace में उसकी copy छोड़ सकता है जो run के बाद भी बची रहे। Short validity server acceptance की अवधि घटाती है। जिस process के पास secret है, उसकी capability खत्म नहीं करती।

Infrastructure बदल सकने वाले agents के लिए certificates से accepted lifetime घटाएं और local custody से private credential disclosure रोकें। फिर renewal, interruption और revocation को एक ही operational system की तरह design करें। Diagram पर लिखी certificate lifetime से ज्यादा महत्वपूर्ण ये details हैं।

Certificate acceptance को सीमित करता है, possession को नहीं

OpenSSH user certificate, signed public key और constraints का मेल होता है। SSH server CA signature verify करता है और certificate type, validity interval, principal list, critical options और extensions जैसे fields जांचता है। Client को फिर भी यह साबित करना पड़ता है कि उसके पास certified public key से जुड़ी private key है।

यह अंतर अक्सर धुंधला हो जाता है। Certificate public material है। आप id_ed25519-cert.pub को private key के पास रख सकते हैं, client पर copy कर सकते हैं और स्वतंत्र रूप से inspect कर सकते हैं। Secret फिर भी id_ed25519 है। अगर agent को यह private file मिल जाए, तो short certificate validity केवल यह सीमित करती है कि एक जारी certificate कितनी देर काम करेगा। Agent के पास फिर भी दोबारा इस्तेमाल की जा सकने वाली signing credential रहती है।

OpenSSH certificate format को PROTOCOL.certkeys में document करता है और सामान्य creation controls ssh-keygen manual में उपलब्ध हैं। Signing command -s से CA private key, -I से identity string, -n से allowed principals और -V से validity specification लेता है। ये authorization inputs हैं, सजावटी metadata नहीं। किसी भी input का access पर असर पड़ने से पहले server को CA पर भरोसा करने और principals को समझने के लिए configure करना होता है।

दो designs पर विचार करें:

• पहले design में agent को id_ed25519, certificate और CA endpoint मिलता है। Agent खुद SSH challenges sign कर सकता है और आगे certificate requests करने में भी सक्षम हो सकता है।
• दूसरे design में local executor protected storage में id_ed25519 रखता है। Agent named SSH action का अनुरोध करता है और executor private material लौटाए बिना SSH authentication संभालता है।

दोनों designs एक ही certificate इस्तेमाल कर सकते हैं। केवल दूसरा design agent prompt injection, compromised plugin या जरूरत से ज्यादा जिज्ञासु subprocess को private credential copy करने से रोकता है।

Certificate identity field को custody के प्रमाण के रूप में भी इस्तेमाल न करें। -I value humans को issuance और access records मिलाने में मदद करती है, लेकिन certificates मांग सकने वाला कोई भी caller प्रभावशाली दिखने वाली identity चुन सकता है। Issuance को known public key और known agent session से bind करें। अगर issuer arbitrary public keys और arbitrary identity strings स्वीकार करता है, तो दबाव के समय आपका audit trail काल्पनिक साबित होगा।

Local custody उस failure को बदलती है जिसकी आपको योजना बनानी है

Credential को local रखने से secret-exfiltration incident, action-authorization incident में बदल जाता है। यह बेहतर समस्या है, फिर भी समस्या है। Agent destructive command मांग सकता है, गलत host चुन सकता है या operator की मंशा से अधिक समय तक approved session इस्तेमाल कर सकता है।

Local component को private SSH credential अपने पास रखनी चाहिए और protocol operation खुद करना चाहिए। Agent को command output, exit status और सीमित diagnostic information मिलनी चाहिए। उसे private key text, temporary file path, environment variable, forward किया जा सकने वाला SSH agent socket या ऐसा दिखावटी redacted value नहीं मिलना चाहिए जिसे कोई दूसरा tool resolve कर सके।

एक आम खराब समझौता secret directory को read-only रूप में agent environment में mount करना है। Read-only edits से बचाता है, reads से नहीं। दूसरा खराब समझौता private key को SSH agent में रखना और हर child process को SSH_AUTH_SOCK तक पहुंच देना है। यह tightly controlled interactive shell में स्वीकार्य हो सकता है, लेकिन autonomous coding agent tools, test runners, package hooks और helper processes शुरू करता है। हर process उस agent से sign करने को कह सकने वाले लोगों की संख्या बढ़ाता है।

Local custody human control के लिए भी उपयोगी point देती है। कोई व्यक्ति नए process की पहली action approve कर सकता है, sensitive credentials के हर उपयोग पर approval मांग सकता है या vault को पूरी तरह lock कर सकता है। ये controls server authorization की जगह नहीं लेते। वे तय करते हैं कि कोई process action करने की कोशिश भी कर सकता है या नहीं।

इस boundary को संकीर्ण रखें। Private key रखने वाला component arbitrary shell text स्वीकार करके agent के कहने पर blindly run न करे। उसे host, target account और वह action request पता होना चाहिए जिसे वह execute करेगा, और execution से पहले या उसके साथ इन तथ्यों को record करना चाहिए। अगर आप यह पता नहीं लगा सकते कि ssh deploy@host का अनुरोध किस process ने किया, तो local custody खराब accountability वाला secret wrapper बन चुकी है।

व्यावहारिक निष्कर्ष सीधा है: certificate renewal public authorization को refresh करे, जबकि local custody private signing को नियंत्रित करती रहे। हर बार certificate expire होने पर private credential दोबारा न बनाएं, जब तक उसे rotate करने का अलग कारण न हो।

Certificate lifetime को interruption tolerance के अनुसार रखें

Validity इस आधार पर चुनें कि नया काम रोकने के बाद पहले से जारी credential को आप कितनी देर तक स्वीकार कर सकते हैं। Read-only diagnostic run, deployment workflow और access controls बदल सकने वाले agent के लिए सही उत्तर अलग होगा।

ऐसी अवधि से शुरू करें जिसमें वास्तविक काम के लिए पर्याप्त समय हो। Teams की अपेक्षा से अधिक बार certificate renewal विफल होता है, क्योंकि laptop sleep में चला जाता है, VPN routes बदलती हैं, CA कुछ समय के लिए unavailable होता है, लंबा command connection खुला रखता है या machine clock drift करती है। बहुत छोटी lifetime सामान्य interruptions को retry logic और bypass के लगातार स्रोत में बदल देती है।

कई autonomous tasks के लिए 15 से 60 मिनट का certificate एक उचित शुरुआती setting है। जहां account production systems को प्रभावित कर सकता हो, वहां lower end इस्तेमाल करें। Longer window तभी रखें जब job को सचमुच इसकी जरूरत हो और आप कारण बता सकें। दस मिनट चलने वाले job के लिए कई घंटे का certificate अक्सर operational necessity के रूप में छिपी सुविधा होती है।

Certificate validity को SSH connection lifetime न समझें। SSH connection बनाते समय authentication करता है। Certificate expire होने पर server आमतौर पर पहले से authenticated session को बाहर नहीं करता। Connection multiplexing इसे और भ्रमित कर सकता है: बाद का command fresh certificate check करने के बजाय पहले से authenticated master connection इस्तेमाल कर सकता है।

यह व्यवहार design बदल देता है:

1. Certificate validity को new authentications की सीमा बनाने के लिए सेट करें।
2. Command या session duration की अलग सीमा local executor में रखें।
3. Agent को reusable multiplexed control socket न दें।
4. Emergency में action सचमुच रोकना हो तो active sessions terminate करें।

OpenSSH का ssh_config option ControlMaster interactive speed के लिए उपयोगी है, लेकिन per-command authentication की सरल धारणाओं को कमजोर करता है। Autonomous work के लिए sensitive targets पर multiplexing बंद करें या executor को connection का मालिक बनाकर उसे बंद करवाएं। Agent को ऐसा control path विरासत में न दें जो approval या certificate window खत्म होने के बाद भी authenticated रह सकता है।

Clock discipline भी इसी section का हिस्सा है। Certificate में absolute validity interval होता है। Issuing host और target server के समय में बड़ा अंतर हो तो नया certificate expired या not yet valid दिख सकता है। दोनों तरफ time synchronization monitor करें और server validity window अस्वीकार करे तो fail closed करें। Clock failure को बहुत लंबा certificate जारी करके ठीक न करें।

Renewal में साबित होना चाहिए कि वही custody boundary अब भी मौजूद है

Renewal service को नया certificate तभी जारी करना चाहिए जब वह request को locally held credential, current agent session और मांगे गए authorization scope से जोड़ सके। HTTP request में public key स्वीकार करना matching private half को control करने वाले की पहचान साबित नहीं करता।

सबसे साफ flow में local executor renewal के दौरान अपने registered public key पर possession proof देता है। Issuer उस proof को verify करता है, active session और requested principal जांचता है, public key पर sign करता है और केवल public certificate लौटाता है। अगली SSH connection के लिए executor उस certificate को अपनी internally held private credential के साथ attach करता है।

Issuer पर certificate creation command कुछ ऐसी दिख सकती है:

ssh-keygen -s agent_user_ca -I run-4821 -n deploy-prod -V +30m agent-run-4821.pub

यह command CA private key से agent-run-4821.pub पर sign करती है। इससे एक companion public certificate बनता है, जिसका नाम आमतौर पर agent-run-4821-cert.pub होता है। run-4821 records मिलाने में मदद करता है, deploy-prod allowed principal है और +30m तीस मिनट का interval मांगता है। Issuer को identity string खुद generate करनी चाहिए, agent द्वारा दी गई label पर भरोसा नहीं करना चाहिए।

Automation पर निर्भर कराने से पहले हर नए certificate को inspect करें:

ssh-keygen -L -f agent-run-4821-cert.pub

Output में certificate type, signing CA fingerprint, identity, serial, validity range, principals, critical options और extensions की सूची होती है। इस inspection को issuer tests का हिस्सा बनाएं। Missing principal, future में शुरू होने वाली validity range या unexpected extension वरना failed deployment के रूप में सामने आएगा और कोई व्यक्ति long-lived fallback key लेने लगेगा।

काम को नई SSH connection की जरूरत पड़ने से पहले renewal करें, ठीक expiry second पर नहीं। Executor interval के अंत के पास replacement मांग सकता है, जब existing certificate अब भी काम कर रहा हो। Command शुरू करने से पहले उसे यह भी देखना चाहिए कि command की allowed duration के लिए certificate lifetime पर्याप्त बची है या नहीं। इससे job के अगले authentication failure से ठीक पहले कोई महत्वपूर्ण write शुरू नहीं होगा।

Request level पर renewal को idempotent रखें। Lost response से client retry कर सकता है, जबकि issuer पहले ही valid certificate बना चुका हो। Request identifier, session identifier, public-key fingerprint, principal और expiry record करें। Retry पर inputs मिलने पर पहले जारी certificate लौटाएं। Inputs अलग हों तो अंदाजा लगाने के बजाय request अस्वीकार करें।

Principals और server policy तय करते हैं कि certificate क्या कर सकता है

Certificate बताता है कि कौन authenticate कर सकता है। Server फिर भी तय करता है कि कौन सा local account उस identity को स्वीकार करेगा और वह account क्या कर सकता है। अगर agent certificate को broad shared administrator account के रूप में authenticate करने दें, तो short validity ढीले authorization decision को नहीं बचाएगी।

OpenSSH TrustedUserCAKeys के जरिए user CA पर भरोसा कर सकता है। इसके बाद accepted principals को AuthorizedPrincipalsFile या AuthorizedPrincipalsCommand से map किया जा सकता है। जब server को centrally managed account mapping चाहिए, तो दूसरा विकल्प उपयोगी है, लेकिन इससे login में availability dependency जुड़ती है। छोटी fleet के लिए static principals file कम flexible, पर अक्सर समझने में आसान होती है।

Constrained server configuration कुछ ऐसी हो सकती है:

TrustedUserCAKeys /etc/ssh/agent_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
RevokedHostKeys /etc/ssh/revoked_agent_credentials.krl

deploy नाम के local account के लिए /etc/ssh/auth_principals/deploy में केवल यह हो सकता है:

deploy-prod

इस layout में server named CA के certificate को तभी स्वीकार करता है जब उसमें deploy-prod principal हो और configured KRL ने उसे revoke न किया हो। अपने servers पर OpenSSH के exact version को test करें। Configuration directives और certificate behavior सिद्धांततः स्थिर हैं, लेकिन distribution packaging और पुराने releases इस बात को प्रभावित कर सकते हैं कि आप किस पर भरोसा कर सकते हैं।

Certificate critical options और extensions उपयोग को और सीमित कर सकते हैं। OpenSSH force-command और source-address जैसे critical options support करता है। यह permit-pty, permit-port-forwarding और permit-agent-forwarding जैसे extensions भी पहचानता है। जब target workflow का आकार सीमित हो, तो इनका उपयोग करें। केवल deployment helper चलाने वाले agent को गलती से general interactive shell नहीं मिलनी चाहिए।

इसलिए कि बाद में debugging की जरूरत पड़ सकती है, agent certificate में generic permit-pty capability न डालें। जरूरत होने पर अलग, सोच-समझकर approved diagnostic credential जारी करें। सुविधा के लिए जो extensions जोड़े जाते हैं, वे उस exceptional task के खत्म होने के बाद भी अक्सर बने रहते हैं जिसने उन्हें उचित ठहराया था।

Emergency revocation के लिए expiry का इंतजार काफी नहीं है

Short validity routine containment संभालती है। अगर issuance रोक दें और certificate तीस मिनट में expire होता है, तो उस अवधि के बाद नए SSH authentications रुक जाएंगे। यह तब पर्याप्त हो सकता है जब आपने किसी गलत task को sensitive target तक पहुंचने से पहले पकड़ लिया हो। अगर private credential बाहर निकल गई हो या agent ने नुकसानदेह काम शुरू कर दिया हो, तो यह पर्याप्त नहीं है।

पहला containment कदम संबंधित session, credential या CA के लिए new issuance रोकना है। फिर urgency के अनुसार पहले से जारी credentials को authentication से रोकें। OpenSSH में Key Revocation List, यानी KRL, servers को specific certificates, public keys या signing CA अस्वीकार करने का तरीका देती है।

Issued certificate को KRL में जोड़ने के लिए operator इस तरह की command चला सकता है:

ssh-keygen -k -f revoked_agent_credentials.krl -s agent_user_ca.pub agent-run-4821-cert.pub

-s argument उस CA की पहचान करता है जिसने certificate sign किया था। बनी हुई KRL को target servers पर distribute करें, RevokedHostKeys के साथ path consistent रखें और अपनी operating procedure के अनुसार sshd reload करें। पूरी प्रक्रिया पहले test करें: certificate बनाएं, सफल authentication करें, उसे KRL में जोड़ें, file distribute करें, sshd reload करें और verify करें कि नया authentication fail होता है।

KRL central kill switch नहीं है। हर SSH server को file मिलनी और उसे पढ़ना जरूरी है। Host unreachable या offline हो, या अलग configuration regime के तहत managed हो, तो expiry तक certificate स्वीकार करता रह सकता है। इसी कारण revocation lists चलाने पर भी short validity interval उपयोगी रहती है।

जब CA private key पर संदेह हो, तो individual certificates revoke करना गलत scale का response है। प्रभावित servers पर उस CA पर भरोसा हटाएं या उसे replace करें, नया CA जारी करें और केवल उन credentials को recertify करें जिन पर अब भी भरोसा है। Agent access के लिए अलग CA रखें, ताकि यह operation human emergency access को lock out न करे। Tested break-glass path बनाए रखें, लेकिन उसे agent की पहुंच से बाहर रखें और उसके उपयोग को record करें।

अंत में active sessions खत्म करें। KRL distribution future authentication रोकती है, लेकिन जरूरी नहीं कि server द्वारा पहले से स्वीकार की गई SSH connection terminate करे। Live work रोकने के लिए host session controls, job supervisor या network controls का उपयोग करें। फिर पहले execute किए गए commands की समीक्षा करें, क्योंकि credential revocation deployment को undo या deleted file को restore नहीं कर सकती।

Uncertainty के दौरान certificate issuer को fail closed करना चाहिए

Issuer को renewal अस्वीकार करना चाहिए जब वह local executor की identity, session state, requested principal या उस scope के लिए जरूरी authorization verify न कर सके। Availability pressure में teams इन checks को warnings बना देती हैं। इससे temporary outage unbounded credential issuance में बदल जाता है।

Deployment day से पहले सामान्य failure cases की योजना बनाएं। Issuer unreachable हो तो existing certificate को normal expiry तक काम करने दें, लेकिन चुपचाप static private key का विकल्प न दें। Local vault locked हो तो action deny करें। Human approval जरूरी हो और कोई जवाब न दे, तो agent को approval अनिश्चित समय तक रखने देने के बजाय work expire करें।

एक उपयोगी renewal record में CA fingerprint, certificate serial, issuance time, expiry time, public-key fingerprint, requested principal, agent process identity, session identifier, target class और approval result शामिल होते हैं। Certificate में इनमें से कुछ जानकारी रहती है, लेकिन वह यह नहीं बताता कि request आपके intended local control path से होकर आई थी या नहीं।

Renewal के दौरान scope drift भी रोकें। deploy-prod के लिए approved session केवल इसलिए root-prod या किसी broader principal में renew नहीं होना चाहिए कि agent ने अपना plan बदल लिया। अलग account, target group या command class के लिए नई authorization boundary मांगें। Long-running autonomous jobs अक्सर यहीं unsafe होते हैं: session narrow शुरू होता है और फिर ऐसी renewal logic से exceptions जमा करता जाता है जिसकी कोई समीक्षा नहीं करता।

Issuance और execution के लिए अलग records रखें। Issuance साबित करता है कि CA ने certificate authorize किया। SSH server logs और executor activity records बताते हैं कि credential कहां इस्तेमाल हुआ और कौन सा command चला। जब operator पूछे कि certificate गलत जारी हुआ था या सही जारी होकर गलत इस्तेमाल हुआ, तो दोनों records चाहिए।

Revocation को timed operational drill की तरह test करें

जिस runbook में केवल certificate revoke करने को कहा गया है, वह तब तक अधूरा है जब तक उसमें systems, files, access rights, expected failure और issuer down होने पर कार्रवाई कर सकने वाले व्यक्ति का नाम न हो। Nonproduction target पर drill चलाएं, real certificates और वही distribution mechanism इस्तेमाल करें जो production में है।

यह sequence अपनाएं:

1. Known serial और short, documented interval वाला certificate जारी करें।
2. एक बार authenticate करें और server-side acceptance event record करें।
3. संबंधित agent session के लिए renewal बंद करें।
4. Certificate को KRL में जोड़ें, उसे distribute करें और target sshd instances reload करें।
5. नई SSH connection की कोशिश करें और पुष्टि करें कि server उसे अस्वीकार करता है। फिर मौजूद original live session को भी terminate करें।

Containment request से हर server group पर rejection तक का वास्तविक समय मापें। ऐसा target number publish न करें जिसे आपने कभी देखा ही नहीं। यह संख्या इस बात पर निर्भर करती है कि configuration system KRL कितनी जल्दी पहुंचाता है और sshd को कितनी विश्वसनीयता से reload करता है।

असुविधाजनक cases भी test करें। जब कोई target host unreachable हो तब certificate revoke करें। Existing multiplexed connection के दौरान revoke करें। Local machine sleep में हो और renewal पूरा न हो सके तब revoke करें। Operator के session approve करने के बाद, लेकिन पहले command से पहले revoke करें। हर परिणाम बताता है कि आपके controls issuance, new authentication या active execution में से किसे रोकते हैं। ये अलग controls हैं। इन सभी को revocation कहना खतरनाक assumptions पैदा करता है।

Drill का evidence सुरक्षित रखें। Issued certificate, KRL update, executor record और target server का rejection log बचाकर रखें। Real incident में यह packet responders को verified command path देता है, न कि ऐसा document जो समय के साथ केवल wishful thinking रह गया हो।

Approval, audit और SSH access को जुड़े रखें

Human approval तभी उपयोगी है जब approval उस process से जुड़ा हो जो उसका उपयोग करेगा। Unnamed background process को approve करना गलत चीज को मंजूरी देने का निमंत्रण है। Reviewer को देखना चाहिए कि process को किसने sign किया, वह कौन सा session शुरू कर रहा है और requested SSH credential ordinary scope रखता है या sensitive।

Sallyport credentials को अपने encrypted local vault में रखता है और bundled helper के जरिए SSH चलाता है, इसलिए MCP-capable agent को अपने environment में private SSH key की जरूरत नहीं पड़ती। इसके session और activity journals human approval को agent process और बाद की action records से जोड़ सकते हैं।

Audit trail में आसान viewing के साथ tamper evidence भी चाहिए। Sallyport अपने journals को encrypted, hash-chained audit log से project करता है और sp audit verify operator को vault access के बिना offline उस chain को verify करने देता है। Incident review के दौरान और evidence export करते समय यह verification चलाएं। केवल readable activity list यह साबित नहीं करती कि किसी ने inconvenient event हटाया नहीं है।

जिस access policy को audit system enforce नहीं करता, उसकी जिम्मेदारी उसे न दें। SSH server को अब भी सही CA पर भरोसा करना, केवल intended principals स्वीकार करना, current KRL पढ़ना और target account को restrict करना होगा। Local executor को private credentials सुरक्षित रखनी और चुने गए approvals मांगने होंगे। Logs evidence और operational feedback देते हैं। वे excessive permissions वाले account को ठीक नहीं करते।

सबसे मजबूत शुरुआत certificate duration घटाना नहीं है। Inventory करें कि किन agent actions को SSH चाहिए, हर action को narrow principal और account दें, private credential को local custody के पीछे रखें, फिर issuance रोकने, revocation distribute करने और live sessions खत्म करने वाले path का अभ्यास करें। जब यह काम करने लगे, तब अपनी वास्तविक renewal system जितनी छोटी certificate lifetime लगातार संभाल सकती है, उतनी चुनें।