लेखक: Matt Connor 2026-08-15 · अपडेट किया गया: 2026-08-23

Ollama API को सुरक्षित कैसे करें: पोर्ट 11434 की समस्या

Q: मैं यह कैसे जाँचूँ कि मेरा Ollama port internet के लिए खुला है या नहीं?

सर्वर पर sudo ss -tlnp | grep 11434 चलाएँ, और किसी अन्य मशीन से curl -m 5 http://YOUR_SERVER_IP:11434/api/version का उपयोग करें। ss में 127.0.0.1:11434 दिखना और remote curl का timeout होना ही वह परिणाम है जो आप चाहते हैं। यदि ss में 0.0.0.0:11434 या *:11434 दिखाई देता है और remote curl JSON लौटाता है, तो इसका मतलब है कि पूरा API पहुँच योग्य है। सर्वर पर स्वयं curl के साथ परीक्षण कभी न करें, क्योंकि loopback address पर bind address चाहे जो भी हो, वह हमेशा उत्तर देगा।

Q: किसी ने मेरे खुले Ollama तक पहुँच प्राप्त कर ली है। मुझे क्या जाँच करनी चाहिए?

सबसे पहले इसे 127.0.0.1 पर bind करें और service को restart करें, ताकि जाँच शुरू करने से पहले exposure रुक जाए। फिर यह देखने के लिए journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 चलाएँ कि किन बाहरी addresses ने किन endpoints को और कब call किया। ollama list की तुलना उन models से करें जिन्हें आपने रखा था, क्योंकि /api/pull unauthenticated है और कोई भी model जिसे आपने pull नहीं किया है, वह disk usage और intrusion का प्रमाण है। df -h के साथ free space की जाँच करें। Ollama default log level पर prompt text को record नहीं करता है, इसलिए आपके पास इस बात का record तो होगा कि किसने और किस model के लिए पूछा, लेकिन यह record नहीं होगा कि क्या generate किया गया था।

Ollama API में डिफ़ॉल्ट रूप से कोई authentication नहीं होता है। पोर्ट 11434 खुला होने पर कोई भी आपके मॉडल चला सकता है। इसे सुरक्षित करने के तीन प्रभावी तरीके यहाँ जानें।

Ollama API में कोई पासवर्ड नहीं है

Ollama API में कोई authentication नहीं है। आपके द्वारा चलाए जा रहे सर्वर में कोई user, कोई password, कोई key check और कोई allowlist नहीं है। जो कोई भी port 11434 पर TCP connection खोल सकता है, वह आपके models की सूची देख सकता है, उन्हें चला सकता है, नए models download कर सकता है और आपके पास मौजूद models को delete कर सकता है।

आधिकारिक documentation में यह स्पष्ट रूप से लिखा है: "Ollama's API को http://localhost:11434 के माध्यम से स्थानीय रूप से एक्सेस करते समय किसी authentication की आवश्यकता नहीं है।" स्थानीय रूप से (locally) शब्द ही पूरे security model को दर्शाता है। Ollama डिफ़ॉल्ट रूप से 127.0.0.1 पर bind होता है, इसलिए laptop पर loopback interface ही access control का काम करता है। यदि आप उस listener को public address पर ले जाते हैं, तो access control समाप्त हो जाता है, क्योंकि उसकी जगह कोई अन्य सुरक्षा उपाय नहीं लगाया गया है।

इसीलिए VPS (virtual private server) पर यह महत्वपूर्ण है। डिफ़ॉल्ट स्थिति सुरक्षित है। अधिकांश लोग जो पहला बदलाव करते हैं, यानी listener को खोलना ताकि कोई दूसरी machine model का उपयोग कर सके, वही बदलाव एक साथ सारी सुरक्षा को खत्म कर देता है।

ओपन पोर्ट 11434 क्या जानकारी उजागर करता है

हर एक एंडपॉइंट। इसमें कोई read-only मोड नहीं है और न ही कोई अलग एडमिन पोर्ट है। ये वास्तविक अनुरोध हैं, जो localhost के बजाय सीधे सर्वर पते पर भेजे जाते हैं:

# List every model on the box
curl http://SERVER_IP:11434/api/tags

# See what is loaded into memory right now
curl http://SERVER_IP:11434/api/ps

# Run a prompt on your hardware
curl http://SERVER_IP:11434/api/generate -d '{"model":"llama3.2","prompt":"Why is the sky blue?"}'

# Write several gigabytes to your disk
curl http://SERVER_IP:11434/api/pull -d '{"model":"llama3.2"}'

# Remove a model
curl -X DELETE http://SERVER_IP:11434/api/delete -d '{"model":"llama3.2"}'

ऑपरेटर के नजरिए से, चार चीजें गलत होती हैं:

आपका CPU या GPU किसी और के लिए inference चलाता है। fair-use CPU allowance वाले प्लान पर, निरंतर लोड का मतलब है कि आपका allowance कोई अजनबी खर्च कर रहा है, और जब आप एकमात्र उपयोगकर्ता नहीं रह जाते, तो VPS पर AI वर्कलोड लागत को नियंत्रित रखना काफी कठिन हो जाता है।
/api/pull आपकी डिस्क पर लिखता है। मॉडल्स का आकार दो से चालीस गीगाबाइट तक होता है। pulls का एक लूप वॉल्यूम को भर देता है, और डिस्क फुल होने पर केवल Ollama ही नहीं, बल्कि सर्वर पर चल रही अन्य सभी सेवाएं भी बंद हो जाती हैं।
अनुरोध आपकी प्रोसेस के भीतर आते हैं और लॉग हो जाते हैं। डिफ़ॉल्ट लॉग लेवल पर Ollama केवल मेटाडेटा रिकॉर्ड करता है, इसलिए आपको एंडपॉइंट, स्टेटस, लेटेंसी और क्लाइंट का पता मिलता है, प्रॉम्प्ट टेक्स्ट नहीं। यह अभी भी इस बात का रिकॉर्ड है कि आपके सर्वर का उपयोग किसने और किस लिए किया, जो आपके जर्नल में जमा होता रहता है, और आपने इसे इकट्ठा करने का विकल्प नहीं चुना था।
/api/delete मॉडल्स को हटा देता है। उन्हें वापस पाने का मतलब है अपने बैंडविड्थ का उपयोग करके उन्हें फिर से डाउनलोड करना।

इसके लिए किसी exploit की आवश्यकता नहीं है। यह documented API है जो बिल्कुल वैसे ही काम कर रहा है जैसे इसे डिज़ाइन किया गया है।

Ed25519 key access control नहीं है

"Ollama API key" सर्च करने पर आपको दो अलग-अलग चीजें मिलती हैं। इनमें से कोई भी आपके सर्वर का पासवर्ड नहीं है, और इनके बीच का अंतर समझने से अधिकांश भ्रम दूर हो जाता है।

पहली identity key pair है। Ollama पहली बार चलने पर एक Ed25519 key pair जनरेट करता है। Linux पर, install script ollama नाम का एक system user बनाती है, जिसकी home directory /usr/share/ollama पर होती है, इसलिए यह pair यहाँ स्थित होती है:

/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pub

यह key बाहर की ओर संकेत करती है। ollama signin public half को आपके ollama.com अकाउंट के साथ रजिस्टर करता है, और यही वह चीज है जो आपको registry में model push करने या private model pull करने के लिए अधिकृत (authorise) करती है। यह ollama.com के सामने आपकी मशीन की पहचान साबित करती है। यह आपकी मशीन से कनेक्ट होने वाले clients से कुछ नहीं मांगती। इसे delete करने, rotate करने या कभी न बनाने से इस पर कोई फर्क नहीं पड़ता कि आपकी API को कौन कॉल कर सकता है।

दूसरी OLLAMA_API_KEY है। वह variable उस key को रखता है जिसे आप https://ollama.com/settings/keys पर बनाते हैं, और आपका client इसे Authorization: Bearer $OLLAMA_API_KEY के रूप में भेजता है जब वह https://ollama.com/api पर hosted API को कॉल करता है। यह उनकी service के लिए एक credential है, जिसका उपयोग आप client के रूप में करते हैं। आपका अपना ollama serve इसे कभी नहीं पढ़ता। अपने VPS पर OLLAMA_API_KEY सेट करने से आपके VPS पर पासवर्ड नहीं लगता।

इसलिए, चालू करने के लिए कोई setting नहीं है। नीचे दी गई तीनों सुरक्षा प्रणालियाँ एक ही तरह से काम करती हैं: port को unreachable रखें, और उसके सामने कुछ ऐसा रखें जो वास्तव में जाँच (check) करता हो।

अभी आपका सर्वर किन पोर्ट्स पर listening है, यह जाँचें

sudo ss -tlnp | grep 11434

सुरक्षित परिणाम में loopback address दिखाई देता है:

LISTEN 0  4096  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

exposed परिणाम में हर interface का नाम होता है:

LISTEN 0  4096  0.0.0.0:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

0.0.0.0 का अर्थ है बॉक्स पर मौजूद सभी IPv4 addresses, जिसमें public address भी शामिल है। *:11434 और [::]:11434 का अर्थ IPv6 सहित यही समान स्थिति है।

अब बाहर से इसकी पुष्टि करें। इसे अपने सर्वर पर नहीं, बल्कि अपने लैपटॉप पर चलाएं:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version

curl: (28) Connection timed out after 5001 milliseconds वह उत्तर है जो आप चाहते हैं, और curl: (7) Failed to connect ... Connection refused भी यही है। यदि JSON object में version field दिखाई दे, तो इसका मतलब है कि पूरी API किसी के भी द्वारा एक्सेस की जा सकती है। सर्वर पर ही curl के साथ परीक्षण करने से कुछ सिद्ध नहीं होता, क्योंकि loopback हमेशा उत्तर देता है।

Exposure आमतौर पर दो तरीकों से होता है। पहला तरीका एक जानबूझकर किया गया बदलाव है, क्योंकि किसी को मॉडल तक पहुँचने के लिए दूसरे मशीन की आवश्यकता थी:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

वह एक लाइन ही पूरा exposure है। दूसरा तरीका Docker है, और इसमें आपको कुछ भी एडिट करने के लिए नहीं कहा जाता है। इसके बारे में नीचे एक अलग सेक्शन दिया गया है।

सुरक्षा 1: इसे localhost पर रखें और tunnel का उपयोग करें

सबसे पहले इसी तरीके को अपनाएं। इसमें किसी नए software की आवश्यकता नहीं है और यह ऐसा कोई credential नहीं बनाता जो leak हो सके। port कभी भी public interface पर मौजूद नहीं होता, इसलिए scanning के जरिए इसे ढूंढा नहीं जा सकता।

default पर निर्भर रहने के बजाय bind address को स्पष्ट रूप से set करें:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

यह /etc/systemd/system/ollama.service.d/override.conf लिखता है। इसे लागू करें और जांचें:

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434

ss में अब 127.0.0.1:11434 दिखना चाहिए। यदि यह अभी भी 0.0.0.0 दिखाता है, तो कोई दूसरा drop-in file प्रभावी हो रहा है। unit और उसके हर drop-in file को उसके path के साथ देखने के लिए systemctl cat ollama.service चलाएं, फिर पुराने file को delete कर दें।

अपने laptop से model का उपयोग करने के लिए, SSH के माध्यम से port forward करें:

ssh -N -L 11434:127.0.0.1:11434 you@your-server

-L 11434:127.0.0.1:11434 आपके laptop पर port 11434 खोलता है और वहां आने वाले किसी भी traffic को server के दृष्टिकोण से 127.0.0.1:11434 पर भेज देता है। -N SSH को remote command न चलाने के लिए कहता है, इसलिए process केवल tunnel को खुला रखती है। जब यह चल रहा हो, तो आपके laptop पर यह काम करता है:

curl -s http://localhost:11434/api/tags

आपको दो तरह की विफलताएं मिल सकती हैं। bind [127.0.0.1]:11434: Address already in use का अर्थ है कि आपका laptop उस port पर अपना खुद का Ollama चला रहा है, इसलिए -L 11500:127.0.0.1:11434 के साथ एक अलग local port चुनें और अपने client को 11500 पर point करें। एक tunnel के माध्यम से खाली reply मिलने का मतलब है कि SSH काम कर रहा है और Ollama server side पर listening नहीं कर रहा है, इसलिए SSH command को छूने से पहले वहां ss की जांच करें।

कई client machines के लिए, प्रति व्यक्ति एक tunnel बनाने से बेहतर एक private network है। machines को WireGuard या Tailscale पर रखें, फिर Ollama को 0.0.0.0 के बजाय उस network पर मौजूद उसके address से bind करें:

[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"

इसके बाद port केवल उसी interface पर मौजूद रहता है जिसे join करने के लिए key की आवश्यकता होती है। यह firewall की गलती से भी सुरक्षित रहता है, क्योंकि यदि कोई rule गलती से पूरी दुनिया को access दे भी दे, तो भी वह ऐसे listener को expose नहीं कर सकता जो public interface पर मौजूद ही नहीं है।

बचाव 2: एक reverse proxy जो bearer token की जाँच करता है

जब public internet से किसी चीज़ को model को call करना हो, तो Ollama को loopback पर रखें और उसके सामने एक proxy लगा दें। यह proxy TLS (transport layer security) को terminate करता है और सही header के बिना आने वाले requests को reject कर देता है। Ollama अभी भी केवल 127.0.0.1 से connections स्वीकार करता है, इसलिए proxy ही एकमात्र रास्ता है।

सबसे पहले एक असली token generate करें। इसे हाथ से न बनाएँ:

openssl rand -base64 36

एक nginx site जो इसकी जाँच करती है:

map $http_authorization $ollama_ok {
    default                                   0;
    "Bearer PASTE_YOUR_GENERATED_TOKEN_HERE"  1;
}

server {
    listen 443 ssl;
    server_name llm.example.com;

    ssl_certificate     /etc/letsencrypt/live/llm.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/llm.example.com/privkey.pem;

    location = /api/pull   { return 403; }
    location = /api/delete { return 403; }
    location = /api/push   { return 403; }

    location / {
        if ($ollama_ok = 0) { return 401; }

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host 127.0.0.1:11434;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

वहाँ पाँच पंक्तियाँ वास्तविक काम कर रही हैं, और प्रत्येक पंक्ति एक ऐसी विफलता को रोकती है जिसका सामना आपको अन्यथा करना पड़ता।

nginx में location block के अंदर if का उपयोग आमतौर पर एक बुरा विचार है, लेकिन ठीक return का body उन दो रूपों में से एक है जो पूर्वानुमानित (predictable) व्यवहार करते हैं, इसलिए यह उपयोग सुरक्षित है।

location = /api/pull एक exact match है, और nginx exact matches को location / prefix से ऊपर रखता है, इसलिए token पर विचार करने से पहले ही उन तीन endpoints को मना कर दिया जाता है। एक वैध token फिर inference की अनुमति देता है, न कि disk भरने की।

proxy_set_header Host 127.0.0.1:11434; महत्वपूर्ण है क्योंकि Ollama आने वाले Host और Origin headers का निरीक्षण करता है। proxy के public hostname को सीधे pass करने से ऐसा 403 Forbidden उत्पन्न हो सकता है जो nginx के बजाय Ollama से आया हो, जिसे debug करना भ्रमित करने वाला होता है। OLLAMA_ORIGINS दूसरा विकल्प है, उन browser clients के लिए जिन्हें एक विशिष्ट origin की अनुमति चाहिए।

proxy_buffering off; महत्वपूर्ण है क्योंकि Ollama अपने response को token-दर-token stream करता है। buffering चालू रहने पर, nginx stream को रोक कर रखता है और अंत में एक साथ deliver करता है, जिससे generation के दौरान आपका client frozen दिखाई देता है।

proxy_read_timeout 600s; महत्वपूर्ण है क्योंकि nginx का default समय 60 seconds है। CPU पर एक लंबी generation इसे आसानी से पार कर लेती है, client को 504 Gateway Time-out मिलता है, और /var/log/nginx/error.log में upstream timed out (110: Connection timed out) while reading response header from upstream record हो जाता है। request अभी भी काम कर रहा था, लेकिन nginx ने उसे बीच में ही छोड़ दिया।

Reload करें और दोनों paths का परीक्षण करें:

sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
curl -s -H "Authorization: Bearer YOUR_TOKEN" https://llm.example.com/api/tags

पहले वाले को 401 print करना चाहिए। दूसरे वाले को आपकी model list print करनी चाहिए। यदि पहला वाला भी model list लौटाता है, तो map block गलत scope में है। यह http level पर होना चाहिए, इसलिए इसे /etc/nginx/conf.d/ के अंतर्गत किसी file में या server block के ऊपर रखें, कभी भी server के अंदर न रखें।

Caddy चार पंक्तियों में basic authentication के साथ वही काम करता है, जो bearer token की तुलना में browser client के लिए अधिक उपयुक्त है:

llm.example.com {
	basic_auth {
		apiuser PASTE_BCRYPT_HASH_HERE
	}
	reverse_proxy 127.0.0.1:11434
}

इसके द्वारा अपेक्षित bcrypt hash बनाने के लिए caddy hash-password चलाएँ। एक नामकरण संबंधी समस्या: Caddy v2.8 से पहले directive basicauth था और अब basic_auth है, इसलिए पुरानी guide से copy की गई config load होने से मना कर देगी और Caddy उस directive का नाम बताएगा जिसे वह पहचान नहीं पाया।

आप चाहे जो भी proxy चुनें, यह सभी के लिए एक साझा secret है। इसे रखने वाले हर client की पहुँच समान होती है, और इसे revoke करने का अर्थ है config को edit करना और एक ही समय में हर caller को update करना।

बचाव 3: एक गेटवे जो प्रति क्लाइंट की जारी करता है

जब एक से अधिक व्यक्ति या एप्लिकेशन मॉडल को कॉल करते हैं, तो एक साझा टोकन अपर्याप्त हो जाता है। आप यह नहीं बता सकते कि किस क्लाइंट ने लोड उत्पन्न किया है, और आप उनमें से किसी एक को बाकी सभी को प्रभावित किए बिना ब्लॉक नहीं कर सकते। एक गेटवे उसी स्थान पर स्थित होता है जहाँ प्रॉक्सी थी, यह समान OpenAI-compatible API का उपयोग करता है, प्रति क्लाइंट एक अलग की (key) जारी करता है और प्रत्येक की (key) के उपयोग का रिकॉर्ड रखता है। एक self-hosted LiteLLM gateway इसके लिए सामान्य समाधान है, और यह एक्सेस कंट्रोल के साथ-साथ प्रति-की (per-key) बजट और रिक्वेस्ट लॉग्स की सुविधा भी जोड़ता है।

बचाव 1 का नियम नहीं बदलता है। Ollama को 127.0.0.1 पर बाइंड होना चाहिए, गेटवे एकमात्र ऐसी प्रक्रिया होनी चाहिए जो इससे बात करे, और गेटवे ही एकमात्र ऐसी सर्विस होनी चाहिए जो पब्लिक लिसनर के रूप में कार्य करे। यदि किसी सर्वर पर पोर्ट 11434 अभी भी दुनिया के लिए खुला है, तो वहां गेटवे लगाना केवल दिखावा है, क्योंकि कॉलर आसानी से इसे बायपास कर सकते हैं।

फायरवॉल का जाल: पब्लिश किया गया कंटेनर पोर्ट UFW को बायपास कर देता है

यही कारण है कि उन सर्वर्स पर भी exposed instances मौजूद होते हैं जिनके मालिकों ने फायरवॉल को सही ढंग से कॉन्फ़िगर किया होता है।

UFW (uncomplicated firewall) अपने नियम kernel की INPUT चेन और filter टेबल में लिखता है, और INPUT उन पैकेट्स को हैंडल करता है जो सीधे होस्ट के लिए होते हैं। Docker का -p फ्लैग nat टेबल की PREROUTING चेन में एक destination NAT (network address translation) नियम लिखता है। kernel यह तय करने से पहले कि पैकेट कहाँ जा रहा है, इस नियम का मूल्यांकन करता है। जब तक राउटिंग का निर्णय लिया जाता है, तब तक डेस्टिनेशन को कंटेनर के एड्रेस में बदला जा चुका होता है। इसलिए पैकेट को स्थानीय रूप से डिलीवर करने के बजाय फॉरवर्ड कर दिया जाता है और यह INPUT के बजाय FORWARD से होकर गुजरता है। UFW के INPUT नियमों को कभी चेक ही नहीं किया जाता, इसलिए पैकेट फायरवॉल के अंदर से गुजरने के बजाय उसे बायपास कर देता है।

यही कारण है कि यह सीक्वेंस पोर्ट 11434 को इंटरनेट के लिए खुला छोड़ देता है:

sudo ufw default deny incoming
sudo ufw enable
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

और sudo ufw status अभी भी यही रिपोर्ट करता है कि फायरवॉल सक्रिय है और डिफ़ॉल्ट रूप से deny पर सेट है। दोनों जानकारियां एक ही समय पर सही हैं, और यही कारण है कि लोग गलत जानकारी पर भरोसा कर बैठते हैं। आप वह नियम देख सकते हैं जिसने ऐसा किया:

sudo iptables -t nat -L DOCKER -n

इसका समाधान पब्लिश फ्लैग में एक एड्रेस जोड़ना है:

docker rm -f ollama
docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama

-p 11434:11434 असल में -p 0.0.0.0:11434:11434 का शॉर्टहैंड है। 127.0.0.1 का उपयोग करने से मैपिंग का होस्ट साइड लूपबैक (loopback) से बाइंड हो जाता है, जिससे आपका SSH टनल और रिवर्स प्रॉक्सी तो इसे एक्सेस कर पाते हैं, लेकिन इंटरनेट नहीं। कंटेनर को फिर से बनाना यहाँ सुरक्षित है क्योंकि मॉडल्स कंटेनर के अंदर नहीं, बल्कि नाम वाले ollama वॉल्यूम में रहते हैं।

पुष्टि करें कि दोनों व्यू अब एक समान हैं:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama को 11434/tcp -> 127.0.0.1:11434 प्रिंट करना चाहिए। यदि यह 0.0.0.0:11434 प्रिंट करता है, तो आप अभी भी exposed हैं। इस मैकेनिज्म को एक बार समझ लें, यह आपके द्वारा पब्लिश किए जाने वाले हर कंटेनर पर लागू होता है: Docker पब्लिश पोर्ट्स UFW को बायपास क्यों करते हैं में DOCKER-USER चेन और उन नियमों के बारे में बताया गया है जो Docker रीस्टार्ट के बाद भी बने रहते हैं। यदि आप अभी भी होस्ट पॉलिसी बना रहे हैं, तो एक नए VPS के लिए आवश्यक UFW नियम उस आधार को कवर करता है जिस पर यह सब टिका है। Rocky या AlmaLinux पर कॉन्फ़िगर करने के लिए UFW नहीं होता, इसलिए firewalld में लिखी गई समान बेस पॉलिसी से शुरुआत करें।

प्रोसेस किस यूजर के रूप में चल रही है

Linux इंस्टॉल स्क्रिप्ट एक समर्पित अकाउंट बनाती है और सर्विस को उसी के तहत चलाती है:

useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama

/etc/systemd/system/ollama.service पर मौजूद यूनिट फिर User=ollama और Group=ollama को सेट करती है। इसे न बदलें। टर्मिनल में हाथ से शुरू की गई एक त्वरित ollama serve उस यूजर के रूप में चलती है जिससे आपने लॉग इन किया है, और यदि वह root है, तो एक अनधिकृत API फाइलों को root के रूप में लिख रही होगी। जाँचें कि यह कौन सा है:

ps -o user= -C ollama

उत्तर ollama होना चाहिए। कुछ और होने का मतलब है कि हाथ से शुरू की गई प्रोसेस यूनिट के साथ या उसकी जगह चल रही है। यही सोच बाद में आपके द्वारा जोड़ी जाने वाली हर डेमन (daemon) पर लागू होती है, और कम से कम विशेषाधिकार वाले यूजर्स के रूप में सर्विस चलाना इसे सही ढंग से समझाता है।

Ollama API endpoint सुरक्षित है या नहीं, यह कैसे जाँचें

आप जो भी विकल्प चुनें, एक परीक्षण इसे स्पष्ट कर देगा, और इसे किसी अन्य मशीन से चलाना होगा:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tags

दोनों को time out हो जाना चाहिए या connection refuse होना चाहिए। यदि आपने proxy बनाया है, तो proxy hostname पर उन्हीं दो paths को बिना credentials के 401 return करना चाहिए और credentials के साथ वास्तविक JSON देना चाहिए।

इसके बाद access log को एक बार पढ़ें, क्योंकि यह बताता है कि क्या port खुले रहने के दौरान किसी ने उसे खोजा था:

journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1

Ollama प्रत्येक request के लिए एक line लिखता है और उसमें client का address शामिल होता है:

[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"

एक बार जब Ollama loopback पर bind हो जाता है, तो हर line में 127.0.0.1 दिखना चाहिए, क्योंकि यही वह एकमात्र address है जहाँ से connection आ सकता है। उस column में कोई public address होने का मतलब है कि बाहर से request आई है, और timestamp आपको समय बताता है। उस command से कोई output न मिलना ही वह परिणाम है जो आप चाहते हैं। यदि model का यह पक्ष आपके लिए नया है, तो VPS पर Ollama चलाना में install, model sizing और memory limits की जानकारी दी गई है, जो यह तय करती है कि वास्तव में क्या load होगा।

FAQ

क्या Ollama में कोई API key या password होता है?

नहीं। आपके द्वारा चलाए जा रहे सर्वर में किसी भी प्रकार का authentication नहीं होता है, और आधिकारिक documentation के अनुसार API तक पहुँचने के लिए किसी authentication की आवश्यकता नहीं है। "Ollama API key" कहे जाने वाले दोनों शब्द इसके विपरीत संकेत देते हैं। /usr/share/ollama/.ollama/ में मौजूद Ed25519 pair आपकी मशीन को ollama.com के लिए प्रमाणित करता है ताकि आप models को push और private models को pull कर सकें। OLLAMA_API_KEY एक credential है जिसे आपका client https://ollama.com/api पर स्थित hosted API को भेजता है। आपका अपना ollama serve इनमें से किसी को भी नहीं पढ़ता है, इसलिए access control को network स्तर पर या सामने लगे proxy के माध्यम से लागू करना होगा।

क्या `OLLAMA_HOST=0.0.0.0` सुरक्षित है यदि मेरे पास firewall है?

केवल तब तक, जब तक उस box पर कोई अन्य service firewall rules न लिखे। 0.0.0.0 का अर्थ है कि listener वास्तव में public interface पर मौजूद है, और आप इसे दुर्गम बनाए रखने के लिए पूरी तरह से firewall पर भरोसा कर रहे हैं। यह भरोसा उस क्षण टूट जाता है जब Docker कोई port publish करता है, क्योंकि Docker द्वारा nat table में जोड़ी गई DNAT rule का मूल्यांकन उस समय होता है जब packet उस INPUT chain तक पहुँचता जहाँ UFW स्थित है। परिणामस्वरूप, packet forward हो जाता है और UFW उसे देख ही नहीं पाता। 127.0.0.1 या किसी private tunnel address पर bind करने से listener public interface से हट जाता है, जिससे firewall की किसी गलती से भी कुछ expose होने का खतरा नहीं रहता।

मैं यह कैसे जाँचूँ कि मेरा Ollama port internet के लिए खुला है या नहीं?

सर्वर पर sudo ss -tlnp | grep 11434 चलाएँ, और किसी अन्य मशीन से curl -m 5 http://YOUR_SERVER_IP:11434/api/version का उपयोग करें। ss में 127.0.0.1:11434 दिखना और remote curl का timeout होना ही वह परिणाम है जो आप चाहते हैं। यदि ss में 0.0.0.0:11434 या *:11434 दिखाई देता है और remote curl JSON लौटाता है, तो इसका मतलब है कि पूरा API पहुँच योग्य है। सर्वर पर स्वयं curl के साथ परीक्षण कभी न करें, क्योंकि loopback address पर bind address चाहे जो भी हो, वह हमेशा उत्तर देगा।

क्या मैं port को 11434 से बदलकर किसी random port पर ले जा सकता हूँ?

नहीं, और इसका कारण स्पष्ट है। एक अलग port केवल एक single port के scan को धीमा करता है। Scanners पूरी range को scan करते हैं, और /api/tags पर एक request यह पहचान लेती है कि service किस port पर चल रही है। Port बदलने से हर client का default configuration भी टूट जाता है और बाद में आपके अपने setup को समझना कठिन हो जाता है। इसके बजाय loopback पर bind करें, जो listener को relocate करने के बजाय उसे पूरी तरह हटा देता है।

किसी ने मेरे खुले Ollama तक पहुँच प्राप्त कर ली है। मुझे क्या जाँच करनी चाहिए?

सबसे पहले इसे 127.0.0.1 पर bind करें और service को restart करें, ताकि जाँच शुरू करने से पहले exposure रुक जाए। फिर यह देखने के लिए journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 चलाएँ कि किन बाहरी addresses ने किन endpoints को और कब call किया। ollama list की तुलना उन models से करें जिन्हें आपने रखा था, क्योंकि /api/pull unauthenticated है और कोई भी model जिसे आपने pull नहीं किया है, वह disk usage और intrusion का प्रमाण है। df -h के साथ free space की जाँच करें। Ollama default log level पर prompt text को record नहीं करता है, इसलिए आपके पास इस बात का record तो होगा कि किसने और किस model के लिए पूछा, लेकिन यह record नहीं होगा कि क्या generate किया गया था।

#ollama #सुरक्षा #api #firewall #reverse-proxy

Ollama API में कोई पासवर्ड नहीं है

ओपन पोर्ट 11434 क्या जानकारी उजागर करता है

Ed25519 key access control नहीं है

अभी आपका सर्वर किन पोर्ट्स पर listening है, यह जाँचें

सुरक्षा 1: इसे localhost पर रखें और tunnel का उपयोग करें

बचाव 2: एक reverse proxy जो bearer token की जाँच करता है

बचाव 3: एक गेटवे जो प्रति क्लाइंट की जारी करता है

फायरवॉल का जाल: पब्लिश किया गया कंटेनर पोर्ट UFW को बायपास कर देता है

प्रोसेस किस यूजर के रूप में चल रही है

Ollama API endpoint सुरक्षित है या नहीं, यह कैसे जाँचें

FAQ

क्या Ollama में कोई API key या password होता है?

क्या OLLAMA_HOST=0.0.0.0 सुरक्षित है यदि मेरे पास firewall है?

मैं यह कैसे जाँचूँ कि मेरा Ollama port internet के लिए खुला है या नहीं?

क्या मैं port को 11434 से बदलकर किसी random port पर ले जा सकता हूँ?

किसी ने मेरे खुले Ollama तक पहुँच प्राप्त कर ली है। मुझे क्या जाँच करनी चाहिए?

क्या `OLLAMA_HOST=0.0.0.0` सुरक्षित है यदि मेरे पास firewall है?