SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-30

Ollama API ला पासवर्ड नाही: port 11434 सुरक्षित करा

Ollama server मध्ये authentication नसल्याने port 11434 पर्यंत पोहोचणारा कोणीही models चालवू, download किंवा delete करू शकतो. उपाय क्रमाने जाणून घ्या.

Ollama API ला पासवर्ड नाही

Ollama API मध्ये authentication नाही. तुम्ही चालवत असलेल्या server मध्ये user, password, key check किंवा allowlist यापैकी काहीही नाही. port 11434 वर TCP connection उघडू शकणारी कोणतीही व्यक्ती तुमचे models सूचीबद्ध करू शकते, ते चालवू शकते, नवीन models download करू शकते आणि तुमच्याकडे असलेले models delete करू शकते.

अधिकृत documentation मध्ये हे स्पष्टपणे नमूद केले आहे: "http://localhost:11434 द्वारे Ollama API ला स्थानिकरित्या access करताना authentication आवश्यक नाही." स्थानिकरित्या हा शब्द संपूर्ण security model स्पष्ट करतो. Ollama defaultनुसार 127.0.0.1 वर bind होते. त्यामुळे laptop वर loopback interface हेच access control असते. हा listener public address वर हलवल्यास access control नाहीसे होते, कारण त्याची जागा घेणारी कोणतीही सुरक्षा उरत नाही.

म्हणूनच VPS (virtual private server) वर हे महत्त्वाचे ठरते. Default configuration सुरक्षित असते. बहुतेक लोक करतात तो पहिला बदल म्हणजे दुसऱ्या machine ला model वापरता यावा म्हणून listener उघडणे. हाच बदल सर्व protection एकाच वेळी काढून टाकतो.

उघडा port 11434 काय उघड करतो

प्रत्येक endpoint उपलब्ध असतो. Read-only mode किंवा स्वतंत्र admin port नसतो. localhost ऐवजी server address ला पाठवलेल्या या वास्तविक requests आहेत:

# 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 असलेल्या plan मध्ये सततचा load म्हणजे तुमचे allowance अनोळखी व्यक्ती वापरत आहे. तुम्ही एकमेव caller नसल्यावर VPS वरील AI workload चे खर्च नियंत्रणात ठेवणे अधिक कठीण होते.
  • /api/pull तुमच्या disk वर लिहिते. प्रत्येक model चा आकार दोन ते चाळीस gigabytes असतो. Pulls चे loop volume भरते. Disk पूर्ण भरल्यास Ollama सोडून box वरील इतर प्रत्येक service बिघडते.
  • Requests तुमच्या process मध्ये येतात आणि log केल्या जातात. Default log level मध्ये Ollama केवळ metadata नोंदवते. त्यामुळे endpoint, status, latency आणि client address नोंदवले जातात; prompt text नोंदवला जात नाही. तरीही तुमचा box कोणी आणि कशासाठी वापरला याची नोंद तुमच्या journal मध्ये राहते. ही नोंद गोळा करण्याची निवड तुम्ही केलेली नसते.
  • /api/delete models काढून टाकते. ते परत मिळवण्यासाठी तुमच्या स्वतःच्या bandwidth वरून ते पुन्हा download करावे लागतात.

यापैकी कशासाठीही exploit आवश्यक नाही. Document केलेले API जसे डिझाइन केले आहे तसेच कार्य करते.

Ed25519 key हे access control नाही

"ollama API key" शोधल्यावर दोन वेगळ्या गोष्टी आढळतात. यापैकी कोणतीही तुमच्या server साठी password नाही. त्या वेगळ्या ओळखल्यास बहुतेक गोंधळ दूर होतो.

पहिली गोष्ट म्हणजे identity key pair. Ollama पहिल्यांदा सुरू झाल्यावर Ed25519 key pair तयार करते. Linux वर install script ollama नावाचा system user तयार करते आणि त्याचे home directory /usr/share/ollama येथे ठेवते. त्यामुळे key pair येथे असते:

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

ही key बाहेरच्या दिशेने वापरली जाते. ollama signin public half तुमच्या ollama.com account शी नोंदवते. Registry वर model push करण्यासाठी किंवा private model pull करण्यासाठी तीच authorization देते. ती तुमच्या machine ची ओळख ollama.com कडे सिद्ध करते. तुमच्या machine ला connect होणाऱ्या clients कडून ती काहीही मागत नाही. ती delete करणे, rotate करणे किंवा ती कधीही तयार न करणे यामुळे तुमच्या API ला कोण call करू शकतो यावर काहीही परिणाम होत नाही.

दुसरी गोष्ट म्हणजे OLLAMA_API_KEY. या variable मध्ये तुम्ही https://ollama.com/settings/keys येथे तयार केलेली key असते. Hosted API ला https://ollama.com/api येथे call करताना तुमचा client ती Authorization: Bearer $OLLAMA_API_KEY म्हणून पाठवतो. हे त्यांच्या service साठीचे credential आहे आणि client म्हणून तुम्ही ते वापरता. तुमचे स्वतःचे ollama serve ते कधीही read करत नाही. तुमच्या VPS वर OLLAMA_API_KEY set केल्याने VPS वर password लागू होत नाही.

म्हणून सुरू करण्यासाठी कोणतेही setting नाही. खालील तीन संरक्षणपद्धती एकाच प्रकारे कार्य करतात: port unreachable ठेवा आणि त्यापुढे तपासणी करणारी यंत्रणा ठेवा.

तुमचा सर्व्हर सध्या कोणत्या पत्त्यांवर ऐकत आहे ते तपासा

sudo ss -tlnp | grep 11434

सुरक्षित परिणामात loopback पत्ता दिसतो:

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

उघड्या परिणामात प्रत्येक interface दिसतो:

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

0.0.0.0 म्हणजे या मशीनवरील सर्व IPv4 पत्ते, त्यात public पत्त्याचाही समावेश होतो. *:11434 आणि [::]:11434 यांचा IPv6 समाविष्ट असताना तोच अर्थ होतो.

आता बाहेरून पडताळणी करा. ही कमांड सर्व्हरवर नव्हे, तर तुमच्या laptop वर चालवा:

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 हे देखील अपेक्षित उत्तर आहे. version field असलेला JSON object म्हणजे विनंती करणाऱ्या कोणालाही संपूर्ण API उपलब्ध आहे. सर्व्हरवरच curl वापरून केलेली चाचणी काहीही सिद्ध करत नाही, कारण loopback नेहमी उत्तर देतो.

उघडेपणा सहसा दोनपैकी एका मार्गाने निर्माण होतो. पहिला मार्ग म्हणजे जाणीवपूर्वक केलेला बदल. दुसऱ्या मशीनला model पर्यंत पोहोच आवश्यक असल्यामुळे कोणीतरी हा बदल केलेला असतो:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

ही एकच line संपूर्ण उघडेपणाचे कारण आहे. दुसरा मार्ग Docker आहे. त्यासाठी तुम्हाला काहीही edit करण्याची गरज नसते. त्यासाठी खाली स्वतंत्र section आहे.

संरक्षण 1: ते localhost वर ठेवा आणि tunnel द्वारे जोडा

हा उपाय प्रथम वापरा. यासाठी नवीन software आवश्यक नाही आणि leak होऊ शकणारे कोणतेही credential तयार होत नाही. हा port public interface वर कधीच उपलब्ध नसतो, त्यामुळे scanning द्वारे तो सापडत नाही.

default वर अवलंबून न राहता bind address स्पष्टपणे सेट करा:

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 files त्यांच्या path सह सूचीबद्ध करण्यासाठी systemctl cat ollama.service चालवा. त्यानंतर जुनी file हटवा.

तुमच्या 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 उघडते आणि तिथे येणारे सर्व काही 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 याचा अर्थ त्या port वर तुमच्या laptop वरील स्वतःचे Ollama चालू आहे. त्यामुळे -L 11500:127.0.0.1:11434 वापरून वेगळा local port निवडा आणि client ला 11500 कडे निर्देशित करा. tunnel यशस्वीपणे connect झाल्यानंतरही रिकादा reply मिळत असल्यास SSH कार्यरत आहे, पण server वरील बाजूस Ollama 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 join करण्यासाठी key आवश्यक असलेल्या interface वरच उपलब्ध राहतो. यामुळे firewall मधील चुकीची rule असली तरी ही रचना सुरक्षित राहते. चुकून world ला परवानगी देणारी rule लागू झाली तरी public interface वर listener उपलब्ध नसल्याने तो उघड करता येत नाही.

संरक्षण 2: bearer token तपासणारा reverse proxy

सार्वजनिक इंटरनेटवरील एखाद्या स्रोताला model ला call करणे आवश्यक असल्यास, Ollama ला loopback वर ठेवा आणि त्याच्या पुढे proxy ठेवा. Proxy TLS (transport layer security) termination करतो आणि योग्य header नसलेल्या विनंत्या नाकारतो. Ollama अजूनही फक्त 127.0.0.1 कडून connections स्वीकारतो, त्यामुळे proxy हाच आत येण्याचा एकमेव मार्ग राहतो.

प्रथम खरा token तयार करा. तो हाताने तयार करू नका:

openssl rand -base64 36

तो token तपासणारी 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;
    }
}

या configuration मधील पाच ओळी प्रत्यक्ष काम करतात. त्यांपैकी प्रत्येक ओळ अन्यथा उद्भवणारे एक failure टाळते.

nginx मधील if block च्या आत location वापरणे सहसा चुकीचे ठरते. मात्र नेमका return असलेला body ही predictably काम करणाऱ्या दोन forms पैकी एक आहे. त्यामुळे येथे हा वापर सुरक्षित आहे.

location = /api/pull हा exact match आहे. nginx, location / prefix पेक्षा exact matches ला अधिक प्राधान्य देतो. त्यामुळे token तपासण्यापूर्वीच हे तीन endpoints नाकारले जातात. वैध token मुळे inference करता येते; disk भरता येत नाही.

proxy_set_header Host 127.0.0.1:11434; महत्त्वाचे आहे, कारण Ollama येणाऱ्या Host आणि Origin headers तपासतो. Proxy चे public hostname थेट पुढे पाठवल्यास 403 Forbidden Ollama कडून आलेले असू शकते, nginx कडून नाही. त्यामुळे debugging करताना गोंधळ होतो. विशिष्ट origin ला परवानगी आवश्यक असलेल्या browser client साठी OLLAMA_ORIGINS हा दुसरा control आहे.

proxy_buffering off; महत्त्वाचे आहे, कारण Ollama response token by token stream करतो. Buffering सुरू असल्यास nginx हा stream धरून ठेवतो आणि generation पूर्ण झाल्यावर तो एकाच वेळी पाठवतो. त्यामुळे संपूर्ण 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 नोंदवले जाते. Request प्रत्यक्षात सुरूच होती. nginx ने ती थांबवली.

दोन्ही paths reload करून तपासा:

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

पहिल्या command ने 401 print केले पाहिजे. दुसऱ्या command ने तुमची model list print केली पाहिजे. पहिल्या command नेही model list दिल्यास map block चुकीच्या scope मध्ये आहे. तो http level वर असणे आवश्यक आहे. त्यामुळे तो /etc/nginx/conf.d/ अंतर्गत एखाद्या file मध्ये किंवा server block च्या वर ठेवा; server च्या आत कधीही ठेवू नका.

Caddy हेच काम basic authentication वापरून चार lines मध्ये करतो. त्यामुळे browser client साठी bearer token पेक्षा ही पद्धत अधिक योग्य ठरते:

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

अपेक्षित bcrypt hash तयार करण्यासाठी caddy hash-password चालवा. येथे एक naming trap आहे: Caddy v2.8 पूर्वी directive basicauth होती आणि आता ती basic_auth आहे. त्यामुळे जुन्या guide मधून copy केलेली config load होत नाही आणि Caddy ला ओळखता न आलेल्या directive चे नाव दाखवते.

तुम्ही कोणताही proxy निवडला तरी हा सर्व clients साठी एकच shared secret असतो. तो असलेल्या प्रत्येक client ला समान access मिळतो. तो रद्द करण्यासाठी config edit करावी लागते आणि त्याच वेळी प्रत्येक caller update करावा लागतो.

संरक्षण 3: प्रत्येक क्लायंटसाठी key जारी करणारा gateway

एकापेक्षा अधिक व्यक्ती किंवा अॅप्लिकेशनने model ला विनंत्या पाठवायला सुरुवात केली की shared token अपुरा ठरतो. लोड कोणत्या client मुळे निर्माण झाला हे कळत नाही. तसेच सर्व clients बंद केल्याशिवाय त्यांपैकी एकाला स्वतंत्रपणे थांबवता येत नाही. Proxy ज्या ठिकाणी होता, त्याच ठिकाणी gateway ठेवला जातो. तो त्याच OpenAI-compatible API द्वारे संवाद साधतो, प्रत्येक client साठी स्वतंत्र key जारी करतो आणि प्रत्येक key ने केलेल्या वापराची नोंद ठेवतो. Self-hosted LiteLLM gateway हा यासाठी नेहमीचा पर्याय आहे. Access control व्यतिरिक्त तो प्रत्येक key साठी budgets आणि request logs उपलब्ध करून देतो.

Defence 1 मधील नियम बदलत नाही. Ollama 127.0.0.1 ला bind होते, त्याच्याशी संवाद साधणारी एकमेव प्रक्रिया gateway असते आणि public listener असलेली एकमेव service gateway असते. ज्या मशीनवर port 11434 अजूनही जगासाठी खुला आहे, त्या मशीनवरील gateway केवळ दिखावा ठरतो, कारण callers त्याला सहज वळसा घालून थेट Ollama शी संवाद साधू शकतात.

फायरवॉलचा सापळा: प्रकाशित container port UFW ला वगळतो

यामुळेच फायरवॉल योग्यरीत्या configure केलेल्या सर्व्हरवरही बाहेरून उघड्या instances आढळतात.

UFW (uncomplicated firewall) आपले rules kernel च्या filter table मधील INPUT chain मध्ये लिहितो आणि INPUT host स्वतःला उद्देशून असलेली packets हाताळतो. Docker चा -p flag nat table मधील PREROUTING chain मध्ये destination NAT (network address translation) rule लिहितो. Kernel packet कुठे पाठवायची हे ठरवण्यापूर्वी हा rule evaluate करतो. Routing decision होईपर्यंत destination container च्या address मध्ये बदललेले असते. त्यामुळे packet स्थानिकरीत्या deliver होण्याऐवजी forward केली जाते आणि ती INPUT ऐवजी FORWARD मधून जाते. UFW चे INPUT rules तपासलेच जात नाहीत. त्यामुळे packet फायरवॉलमधून जाण्याऐवजी फायरवॉलला वळसा घालते.

म्हणूनच खालील sequence port 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 default deny सह firewall active असल्याचे दाखवतो. दोन्ही निष्कर्ष एकाच वेळी बरोबर असतात. यामुळेच लोक चुकीच्या निष्कर्षावर विश्वास ठेवतात. हे करणारा rule तुम्ही पाहू शकता:

sudo iptables -t nat -L DOCKER -n

publish flag मध्ये एक address देणे हा उपाय आहे:

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 निर्दिष्ट केल्याने mapping ची host बाजू loopback ला बांधली जाते. त्यामुळे तुमचा SSH tunnel आणि reverse proxy त्यापर्यंत पोहोचू शकतात, पण इंटरनेटवरून पोहोचता येत नाही. येथे container पुन्हा तयार करणे सुरक्षित आहे, कारण models container मध्ये नसून named ollama volume मध्ये आहेत.

दोन्ही views मध्ये समान माहिती आहे याची खात्री करा:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama ने 11434/tcp -> 127.0.0.1:11434 print केले पाहिजे. 0.0.0.0:11434 print झाल्यास सर्व्हर अजूनही बाहेरून उघडा आहे. ही यंत्रणा एकदा समजून घेतली की तुम्ही प्रकाशित केलेल्या प्रत्येक container साठी ती लागू करता येते: Docker चे published ports UFW ला का वगळतात येथे DOCKER-USER chain आणि Docker restart नंतरही टिकणारे rules समजावले आहेत. Host policy स्वतः तयार करत असाल, तर नवीन VPS साठी आवश्यक UFW rules हा त्याचा आधार स्पष्ट करते. Rocky किंवा AlmaLinux वर configure करण्यासाठी UFW नसतो. त्यामुळे firewalld मध्ये लिहिलेली तीच आधारभूत policy येथून सुरुवात करा.

प्रक्रिया कोणत्या वापरकर्त्याच्या खात्याने चालू आहे

Linux install script एक स्वतंत्र account तयार करते आणि सेवा त्याच account अंतर्गत चालवते:

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

/etc/systemd/system/ollama.service मधील unit नंतर User=ollama आणि Group=ollama सेट करते. त्यात बदल करू नका. टर्मिनलमध्ये हाताने सुरू केलेले तात्पुरते ollama serve तुम्ही login केलेल्या account अंतर्गत चालते. ते account root असल्यास, authentication नसलेले API root म्हणून files लिहिते. ते कोणत्या account अंतर्गत चालू आहे ते तपासा:

ps -o user= -C ollama

उत्तर ollama असावे. यापेक्षा वेगळे काही आढळल्यास, unit सोबत किंवा त्याऐवजी हाताने सुरू केलेली प्रक्रिया चालू आहे. नंतर जोडलेल्या प्रत्येक daemon साठीही हाच विचार लागू होतो आणि किमान विशेषाधिकार असलेल्या वापरकर्त्यांखाली सेवा चालवणे ही बाब योग्य प्रकारे हाताळते.

Ollama API endpoint सुरक्षित आहे का हे कसे तपासावे

तुम्ही कोणतीही पद्धत निवडली असली, तरी एक चाचणी निश्चित उत्तर देते. ती दुसऱ्या मशीनवरून चालवावी:

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

दोन्ही विनंत्या timeout व्हाव्यात किंवा नाकारल्या जाव्यात. तुम्ही proxy तयार केला असल्यास, proxy hostname वरील त्याच दोन paths ने credentials शिवाय 401 परत करावे आणि credentials दिल्यावर खरे JSON परत करावे.

त्यानंतर access log एकदा वाचा. पोर्ट उघडा असताना कोणाला तो सापडला का, हे त्यातून समजते:

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

Ollama प्रत्येक request साठी एक ओळ लिहिते आणि client address समाविष्ट करते:

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

Ollama loopback वर bind केल्यानंतर प्रत्येक ओळीत 127.0.0.1 एकदा दिसायला हवे, कारण connection फक्त याच address वरून येऊ शकते. त्या column मध्ये public address दिसत असल्यास request बाहेरून आली आहे. Timestamp वरून ती कधी आली ते समजते. त्या command कडून कोणतेही output न मिळणे, हेच अपेक्षित परिणाम आहे. Ollama बाबतचा हा भाग तुमच्यासाठी नवीन असल्यास, VPS वर Ollama चालवणे या मार्गदर्शकात install, model sizing आणि प्रत्यक्षात काय load होईल हे ठरवणाऱ्या memory limits यांचा समावेश आहे.

FAQ

Ollama कडे API key किंवा password आहे का?

नाही. तुम्ही चालवत असलेल्या server वर कोणत्याही प्रकारचे authentication नाही. API वापरण्यासाठी authentication आवश्यक नसल्याचे अधिकृत documentation मध्ये नमूद केले आहे. “Ollama API key” म्हटल्या जाणाऱ्या दोन्ही गोष्टी याच्या उलट दिशेने निर्देश करतात. /usr/share/ollama/.ollama/ मधील Ed25519 pair तुमचे machine ollama.com समोर प्रमाणित करते, त्यामुळे तुम्ही models push करू शकता आणि private models pull करू शकता. OLLAMA_API_KEY हे तुमचा client https://ollama.com/api वरील hosted API कडे पाठवतो असे credential आहे. तुमचे स्वतःचे ollama serve यापैकी कोणतेही वाचत नाही. त्यामुळे access control network किंवा समोरील proxy कडून लागू करावे लागते.

Firewall असल्यास OLLAMA_HOST=0.0.0.0 सुरक्षित आहे का?

त्या box वर इतर कोणतीही प्रक्रिया firewall rules लिहित नसेल, तोपर्यंतच. 0.0.0.0 याचा अर्थ listener public interface वर प्रत्यक्ष उपलब्ध आहे आणि त्याला unreachable ठेवण्यासाठी तुम्ही केवळ firewall वर अवलंबून आहात. Docker ने port publish केल्यावर हा विश्वास तुटतो. कारण Docker ने nat table मध्ये जोडलेला DNAT rule packet INPUT chain पर्यंत पोहोचण्यापूर्वी लागू होतो. UFW याच chain वर कार्य करते. त्यामुळे packet forward होतो आणि UFW ला तो दिसत नाही. 127.0.0.1 किंवा private tunnel address वर bind केल्यास listener public interface वरून हटतो. त्यामुळे firewall configuration मधील चुकीमुळे expose करण्यासाठी काहीही उरत नाही.

माझा Ollama port internet साठी खुला आहे का हे कसे तपासू?

Server वर sudo ss -tlnp | grep 11434 चालवा आणि वेगळ्या machine वरून 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 reachable आहे. Server वरच curl वापरून कधीही चाचणी करू नका. Bind address काहीही असला तरी loopback त्याला उत्तर देतो.

Port 11434 वरून एखाद्या random port वर हलवू शकतो का?

नाही. याचे कारण स्पष्टपणे समजून घेणे महत्त्वाचे आहे. वेगळा port वापरल्याने केवळ एका port ची scan मंदावते. Scanners संपूर्ण range तपासतात. तसेच /api/tags कडे केलेली एक request service कोणत्याही port वर आली तरी ती ओळखते. Port बदलल्याने प्रत्येक client चा default तुटतो आणि पुढे तुमची स्वतःची configuration समजून घेणे कठीण होते. त्याऐवजी loopback वर bind करा. यामुळे listener दुसरीकडे हलवला जात नाही, तर public interface वरून हटवला जातो.

माझ्या उघड्या Ollama पर्यंत कोणीतरी पोहोचले. मी काय तपासावे?

प्रथम त्याला 127.0.0.1 वर bind करा आणि service restart करा. त्यामुळे तपास सुरू करण्यापूर्वी exposure थांबेल. त्यानंतर कोणत्या बाहेरील addresses ने कोणत्या endpoints ला आणि केव्हा call केले हे पाहण्यासाठी journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 चालवा. ollama list ची तुलना तुम्हाला अपेक्षित असलेल्या models शी करा. /api/pull मध्ये authentication नसते. त्यामुळे तुम्ही pull न केलेला model हा disk usage तसेच घटनेचा पुरावा असतो. df -h वापरून मोकळी जागा तपासा. Default log level वर Ollama prompt text नोंदवत नाही. त्यामुळे कोणी आणि कोणत्या model साठी विनंती केली याची नोंद मिळते; काय generate झाले याची नाही.

#ollama#security#api#firewall#reverse-proxy