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

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

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

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

अच्छी खबर भी है। OpenClaw आपके लिए पहले से ही एक सुरक्षित विकल्प चुनता है: इसका gateway, जो एकमात्र process है जो सब कुछ नियंत्रित करता है, default रूप से loopback address पर listen करता है। इसलिए, जब तक आप इसे expose करने के लिए विशेष प्रयास नहीं करते, तब तक यह internet से पहुंच योग्य नहीं होता है। नीचे दिया गया अधिकांश काम इसे उसी स्थिति में बनाए रखने और यदि कुछ गलत हो जाता है, तो नुकसान के दायरे (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 को install करें

OpenClaw एक npm package के रूप में वितरित किया जाता है, इसलिए यदि सर्वर पर Node.js नहीं है तो पहले उसे install करें; project के लिए Node 24.16 या उससे नया, या 26.1 या उससे नया version आवश्यक है। package को globally install करें, जो openclaw binary को हर user के लिए PATH में डाल देता है, फिर एक बार होने वाली onboarding प्रक्रिया चलाएं:

sudo npm install -g openclaw@latest --allow-scripts=openclaw
sudo -u openclaw openclaw onboard

--allow-scripts=openclaw flag का उपयोग इसलिए किया गया है क्योंकि npm 12 default रूप से package install scripts को block करता है, और OpenClaw को चलने के लिए अपनी script की आवश्यकता होती है। npm 11.15 या उससे पुराने version पर, जिसमें ऐसा कोई विकल्प नहीं है, इस flag को हटा दें। onboarding को openclaw user के रूप में चलाने का मतलब है कि agent की configuration उसके home directory, /opt/openclaw में सुरक्षित रहती है, न कि root की directory में। project एक curl -fsSL https://openclaw.ai/install.sh | bash installer भी प्रदान करता है जो एक ही line में वही install प्रक्रिया पूरी करता है। onboarding के दौरान --install-daemon flag को छोड़ दें: यह OpenClaw की अपनी service को register कर देगा, जबकि नीचे आपके द्वारा बनाई जाने वाली hardened systemd unit अधिक सख्त है।

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 कर दें।