Claude Code सर्व्हरवर सुरक्षित कसे चालवावे

सर्व्हरवर Claude Code सुरक्षितपणे चालवणे म्हणजे काय

सर्व्हरवर Claude Code सुरक्षितपणे चालवण्यासाठी, त्याचे permission prompts चालू ठेवा, ते एका समर्पित unprivileged user म्हणून चालवा, आणि unattended runs साठी केवळ विश्वासाऐवजी एक खरी मर्यादा द्या: इन-बिल्ट sandbox, एक container, किंवा असा disposable VPS ज्यामध्ये तुम्हाला हवी असलेली कोणतीही महत्त्वाची माहिती नसेल. --dangerously-skip-permissions flag मुळे model आणि तुमच्या shell मधील approval step निघून जातो. unattended कामासाठी हा बदल योग्य असू शकतो, परंतु तो केवळ अशा मर्यादेत असावा जी एका चुकीच्या command मुळे होणारे नुकसान मर्यादित करते. हा flag प्रत्यक्षात काय बदलतो आणि वाढत्या isolation च्या टप्प्यांमध्ये ती मर्यादा कशी तयार करायची, हे या मार्गदर्शकात स्पष्ट केले आहे.

Claude Code तुमच्या मशीनवर काय करू शकतो

Claude Code हा एक coding agent आहे जो तुमच्या terminal मध्ये चालतो. तो files वाचू शकतो, files लिहू शकता आणि ज्या user ने तो सुरू केला आहे, त्या user प्रमाणे shell commands चालवू शकतो. हे या tool चे मुख्य वैशिष्ट्य आहे: तुम्ही प्रत्येक command टाईप न करता तो repository clone करू शकतो, code edit करू शकतो, tests चालवू शकतो, failure वाचू शकतो आणि code fix करण्यासाठी loop मध्ये काम करू शकतो. जर तुम्ही अद्याप सर्व्हरवर याची setup केली नसेल, तर running Claude Code on a VPS with tmux मध्ये installation आणि session handling बद्दल माहिती दिली आहे. या पानावर, setup झाल्यानंतर तो agent तुमच्या मशीनवर किती अधिकार मिळवू शकतो, याबद्दल माहिती दिली आहे.

यातील धोका म्हणजे एकच वाक्य पुन्हा पुन्हा वाचणे. जो process तुमच्या user प्रमाणे shell commands चालवतो, तो तुमच्या user प्रमाणे काहीही करू शकतो. तो ~/.ssh/id_ed25519, ~/.aws/credentials आणि तुमच्या user ला उघडता येतील अशा सर्व .env files वाचू शकतो. तो curl चालवू शकतो आणि सर्व्हर ज्या host ला पोहोचू शकतो तिथे डेटा पाठवू शकतो. तो git push --force चालवू शकतो. Agent चे स्वतःचे कोणतेही उद्देश नसतात. धोका असा आहे की एखादे कार्य चुकले, किंवा त्याने काम करताना वाचलेल्या मजकुरात कोणातरी दुसऱ्याने लिहिलेले सूचना असू शकतात: जसे की त्याने fetch केलेली एखादी web page, किंवा ज्या issue ला fix करायला सांगितले आहे त्यातील एखादी comment. या दुसऱ्या प्रकाराला prompt injection म्हणतात, आणि म्हणूनच "model सहसा समजूतदार असते" हा कोणताही security plan नाही. तुम्हाला सरासरी कामासाठी नाही, तर चुकीच्या (bad) run साठी तयारी करायची आहे.

Permission system सोप्या शब्दांत

By default, Claude Code कोणतीही कृती करण्यापूर्वी विचारतो. प्रोजेक्टमधील files वाचणे शांतपणे (silently) होते, परंतु एखादी file edit करणे किंवा shell command चालवणे, हे आधी तुम्हाला नेमके edit किंवा command दाखवते आणि 'yes' साठी थांबते. तुम्ही एक कृती approve करू शकता, किंवा संपूर्ण session साठी त्या प्रकारच्या कृती approve करू शकता. या approvals फक्त त्या session साठी मर्यादित असतात: CLI बंद केल्यावर, पुढचे session पुन्हा सावधगिरीने सुरू होते. तुम्हाला कायमस्वरूपी पाळायचे असलेले नियम (rules) settings file मध्ये persistent allow, ask, आणि deny lists म्हणून साठवले जातात. उदाहरणार्थ: allow git status, ask on git push, deny reads of .env. Deny rules नेहमीच प्रभावी ठरतात.

हे डिझाइन असे गृहीत धरते की एखादा माणूस terminal कडे पाहत आहे, आणि लॅपटॉपवर हे खरे आहे. सर्व्हरवर, अनेकदा कोणीही पाहत नसते. तुम्ही tmux मध्ये एखादे मोठे काम सुरू करून झोपायला जाता, आणि रात्री 2 वाजता एखादा agent प्रश्न विचारण्यासाठी थांबला, तर सकाळपर्यंत कोणतेही प्रगती होत नाही. यामुळे वेळ आणि पैसे दोन्ही वाया जातात, कारण an idle Claude Code session loses its warm prompt cache आणि पुढच्या वेळी ते पुन्हा rebuild करण्यासाठी खर्च येतो. सर्व्हरवर लोक skip flag का वापरतात याचे हे खरे कारण आहे, आणि त्याने सुटलेली समस्या वास्तविक आहे. या मार्गदर्शिकेचा उर्वरित भाग सर्व guardrails सोडून न देता ही समस्या कशी सोडवायची याबद्दल आहे.

--dangerously-skip-permissions काय बदलतो

claude --dangerously-skip-permissions approval step बंद करते. Edits कोणत्याही prompt शिवाय होतात. Shell commands कोणत्याही prompt शिवाय चालतात. संवेदनशील ठिकाणांचे रक्षण करणारे protected-path checks देखील skip केले जातात. तुमचे explicit deny rules अजूनही लागू राहतात, आणि काही अत्यंत गंभीर कृतींसाठी तो अजूनही थांबून विचारतो, परंतु थोडक्यात सांगायचे तर: model ने काय चालवण्याचे ठरवले, ते चालते.

सर्व्हरवर या flag बद्दल दोन गोष्टी महत्त्वाच्या आहेत. पहिले म्हणजे, Linux आणि macOS वर जेव्हा Claude Code root किंवा sudo अंतर्गत चालतो, तेव्हा तो block केला जातो, कारण prompt शिवाय चालणारा root मशीनवरील कोणतीही file किंवा service बदलू शकतो. Agent ला anyway स्वतःच्या unprivileged account ची गरज असते आणि हा flag ते सुनिश्चित करतो. दुसरे म्हणजे, हा flag model च्या वर्तनात कोणताही बदल करत नाही. तो loop मधून मानवाला काढून टाकतो आणि इतर काहीही बदलत नाही, त्यामुळे prompt ने जे चुकीचे काम पकडले असते, ते आता execute होते.

त्यामुळे याचे खरे गणित असे आहे: जर तुम्ही permissions skip केले, तर security प्रश्न "agent काहीतरी वाईट करेल का" यावरून बदलून "एका चुकीच्या कृतीमुळे किती नुकसान होऊ शकते" असा होतो. तुम्ही प्रत्येक निर्णय नियंत्रित करण्याचा प्रयत्न करणे थांबवता आणि 'blast radius' नियंत्रित करण्यास सुरुवात करता. Containment (मर्यादित करणे) हे उत्तर आहे, आणि ते टप्प्याटप्प्याने येते.

In-built Claude Code sandbox

टप्प्यांपूर्वी हे जाणून घ्या की Claude Code आता त्याने चालवल्या जाणाऱ्या commands साठी OS-level sandbox प्रदान करतो, ज्यामुळे लोकांनी skip flag का वापरायचा, त्यातील बहुतेक कारणे दूर होतात. Linux वर ते filesystem isolation साठी bubblewrap वापरते, आणि network traffic proxy द्वारे route करण्यासाठी socat वापरते. Sandbox मध्ये, एक command फक्त project directory आणि session temp directory मध्ये लिहू शकते, आणि ते फक्त अशा proxy द्वारे network ला पोहोचू शकते जो प्रत्येक domain ची allow list सोबत तुलना करतो. जेव्हा एखाद्या command ला नवीन domain ची गरज असते, तेव्हा Claude Code तुम्हाला विचारतो.

session मध्ये /sandbox command वापरून ते चालू करा. Ubuntu आणि Debian वर, प्रथम आवश्यक असलेले दोन packages install करा:

sudo apt install bubblewrap socat

Ubuntu 24.04 आणि नंतरच्या आवृत्त्यांमध्ये, default AppArmor policy bubblewrap ला आवश्यक user namespaces तयार करण्यापासून रोखते. काही कमी असल्यास sandbox panel तुम्हाला सांगते, आणि Claude Code sandboxing documentation मध्ये ते ठीक करणारी AppArmor profile दिली आहे.

Sandbox मध्ये auto-allow mode असतो: sandboxed commands कोणत्याही prompt शिवाय चालतात, कारण आता enforced boundary ते काम करते जे prompt करायचे. जे commands sandbox मध्ये चालवू शकत नाहीत, ते सामान्य permission flow वर परततात, त्यामुळे खरोखर असामान्य कृतींसाठी तो अजूनही विचारतो. बहुतेक server workflows साठी, skip flag साठी हा योग्य पर्याय आहे, कारण तुम्हाला शून्य ऐवजी OS-enforced boundary मुळे खूप कमी प्रश्न विचारले जातात.

त्याच्या मर्यादांबद्दल प्रामाणिक राहा. बाय डिफॉल्ट, जोपर्यंत तुम्ही त्या paths deny करत नाही, तोपर्यंत एक sandboxed command अजूनही बहुतेक filesystem, credentials files सह, वाचू शकते; sandbox.credentials setting नेमके याच कारणासाठी आहे. Network proxy फक्त domain names तपासतो आणि traffic चे स्वतः निरीक्षण करत नाही, त्यामुळे github.com सारखा मोठा allow अजूनही डेटा बाहेर पाठवण्यास वाव देतो. Docker sandbox मध्ये चालत नाही. Sandbox सुरक्षिततेचा स्तर खूप वाढवतो. परंतु, हे पूर्ण isolation boundary नाही, म्हणूनच खालील टप्पे अजूनही महत्त्वाचे आहेत.

The containment ladder

Isolation च्या वाढत्या क्रमाने तीन टप्पे. तुमच्या मशीनवर इतर काय आहे त्यानुसार सर्वात कमी टप्पा निवडा.

Rung 1: एक समर्पित unprivileged user. Agent ला स्वतःचे account, स्वतःची home directory, स्वतःची project directory मिळते आणि त्याला sudo मिळत नाही:

sudo adduser --disabled-password --gecos "" agent

हे account boundary agent ला तुमच्या files पासून दूर ठेवते: तुमचे SSH keys आणि मशीनवरील इतर सर्व projects. यामुळे skip flag वापरणे शक्य होते, कारण हा flag root म्हणून चालण्यास नकार देतो. हे running every service as an unprivileged user च्या तत्त्वासारखेच आहे, जे agent साठी लागू केले आहे. Rung 1 कशावर मर्यादा आणत नाही: network, आणि मशीनवरील सर्वत्र वाचता येण्याजोग्या (world-readable) गोष्टी.

Rung 2: एक container. Anthropic एक reference devcontainer प्रकाशित करते जो Claude Code ला non-root user म्हणून चालवतो, ज्यामध्ये firewall rules असतात जे agent कोणत्या hosts ला पोहोचू शकतो यावर मर्यादा आणतात, आणि तुम्ही स्वतः तयार केलेले container तेच काम करते. Filesystem फक्त तुम्ही mount केलेल्या volumes पर्यंत मर्यादित होते, आणि egress फक्त container च्या rules नुसार मर्यादित असते. जेव्हा सर्व्हरवर तुम्हाला हव्या असलेल्या इतर services चालत असतात, तेव्हा हा योग्य मधला टप्पा आहे. याची मर्यादा अशी आहे की containers host kernel शेअर करतात, आणि एक चुकीचे mount मर्यादा मोडून काढू शकते; जर तुम्ही container ला /var/run/docker.sock दिले, तर तो संपूर्ण host ला पोहोचू शकतो.

Rung 3: एक समर्पित VPS. सर्वात मजबूत टप्पा सर्वात स्पष्ट आहे: agent ला एक संपूर्ण मशीन द्या ज्यामध्ये तुम्हाला हवी असलेली कोणतीही माहिती नसेल. एका लहान VPS साठी दरमहा काही डॉलर्स लागतात. the first ten minutes on a new VPS runbook वापरून त्याची setup करा, clean state चा snapshot घ्या, आणि agent ला काम करू द्या. तिथे दुसरे काहीही नसते. कोणतेही वैयक्तिक SSH key नाही, फक्त एकाच repository साठी मर्यादित deploy key. कोणतेही cloud credentials नाही, कोणतेही production data नाही. जर एखादे run चुकले, किंवा तुम्हाला फक्त clean slate हवे असेल, तर snapshot रिस्टोर करा किंवा काही मिनिटांत मशीन पुन्हा तयार करा. Blast radius म्हणजे फक्त भाडे (rent) आहे. ही अशी setup आहे जिथे --dangerously-skip-permissions भीतीदायक राहत नाही, कारण सर्वात वाईट परिणाम म्हणजे एक रिबिल्ट सर्व्हर आणि एक रद्द केलेले token.

हे टप्पे एकमेकांवर रचलेले आहेत. एक sandboxed agent, जो unprivileged user म्हणून चालतो, एका disposable VPS वर, यासाठी जवळजवळ काही अतिरिक्त खर्च येत नाही आणि अपयशाच्या कथा कंटाळवाण्या (boring) बनवते. कंटाळवाणे असणे हेच ध्येय आहे.

Credentials सुरक्षित करा

इतर सर्व गोष्टींसाठी महत्त्वाचा नियम: agent च्या user ला इतर कोणत्याही गोष्टीचे secrets वाचता येऊ नयेत.

API key फक्त agent ला द्या आणि इतर कोणालाही नाही. तो agent च्या user च्या मालकीच्या 600 mode असलेल्या file मध्ये ठेवा, आणि shell सुरू झाल्यावर तो load करा:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

त्यानंतर दुसरी बाजू बंद करा. Debian आणि Ubuntu वर, home directories अनेकदा मशीनवरील प्रत्येक user ला वाचता येतील अशा पद्धतीने तयार केल्या जातात, म्हणून तुमची स्वतःची directory घट्ट करा: chmod 750 /home/youruser. ls -ld /home/* ने तपासा आणि agent च्या account ला list करता येतील अशा गोष्टी fix करा.

प्रत्येक token मर्यादित (scope) करा. एकाच repository साठी मर्यादित GitHub token, किंवा per-repository deploy key, याचा अर्थ असा की लीक झालेल्या credential मुळे फक्त एक project जाईल, तुमचे संपूर्ण account नाही. जर तुम्ही sandbox वापरत असाल, तर त्याचे credential settings जोडा जेणेकरून ~/.ssh आणि ~/.aws reads साठी देखील deny होतील. आणि production credentials मशीनपासून पूर्णपणे दूर ठेवा, कारण agent अशा secret ला लीक करू शकत नाही जे तिथे कधीच नव्हते.

Git हा safety net आहे

Agent ने केलेले प्रत्येक बदल review करण्यायोग्य आणि revert करण्यायोग्य असावे, आणि जर agent एखाद्या branch वर काम करत असेल, तर git तुम्हाला दोन्ही गोष्टी मोफत देते:

git switch -c agent/refactor-auth

git diff main...agent/refactor-auth वापरून run नंतर त्याचे review करा, जे चांगले आहे ते merge करा, आणि जर run मुळे काहीच झाले नसेल तर branch डिलीट करा. Forge बाजूला main branch सुरक्षित करा, जेणेकरून agent च्या token ला त्यावर push करता येणार नाही आणि कुठेही force-push करता येणार नाही. Commit history हे तुम्ही झोपलेले असताना काय घडले याचे audit log म्हणून काम करते, जे terminal scrollback पेक्षा जास्त मौल्यवान आहे.

Network हा blast radius चा भाग आहे

एक agent curl चालवू शकतो. हे वाक्यच संपूर्ण egress समस्या आहे: agent जे काही वाचू शकतो, ते तो कुठेही पाठवू शकतो, आणि prompt-injected agent असे करू शकतो. एक साधा unprivileged user यावर कोणतीही मर्यादा आणत नाही, कारण कोणताही user सर्व्हर ज्या host ला पोहोचू शकतो तिथे पोहोचू शकतो. Sandbox त्याच्या proxy द्वारे domain नुसार यावर मर्यादा आणते. एक container त्याच्या स्वतःच्या firewall rules द्वारे यावर मर्यादा आणू शकतो. एक समर्पित VPS लीक होण्यासारख्या गोष्टींवरच मर्यादा आणतो, जे या तिन्हींपैकी सर्वात मजबूत उत्तर आहे.

केवळ ufw वापरून egress सोडवण्याचा प्रयत्न करू नका. ufw बाय डिफॉल्ट सर्व outgoing traffic ला परवानगी देते, आणि apt, npm, git, आणि Claude API ला परवानगी देणारे outbound rules लिहिणे हे कठीण काम आहे जे शांतपणे बिघडू शकते. त्याऐवजी sandbox, container किंवा machine level वर मर्यादा निवडा, जिथे domain allow list किंवा एक रिकामी machine तेच काम स्वच्छरित्या करते.

जर तुम्ही Claude Code चालवण्याऐवजी API विरुद्ध स्वतःचा agent बनवत असाल, तर तेच विचार लागू होतात. Building an AI agent with Claude on a VPS त्याबद्दल माहिती देते, आणि त्याच्या agent ला देखील तोच समर्पित user, तेच scoped tokens आणि तोच disposable box मिळायला हवा.

आधी मशीन harden करा

तुम्ही कोणताही टप्पा निवडला तरी, agent येण्यापूर्वी मशीनला मूलभूत गोष्टींची आवश्यकता असते: फक्त SSH keys, no root login, default-deny firewall, आणि automatic security updates. तुमची checklist येथे तयार करा आणि एकदा ती पूर्ण करा:

FAQ

--dangerously-skip-permissions सर्व्हरवर वापरण्यासाठी सुरक्षित आहे का?

स्वतःहून नाही. हा flag प्रत्येक approval prompt काढून टाकतो, त्यामुळे model ने तयार केल्याबरोबर पहिली चुकीची command चालते. जेव्हा blast radius मर्यादित असतो तेव्हाच हा बदल स्वीकारार्ह ठरतो: किमान एक समर्पित unprivileged user, आणि खरोखर unattended कामासाठी एक container किंवा disposable VPS ज्यामध्ये एक project आणि एक scoped token असेल. ज्या मशीनवर production credentials किंवा तुम्ही गमावू न शकू असा डेटा आहे, तिथे याचा वापर कधीही करू नका.

Claude Code मध्ये sandbox आहे का?

हो. Claude Code मध्ये shell commands साठी इन-बिल्ट sandbox आहे, जो /sandbox command ने सुरू होतो. ते Linux वर bubblewrap आणि macOS वर Seatbelt वापरते, writes ला project directory पर्यंत मर्यादित करते, आणि network access एका proxy द्वारे route करते जो फक्त मंजूर केलेल्या domains ला परवानगी देतो. त्याचा auto-allow mode sandboxed commands कोणत्याही prompt शिवाय चालवतो, ज्यामुळे तो skip flag प्रमाणेच अडथळे कमी करतो आणि OS-enforced boundary देखील राखतो. हे पूर्ण isolation boundary नाही, म्हणून unattended runs साठी ते समर्पित user किंवा समर्पित मशीन सोबत वापरा.

skip flag root म्हणून चालण्यास का नकार देतो?

कारण root कडे permission prompts नसल्यास तो सिस्टिममधील कोणतीही file आणि कोणतीही service बदलू शकतो, म्हणून Claude Code Linux आणि macOS वर root किंवा sudo अंतर्गत चालताना --dangerously-skip-permissions block करतो. उपाय म्हणजे या check ला विरोध करणे नाही. agent साठी एक unprivileged user तयार करा आणि तिथे ते चालवा; ते account boundary हा containment चा पहिला आणि सर्वात स्वस्त स्तर आहे.

Claude Code माझे SSH keys आणि .env files वाचू शकतो का?

तो ज्या user प्रमाणे चालतो, तो जे काही वाचू शकतो ते तो वाचू शकतो, आणि sandbox च्या default policy मध्ये देखील तुम्ही them deny करेपर्यंत credential paths वाचण्याची परवानगी असते. म्हणून agent ला त्याच्या स्वतःच्या user प्रमाणे चालवा, तुमची स्वतःची home directory mode 750 किंवा त्यापेक्षा कडक ठेवा, sandbox settings मध्ये credential paths deny करा, आणि production secrets मशीनपासून पूर्णपणे दूर ठेवा. मशीनवर जे secret कधीच नव्हते, ते वाचले किंवा लीक केले जाऊ शकत नाही.

Claude Code unattended चालवण्याचा सर्वात सुरक्षित मार्ग कोणता?

केवळ agent कामासाठी वापरला जाणारा एक स्वस्त समर्पित VPS: दहा मिनिटांत harden केलेला, clean snapshot असलेला, sandbox चालू असलेल्या unprivileged user अंतर्गत Claude Code चालवणारा, mode-600 file मध्ये API key असलेला, per-repository deploy key असलेला, आणि सर्व काम branches वर केलेले जे तुम्ही merge करण्यापूर्वी review करता. जर एखादे run चुकले, तर तुम्ही एक token रद्द करता आणि snapshot रिस्टोर करता, आणि तुमच्या मालकीची दुसरी कोणतीही गोष्ट प्रभावित होत नाही.