SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-30

Ollama APIకి password ఎందుకు ఉండదు, రక్షణ ఎలా?

Ollama serverలో authentication ఉండదు. port 11434ను చేరగలిగినవారు modelsను run, download, delete చేయగలరు. వరుసగా చేయాల్సిన మూడు పరిష్కారాలు ఇవే.

Ollama APIకి password ఉండదు

Ollama APIలో authentication ఉండదు. మీరు నడుపుతున్న serverలో user, password, key check లేదా allowlist ఏదీ ఉండదు. TCP connection ను port 11434కి తెరవగలిగే ఏదైనా client మీ modelsను list చేయగలదు, వాటిని run చేయగలదు, కొత్త modelsను download చేయగలదు, మీ వద్ద ఉన్న modelsను delete చేయగలదు.

అధికారిక documentation దీన్ని స్పష్టంగా చెబుతుంది: "http://localhost:11434 ద్వారా Ollama APIని localగా access చేసేటప్పుడు authentication అవసరం లేదు." ఇందులోని localగా అనే పదమే మొత్తం 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ను తెరవడం చాలామంది చేసే మొదటి మార్పు. అదే మార్పుతో అన్ని రక్షణలు ఒకేసారి తొలగిపోతాయి.

ఓపెన్ port 11434 ఏమి బయటపెడుతుంది

ప్రతి endpoint అందుబాటులో ఉంటుంది. Read-only mode లేదు. ప్రత్యేక admin port కూడా లేదు. ఇవే నిజమైన requests; ఇవి localhost కు బదులుగా server address ను లక్ష్యంగా చేసుకుంటాయి:

# 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 లో sustained load అంటే, మీ allowance ను ఒక అపరిచితుడు వినియోగిస్తున్నాడని అర్థం. మీరు మాత్రమే caller కాకపోతే VPSపై AI workload ఖర్చులను నియంత్రించడం మరింత కష్టమవుతుంది.
  • /api/pull మీ disk పై రాస్తుంది. ప్రతి model పరిమాణం రెండు నుంచి నలభై gigabytes వరకు ఉంటుంది. Models ను వరుసగా pull చేయడం వల్ల volume నిండిపోతుంది. Disk పూర్తిగా నిండితే Ollama మాత్రమే కాదు, ఆ server లోని ప్రతి ఇతర service కూడా విఫలమవుతుంది.
  • Requests మీ process లోకి వస్తాయి మరియు log అవుతాయి. Default log level వద్ద Ollama metadata మాత్రమే నమోదు చేస్తుంది. అందువల్ల prompt text కాకుండా endpoint, status, latency మరియు client address లభిస్తాయి. అయినప్పటికీ, మీ server ను ఎవరు, ఏ పనికి ఉపయోగించారో తెలిపే record మీ journal లో నిల్వ అవుతుంది. దాన్ని సేకరించాలా వద్దా అని మీరు నిర్ణయించలేదు.
  • /api/delete models ను తొలగిస్తుంది. వాటిని తిరిగి పొందాలంటే మీ స్వంత bandwidth ఉపయోగించి మళ్లీ download చేయాలి.

ఇవేవీ exploit అవసరం లేకుండానే జరుగుతాయి. ఇది documented API రూపొందించిన విధంగానే పనిచేస్తోంది.

Ed25519 కీ access control కాదు

" Ollama API key" కోసం శోధిస్తే రెండు వేర్వేరు అంశాలు కనిపిస్తాయి. వీటిలో ఏదీ మీ server కు password కాదు. ఈ రెండింటిని వేరు చేస్తే ఎక్కువ గందరగోళం తొలగిపోతుంది.

మొదటిది identity key pair. Ollama మొదటిసారి run అయినప్పుడు 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 తో register చేస్తుంది. Registry కు model ను push చేయడానికి లేదా private model ను pull చేయడానికి ఇది మీకు authorization ఇస్తుంది. ఇది మీ machine ను ollama.com వద్ద నిర్ధారిస్తుంది. మీ machine కు connect అయ్యే clients నుంచి ఇది ఏదీ కోరదు. దీన్ని delete చేయడం, rotate చేయడం లేదా ఎప్పుడూ create చేయకపోవడం వల్ల మీ API ను ఎవరు call చేయవచ్చో మారదు.

రెండవది OLLAMA_API_KEY. ఈ variable లో మీరు https://ollama.com/settings/keys వద్ద create చేసే key ఉంటుంది. https://ollama.com/api వద్ద hosted API ను call చేసేటప్పుడు మీ client దాన్ని Authorization: Bearer $OLLAMA_API_KEY గా పంపుతుంది. ఇది వారి service కు సంబంధించిన credential. దీన్ని clientగా మీరు ఉపయోగిస్తారు. మీ స్వంత ollama serve దీన్ని ఎప్పుడూ read చేయదు. మీ VPS పై OLLAMA_API_KEY ను set చేయడం వల్ల మీ VPS పై password అమలులోకి రాదు.

కాబట్టి switch on చేయాల్సిన setting ఏదీ లేదు. దిగువన ఉన్న మూడు రక్షణ పద్ధతులు ఒకే విధంగా పనిచేస్తాయి: port అందుబాటులో లేకుండా ఉంచండి. ఆ port ముందు authentication ను తనిఖీ చేసే component ను ఉంచండి.

ప్రస్తుతం మీ సర్వర్ ఏ చిరునామాల్లో listening చేస్తుందో పరిశీలించండి

sudo ss -tlnp | grep 11434

సురక్షిత ఫలితంలో loopback చిరునామా కనిపిస్తుంది:

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

బయటికి expose చేసిన ఫలితంలో ప్రతి 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 చిరునామాతో సహా. IPv6 ను కూడా కలిపి చూపించే సమాన రూపాలు *:11434 మరియు [::]:11434.

ఇప్పుడు బయట నుంచి నిర్ధారించండి. దీన్ని serverపై కాకుండా మీ 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ను చేరుకోగలరని అర్థం. Serverపైనే curlతో పరీక్షించడం వల్ల ఏమీ నిరూపించబడదు, ఎందుకంటే loopback ఎల్లప్పుడూ స్పందిస్తుంది.

Exposure సాధారణంగా రెండు మార్గాల్లో జరుగుతుంది. మొదటిది ఉద్దేశపూర్వకంగా చేసిన edit. రెండో machine నుంచి modelను చేరుకోవాల్సి రావడంతో ఎవరో దీన్ని మార్చి ఉండవచ్చు:

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

ఆ ఒక్క line వల్లే మొత్తం exposure ఏర్పడుతుంది. రెండో మార్గం Docker. దీనికి మీరు ఏదీ edit చేయాల్సిన అవసరం ఉండదు. దాని గురించి కింది ప్రత్యేక sectionలో ఉంది.

రక్షణ 1: localhost లోనే ఉంచి tunnel ద్వారా చేరుకోండి

ముందుగా ఈ విధానాన్ని ఉపయోగించండి. దీనికి కొత్త software అవసరం లేదు. లీక్ కావచ్చిన 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 ను వాటి paths తో జాబితా చేయడానికి systemctl cat ollama.service అమలు చేయండి. తరువాత పాత file ను తొలగించండి.

మీ laptop నుంచి model ను ఉపయోగించడానికి port ను SSH ద్వారా 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 కు పంపుతుంది. SSH remote command ను అమలు చేయకుండా -N నిరోధిస్తుంది. అందువల్ల 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 వైపు పంపండి. Tunnel విజయవంతంగా connect అయినప్పటికీ reply ఖాళీగా ఉంటే, SSH సరిగ్గా పనిచేస్తోంది. Server వైపు Ollama listening చేయడం లేదని దీని అర్థం. SSH command ను మార్చే ముందు అక్కడ ss ను తనిఖీ చేయండి.

అనేక client machines కోసం ఒక్కో వ్యక్తికి ఒక్కో tunnel కంటే private network మెరుగైనది. ఆ machines ను WireGuard లేదా Tailscale పై ఉంచండి. తరువాత 0.0.0.0 కు బదులుగా ఆ network లోని address కు Ollama ను bind చేయండి:

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

అప్పుడు port లో చేరడానికి key అవసరమైన interface పై మాత్రమే అది ఉంటుంది. Firewall లో పొరపాటు జరిగినా ఇది రక్షణ కల్పిస్తుంది. ప్రపంచం నుంచి traffic ను అనుమతించే rule అనుకోకుండా ఉన్నప్పటికీ, public interface పై listener లేకపోతే అది బయటపడదు.

Defence 2: bearer token ను తనిఖీ చేసే reverse proxy

Public internet లోని ఏదైనా సేవ model ను పిలవాల్సి వస్తే, Ollama ను loopback పై ఉంచి దాని ముందు proxy ను అమర్చండి. Proxy TLS (transport layer security) termination చేసి, సరైన header లేని requests ను తిరస్కరిస్తుంది. 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;
    }
}

అక్కడి ఐదు lines వాస్తవమైన పని చేస్తాయి. మీరు ఎదుర్కొనే ప్రతి failure ను వాటిలో ఒక్కో line నివారిస్తుంది.

nginx లోని if ను location block లో ఉపయోగించడం సాధారణంగా సరైనది కాదు. అయితే ఖచ్చితంగా return ఉన్న body, ముందుగా ఊహించగలిగే విధంగా పనిచేసే రెండు రూపాల్లో ఒకటి. అందువల్ల ఇక్కడ ఈ ఉపయోగం సురక్షితం.

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 incoming Host మరియు Origin headers ను పరిశీలిస్తుంది. Proxy యొక్క public hostname ను నేరుగా pass through చేస్తే, nginx నుంచి కాకుండా Ollama నుంచి వచ్చిన 403 Forbidden ఏర్పడవచ్చు. దీన్ని debug చేయడం గందరగోళంగా ఉంటుంది. నిర్దిష్ట origin కు అనుమతి అవసరమైన browser client కోసం OLLAMA_ORIGINS మరో నియంత్రణ.

proxy_buffering off; ముఖ్యమైనది, ఎందుకంటే Ollama తన response ను token చొప్పున stream చేస్తుంది. Buffering on లో ఉంటే nginx ఆ stream ను నిలిపి, generation పూర్తయిన తర్వాత ఒకేసారి పంపుతుంది. అప్పుడు మొత్తం generation సమయంలో మీ client నిలిచిపోయినట్లు కనిపిస్తుంది.

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 చేసి test చేయండి:

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 చేయాలి. రెండవది మీ model list ను print చేయాలి. మొదటిదీ model list ను తిరిగి ఇస్తే, map block తప్పు scope లో ఉంది. అది http level లో ఉండాలి. కాబట్టి దాన్ని /etc/nginx/conf.d/ కింద ఉన్న file లో లేదా server block పైన ఉంచండి. server లో మాత్రం ఎప్పుడూ ఉంచవద్దు.

Caddy ఇదే పనిని basic authentication తో నాలుగు lines లో చేస్తుంది. 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 ను run చేయండి. Naming విషయంలో ఒక జాగ్రత్త: Caddy v2.8 కు ముందు directive basicauth. ఇప్పుడు అది basic_auth. అందువల్ల పాత guide నుంచి copy చేసిన config load కావడం విఫలమవుతుంది. Caddy గుర్తించలేని directive పేరును చూపిస్తుంది.

మీరు ఏ proxy ఎంచుకున్నా, అందరికీ ఇది ఒకే shared secret. దీన్ని కలిగి ఉన్న ప్రతి client కు ఒకే విధమైన access ఉంటుంది. దాన్ని revoke చేయాలంటే config ను edit చేసి, ప్రతి caller ను ఒకేసారి update చేయాలి.

రక్షణ 3: ప్రతి client కోసం keyలను జారీ చేసే gateway

ఒకరి కంటే ఎక్కువ మంది లేదా అప్లికేషన్లు modelను ఉపయోగించినప్పుడు shared token పరిమితికి చేరుకుంటుంది. Load కు ఏ client కారణమైందో గుర్తించడం సాధ్యం కాదు. అందరినీ నిలిపివేయకుండా వారిలో ఒక్కరిని మాత్రమే నిలిపివేయలేరు. 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 అవుతుంది. దానితో కమ్యూనికేట్ చేసే ఏకైక process gateway మాత్రమే. Public listener ఉన్న ఏకైక service కూడా gateway మాత్రమే. Port 11434 ఇప్పటికీ ప్రపంచానికి తెరిచి ఉన్న serverలో gatewayను ఉంచడం వల్ల ప్రయోజనం లేదు. Callers gatewayను సులభంగా దాటవేయగలరు.

ఫైర్‌వాల్‌లోని సమస్య: publish చేసిన container port UFW ను దాటిపోతుంది

ఫైర్‌వాల్‌ను సరిగ్గా configure చేసిన server‌లలో కూడా exposed 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 ను పరిశీలిస్తుంది. Routing decision జరిగే సమయానికి destination ఇప్పటికే container address‌కు మార్చబడుతుంది. అందువల్ల packet స్థానికంగా deliver కాకుండా forward అవుతుంది. అది INPUT కు బదులుగా FORWARD గుండా వెళుతుంది. UFW యొక్క INPUT rules ను అసలు పరిశీలించదు. కాబట్టి packet firewall గుండా కాకుండా దాని చుట్టూ వెళ్లిపోతుంది.

అందుకే ఈ sequence port 11434 ను internet‌కు తెరిచి ఉంచుతుంది:

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గా ఉందని చూపిస్తుంది. రెండు readings ఒకేసారి సరైనవే. అందుకే చాలామంది తప్పు reading‌ను నమ్ముతారు. దీనికి కారణమైన 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 side loopback‌కు bind అవుతుంది. అందువల్ల మీ SSH tunnel మరియు reverse proxy దాన్ని చేరుకోగలవు, కానీ internet చేరుకోలేదు. Models named ollama volume లో ఉంటాయి, container లో ఉండవు. కాబట్టి ఇక్కడ container ను మళ్లీ సృష్టించడం సురక్షితం.

రెండు 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 అయితే మీరు ఇంకా exposedగానే ఉన్నారు. ఈ mechanism‌ను ఒకసారి అర్థం చేసుకుంటే, మీరు publish చేసే ప్రతి container‌కు ఇది వర్తిస్తుంది: Docker published ports UFW ను ఎందుకు దాటిపోతాయి లో DOCKER-USER chain మరియు Docker restart అయిన తర్వాత కూడా నిలిచే rules గురించి వివరించబడింది. Host policyనే ఇంకా రూపొందిస్తుంటే, కొత్త VPS కు అవసరమైన UFW rules ఈ ఆధార policy గురించి వివరిస్తుంది. Rocky లేదా AlmaLinuxలో configure చేయడానికి UFW ఉండదు. అందువల్ల firewalld లో రాసిన అదే ఆధార policy తో ప్రారంభించాలి.

ప్రాసెస్ ఏ ఖాతాగా నడుస్తోంది

Linux install script ప్రత్యేకమైన account ను సృష్టించి, దాని కింద service ను నడుపుతుంది:

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

/etc/systemd/system/ollama.service వద్ద ఉన్న unit తరువాత User=ollama మరియు Group=ollama ను సెట్ చేస్తుంది. దాన్ని మార్చవద్దు. Terminalలో చేతితో ప్రారంభించిన త్వరిత ollama serve, మీరు login చేసిన account గా నడుస్తుంది. అది root అయితే, authentication లేని API files ను root గా రాస్తుంది. ఏది జరుగుతుందో పరిశీలించండి:

ps -o user= -C ollama

సమాధానం ollama అయి ఉండాలి. మరేదైనా ఉంటే, unit కు అదనంగా లేదా దాని బదులుగా చేతితో ప్రారంభించిన process నడుస్తోందని అర్థం. తరువాత మీరు జోడించే ప్రతి daemon కు ఇదే విధానం వర్తిస్తుంది. కనీస అనుమతులు ఉన్న users గా services ను నడపడం ఈ అంశాన్ని సరిగ్గా అమలు చేస్తుంది.

Ollama API endpoint సురక్షితంగా ఉందో ఎలా తనిఖీ చేయాలి

మీరు ఏ విధానాన్ని ఎంచుకున్నా, ఒక పరీక్షతో విషయం స్పష్టమవుతుంది. ఆ పరీక్షను తప్పనిసరిగా మరో machine నుంచి అమలు చేయాలి:

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 ను ఒకసారి చదవాలి. 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 ఒక్కసారి కనిపించాలి. Connection రావడానికి అదే ఏకైక address అవుతుంది. ఆ column లో public address కనిపిస్తే, అది బయట నుంచి వచ్చిన request అని అర్థం. Timestamp ద్వారా అది ఎప్పుడు వచ్చిందో తెలుస్తుంది. ఆ command నుంచి ఎలాంటి output రాకపోవడమే మీకు కావాల్సిన ఫలితం. Model భాగం మీకు కొత్తగా ఉంటే, 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 జత మీ machine ను ollama.com కు ధృవీకరిస్తుంది. దాంతో మీరు models ను push చేయవచ్చు, private models ను pull చేయవచ్చు. OLLAMA_API_KEY అనేది https://ollama.com/api వద్ద ఉన్న hosted API కు మీ client పంపే credential. మీ స్వంత ollama serve వీటిలో ఏదీ చదవదు. అందువల్ల access control network నుంచి లేదా ముందు ఉంచిన proxy నుంచి రావాలి.

Firewall ఉంటే OLLAMA_HOST=0.0.0.0 సురక్షితమేనా?

ఆ box లో మరే ఇతర విషయం 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 లోని పొరపాటు ద్వారా బయటపడే listener మిగలదు.

నా Ollama port internet కు open గా ఉందో ఎలా తనిఖీ చేయాలి?

Server పై sudo ss -tlnp | grep 11434 ను run చేయండి. వేరే machine నుంచి curl -m 5 http://YOUR_SERVER_IP:11434/api/version ను run చేయండి. ss 127.0.0.1:11434 చూపిస్తూ, remote curl timeout అవడం మీకు కావాల్సిన రెండు ఫలితాలు. ss 0.0.0.0:11434 లేదా *:11434 చూపిస్తూ, remote curl JSON ను తిరిగి ఇస్తే పూర్తి API చేరుకోగలుగుతున్నారు. Server పైనే curl తో ఎప్పుడూ test చేయవద్దు. Bind address ఏదైనా loopback దానికి సమాధానం ఇస్తుంది.

Port ను 11434 నుంచి ఏదైనా random port కు మార్చవచ్చా?

లేదు. కారణాన్ని స్పష్టంగా చెప్పాలి. వేరే port కు మార్చడం ద్వారా ఒకే port ను scan చేసే ప్రయత్నం మాత్రమే నెమ్మదిస్తుంది. Scanners మొత్తం range ను పరిశీలిస్తాయి. /api/tags కు చేసే ఒక request, అది ఏ port కు వచ్చినా service ను గుర్తిస్తుంది. Port మార్చడం వల్ల ప్రతి client యొక్క default కూడా పనిచేయదు. తరువాత మీ స్వంత setup ను అర్థం చేసుకోవడం కూడా కష్టమవుతుంది. బదులుగా loopback కు bind చేయండి. అప్పుడు listener ను వేరే చోటుకు మార్చడం కాదు, public interface నుంచి తొలగించడం జరుగుతుంది.

ఎవరో నా open Ollama ను చేరుకున్నారు. నేను ఏమి తనిఖీ చేయాలి?

ముందుగా దాన్ని 127.0.0.1 కు bind చేసి service ను restart చేయండి. దాంతో మీరు దర్యాప్తు ప్రారంభించే ముందే exposure ఆగుతుంది. తరువాత ఏ బయటి addresses ఎప్పుడు ఏ endpoints ను పిలిచాయో చూడటానికి journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 ను run చేయండి. ollama list ను మీరు ఉంచాలని ఉద్దేశించిన models తో పోల్చండి. /api/pull కు authentication లేదు. మీరు pull చేయని model disk usage ను కూడా సూచిస్తుంది, ఒక ఆధారంగా కూడా పనిచేస్తుంది. df -h తో ఖాళీ స్థలాన్ని తనిఖీ చేయండి. Default log level వద్ద Ollama prompt text ను record చేయదు. అందువల్ల ఎవరు ఏ model కోసం request చేశారో తెలుస్తుంది. ఏ text generate అయిందో మాత్రం తెలియదు.

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