OpenClaw को VPS पर सुरक्षित तरीके से कैसे सेटअप करें

OpenClaw क्या है, और इसे सबसे पहले सुरक्षित (harden) क्यों करें

OpenClaw एक self-hosted AI agent है। आप इसे अपने सर्वर पर चलाते हैं, इसे एक large language model से जोड़ते हैं, और यह shell commands चला सकता है, browser को नियंत्रित कर सकता है, आपकी files को पढ़ और लिख सकता है, और chat apps से आपके द्वारा भेजे गए संदेशों पर कार्य कर सकता है। यही पहुँच इस tool का मुख्य उद्देश्य है, और यही इसका सबसे बड़ा जोखिम भी है। कोई भी command चलाने में सक्षम agent उतना ही सुरक्षित है जितना कि वह सर्वर जिस पर वह चलता है और जो सीमाएँ आप उस पर लगाते हैं।

दो तथ्य इस गाइड की दिशा तय करते हैं। पहला, OpenClaw को आपके द्वारा सुरक्षित (harden) किए जाने के लिए डिज़ाइन किया गया है। इसका security model सख्त tool policies, sandboxing, और सावधानीपूर्वक permissions की जिम्मेदारी operator पर डालता है, न कि सुरक्षित default settings पर। दूसरा, इस project में पहले ही एक गंभीर security event हो चुका है: मार्च 2026 में, चार दिनों के भीतर नौ security issues का खुलासा हुआ, जिसमें एक critical privilege-escalation flaw, CVE-2026-32922 शामिल था, जिसे 10 में से 9.9 rating दी गई थी। इन तथ्यों का मतलब यह नहीं है कि आपको OpenClaw का उपयोग नहीं करना चाहिए। इनका मतलब यह है कि आपको इसे लापरवाही से नहीं चलाना चाहिए, और यह गाइड इसे सावधानी से चलाने का तरीका है। सावधानी बरतने का एक हिस्सा यह तय करना है कि agent बिना पूछे कितना काम कर सकता है, एक ऐसा विकल्प जिसे Claude Code अपनी permission modes के साथ स्पष्ट करता है, जहाँ एक ऐसा सर्वर जिसके सामने आप नहीं बैठे हैं, उस laptop की तुलना में अधिक सख्त setting का हकदार है जिसे आप खुद देख रहे हैं।

अच्छी खबर भी है। OpenClaw पहले से ही आपके लिए एक सुरक्षित विकल्प चुनता है: इसका gateway, वह एकमात्र process जो सब कुछ नियंत्रित करता है, default रूप से loopback address पर listen करता है, इसलिए यह internet से तब तक पहुँच योग्य नहीं है जब तक कि आप इसे expose करने के लिए विशेष प्रयास न करें। नीचे दिया गया अधिकांश कार्य इसे उसी स्थिति में बनाए रखने और यदि कुछ गलत हो जाता है तो blast radius को सीमित करने के बारे में है।

OpenClaw को अपना unprivileged user दें

किसी भी agent को root के रूप में कभी न चलाएं। यदि OpenClaw root के रूप में चलता है और कुछ भी गलत होता है, चाहे वह कोई bug हो, गलत instruction हो, या ऊपर बताया गया कोई CVE हो, तो नुकसान की कोई सीमा नहीं रहती। एक समर्पित system user बनाएं जिसमें login shell न हो और sudo का अधिकार न हो, और agent को उसी user के रूप में चलाएं:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

OpenClaw के स्वामित्व वाली हर चीज़ /opt/openclaw के अंतर्गत रहती है, जिसका मालिक वही account होता है। यह सबसे महत्वपूर्ण कदम है, और यह वही सिद्धांत है जिसे unprivileged user के रूप में services चलाना में कवर किया गया है: जिस account के रूप में agent चलता है, वह उस नुकसान की अधिकतम सीमा तय करता है जो वह कर सकता है।

OpenClaw इंस्टॉल करना

OpenClaw एक npm पैकेज के रूप में वितरित किया जाता है, इसलिए यदि सर्वर पर Node.js नहीं है तो पहले उसे इंस्टॉल करें। पैकेज को ग्लोबली इंस्टॉल करें, जो openclaw बाइनरी को हर यूजर के PATH में डाल देता है, फिर एक बार होने वाला onboarding स्टेप चलाएं:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

onboarding को openclaw यूजर के रूप में चलाने का मतलब है कि एजेंट का कॉन्फ़िगरेशन root की डायरेक्टरी के बजाय उसके होम डायरेक्टरी, /opt/openclaw में सुरक्षित होता है। यह प्रोजेक्ट एक curl -fsSL https://openclaw.ai/install.sh | bash इंस्टॉलर भी प्रदान करता है जो एक ही लाइन में वही इंस्टॉलेशन पूरा कर देता है। onboarding के दौरान --install-daemon फ्लैग को छोड़ दें: यह OpenClaw की अपनी सर्विस को रजिस्टर कर देगा, जबकि नीचे आपके द्वारा बनाई गई हार्डन्ड systemd यूनिट अधिक सख्त है।

Gateway को loopback पर रखें, firewall के पीछे

Gateway डिफ़ॉल्ट रूप से 127.0.0.1 पर bind होता है। इसे वहीं रहने दें। इस port को internet पर publish करने का लगभग कभी कोई कारण नहीं होता है, और ऐसा करने से कोई भी व्यक्ति जो इसे ढूँढ लेता है, उसे एक ऐसी प्रक्रिया का remote access मिल जाता है जो commands निष्पादित करने का कार्य करती है।

सर्वर के सामने एक default-deny firewall लगाएँ ताकि गलती से कुछ भी expose न हो:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

यहाँ दो गलतियों से बचें। एक firewall जो केवल IPv4 को कवर करता है, वह उसी service को IPv6 पर पूरी तरह खुला छोड़ सकता है, जो कि ठीक वही IPv6 firewall gap है जिसमें बहुत से लोग फंस जाते हैं। और यदि आपको अपने laptop से gateway तक पहुँचना है, तो port को open न करें। इसे VPN या SSH tunnel के माध्यम से access करें, ताकि agent कभी भी open internet पर listening मोड में न रहे।

इसके secrets को अलग रखें

OpenClaw को जिस भी language model से आप जोड़ते हैं, उसके लिए एक API key की आवश्यकता होती है। वह key आपके पैसे खर्च कर सकती है और agent के माध्यम से आपकी ओर से कार्य कर सकती है, इसलिए इसे password की तरह सुरक्षित रखें। इसे unit file में न रखें और न ही किसी repository में डालें। इसे ऐसी file में रखें जिसे केवल OpenClaw user ही पढ़ सके:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

systemd unit उस file को EnvironmentFile के साथ load करती है, इसलिए key command line, log या आपकी shell history में आए बिना सीधे process तक पहुँच जाती है। यह pattern server पर मौजूद हर secret के लिए लागू होता है: self-hosted Vaultwarden की hardening मुख्य रूप से इसके admin token और backup file पर केंद्रित होती है, न कि इसके encryption पर, क्योंकि file permissions ही वास्तव में यह तय करती हैं कि storage पर मौजूद secret को कौन पढ़ सकता है।

इसे एक hardened systemd service के रूप में चलाएं

agent को systemd के अंतर्गत चलाने से आपको automatic restarts, journalctl के माध्यम से साफ logs और सबसे महत्वपूर्ण रूप से, kernel-level sandboxing विकल्पों का एक सेट मिलता है। ये विकल्प process की पहुंच को सीमित करते हैं, भले ही वह breach हो जाए। एक agent के लिए सबसे महत्वपूर्ण विकल्प हैं: NoNewPrivileges ताकि वह कभी भी नई शक्तियां प्राप्त न कर सके, ProtectSystem=strict ताकि filesystem read-only रहे (सिवाय उन जगहों के जहां आप write की अनुमति देते हैं), PrivateTmp ताकि उसके पास अपनी अलग temporary directory हो, और ProtectHome ताकि वह home directories को न पढ़ सके।

यहाँ एक पूर्ण, hardened unit generate करें, फिर इसे /etc/systemd/system/openclaw.service पर copy करें:

यह unit openclaw gateway को start करती है, जो agent को नियंत्रित करने वाली long-running process है; यदि आपके सर्वर पर which openclaw कोई अलग path दिखाता है, तो ExecStart को उसके अनुसार बदलें। इन directives, और daemon-reload तथा enable --now का पूरा विवरण systemd service के रूप में प्रोग्राम चलाना में दिया गया है। unit को paste करने के बाद संक्षिप्त प्रक्रिया यह है:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

फ्रंट डोर को भी सुरक्षित करें

एक agent box उतना ही सुरक्षित होता है जितना कि उसके चारों ओर का सर्वर। दो और परतें इस काम को पूरा करती हैं। SSH को केवल key-based authentication पर ले जाएँ और root login को बंद करें, जैसा कि VPS पर SSH hardening में बताया गया है, ताकि जिस account से आप box को manage करते हैं, उसे brute-force न किया जा सके। इसके बाद Fail2ban जोड़ें ताकि उन scanners को बाहर निकाला जा सके जो हर public port पर हमला करते हैं। इनमें से कोई भी सीधे OpenClaw को प्रभावित नहीं करता है, लेकिन दोनों उन रास्तों को बंद कर देते हैं जिनका उपयोग हमलावर उस तक पहुँचने के लिए करेंगे।

इसे अपडेटेड रखें, जानबूझकर

March 2026 के खुलासे वर्तमान रहने का सबसे स्पष्ट तर्क हैं। किसी agent में privilege-escalation bug साधारण web app की तुलना में कहीं अधिक गंभीर होता है, क्योंकि agent पहले से ही commands चलाता है। project के releases पर नज़र रखें, security updates को तुरंत लागू करें, और OpenClaw upgrade को टालने के बजाय routine maintenance के रूप में लें।

आप वास्तव में क्या hardening कर रहे हैं, यह समझने के लिए OpenClaw-style agent का architecture उन हिस्सों के बारे में बताता है जो काम करते हैं, और VPS पर अपना AI agent बनाना उस सामान्य स्वरूप को कवर करता है जो कोई भी agent लेता है। यदि आप इसके साथ दूसरा agent चलाते हैं, तो याद रखें कि एक VPS पर दो Claude Code sessions एक-दूसरे को काम सौंप सकते हैं, इसलिए प्रत्येक को आपके account को inherit करने के बजाय अपना स्वयं का account और अपनी सीमाएं चाहिए।

FAQ

क्या public VPS पर OpenClaw चलाना सुरक्षित है?

यदि आप इसे सुरक्षित (harden) करते हैं, तो यह सुरक्षित हो सकता है। OpenClaw को शक्तिशाली बनाया गया है: यह shell commands चलाता है और browser को नियंत्रित करता है, इसलिए लापरवाही से किया गया setup वास्तव में खतरनाक है। इस project में पहले ही एक critical CVE (मार्च 2026 में CVE-2026-32922) आ चुका है। इसका security model यह अपेक्षा करता है कि आप, operator के रूप में, सीमाएँ निर्धारित करेंगे। इसे एक unprivileged user के रूप में चलाएँ, इसके gateway को default-deny firewall के पीछे loopback पर रखें, इसकी API keys को अलग रखें और इसे एक hardened systemd service के रूप में चलाएँ।

क्या मुझे OpenClaw gateway को internet पर expose करना चाहिए?

नहीं। Gateway default रूप से loopback पर bind होता है, और आपको इसे वहीं रहने देना चाहिए। यह एकमात्र process है जो agent को नियंत्रित करती है, इसलिए एक exposed gateway उस चीज़ का remote path बन जाता है जो commands चलाने का काम करती है। यदि आपको इसे remote रूप से access करने की आवश्यकता है, तो port खोलने के बजाय VPN या SSH tunnel का उपयोग करें।

OpenClaw को किस user के रूप में चलाना चाहिए?

इसे एक समर्पित system user के रूप में चलाएँ जिसके पास login shell और sudo न हो, और इसे कभी भी root के रूप में न चलाएँ। यदि agent breach होता है, तो उसका user account ही नुकसान की सीमा तय करता है, इसलिए उस account के पास केवल /opt/openclaw जैसी directory के अंतर्गत अपनी ही files होनी चाहिए, और कुछ नहीं।

मैं OpenClaw की API keys को सुरक्षित कैसे रखूँ?

उन्हें ऐसी file में store करें जिसे केवल OpenClaw user ही पढ़ सके (mode 600) और इसे systemd के EnvironmentFile के साथ service में load करें। key को unit file, अपनी shell history और किसी भी git repository से दूर रखें। यदि आपको कभी भी संदेह हो कि key leak हुई है, तो उसे rotate कर दें।