SSD Nodes Learn 🎉 VPS $5.50/నెల నుండి
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-16

Ollama APIకి password లేదు: port 11434ను ఎలా రక్షించాలి

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ని access చేస్తున్నప్పుడు authentication అవసరం లేదు." భద్రతా నమూనా మొత్తం locally అనే పదంపైనే ఆధారపడి ఉంటుంది. 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"}'

Operator దృష్టిలో, నాలుగు సమస్యలు ఎదురవుతాయి:

  • మీ CPU లేదా GPU మరొకరి కోసం inference నడుపుతుంది. Fair-use CPU allowance ఉన్న planలో నిరంతర load అంటే, మీ allowance ను ఒక అపరిచితుడు వినియోగిస్తున్నాడని అర్థం. మీరు మాత్రమే caller కాకపోతే, VPSలో AI workload ఖర్చులను నియంత్రించడం చాలా కష్టమవుతుంది.
  • /api/pull మీ diskలోకి రాస్తుంది. ఒక్కో model పరిమాణం రెండు నుంచి నలభై gigabytes వరకు ఉంటుంది. Pullల loop volumeను నింపుతుంది. Disk నిండిపోతే Ollama మాత్రమే కాకుండా ఆ serverలోని ప్రతి ఇతర service కూడా పనిచేయడం ఆగిపోవచ్చు.
  • Requests మీ processలోకి వచ్చి log అవుతాయి. Default log levelలో Ollama metadataను మాత్రమే record చేస్తుంది. అందువల్ల endpoint, status, latency, client address కనిపిస్తాయి; prompt text కనిపించదు. అయినప్పటికీ, మీ boxను ఎవరు, ఏ పని కోసం ఉపయోగించారనే record మీ journalలో నిల్వ ఉంటుంది. ఆ recordను సేకరించాలని మీరు ఎంచుకోలేదు.
  • /api/delete modelsను తొలగిస్తుంది. వాటిని తిరిగి పొందాలంటే మీ స్వంత bandwidthను ఉపయోగించి మళ్లీ download చేయాలి.

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

Ed25519 key అనేది 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 నుంచి ఇది ఏ credential ను అడగదు. దీన్ని తొలగించడం, 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 దీన్ని ఎప్పుడూ చదవదు. మీ VPS పై OLLAMA_API_KEY ను set చేయడం వల్ల మీ VPS కు password అమలు కాదు.

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

ఇప్పుడు మీ server ఏ వాటిపై 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 అంటే ఆ machine లోని అన్ని IPv4 addresses, public address కూడా కలిపి. 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 రెండు మార్గాల్లో ఒకదాని ద్వారా ఏర్పడుతుంది. మొదటిది ఉద్దేశపూర్వకంగా చేసిన మార్పు. ఎవరికైనా model ను రెండో machine నుంచి చేరుకోవాల్సి వచ్చినప్పుడు ఈ మార్పు చేస్తారు:

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

Exposure కు కారణం ఆ ఒక్క line చాలు. రెండో మార్గం 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 యొక్క 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 కు పంపుతుంది. SSH remote command ను అమలు చేయకూడదని -N సూచిస్తుంది. అందువల్ల process tunnel ను తెరిచి ఉంచుతుంది. ఇది నడుస్తున్నప్పుడు, మీ laptop పై కింది command పనిచేస్తుంది:

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 అయినప్పటికీ empty 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 లోని పొరపాటును కూడా తట్టుకుంటుంది. ఎందుకంటే ఒక rule అనుకోకుండా ప్రపంచానికి access ఇచ్చినా, public interface పై listener లేకపోతే దాన్ని బయటకు expose చేయలేరు.

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

Public internetలో ఉన్న ఏదైనా client modelను పిలవాల్సి వస్తే, Ollamaను loopbackపై మాత్రమే ఉంచి దాని ముందు proxyను అమర్చండి. Proxy TLS (transport layer security) ను terminate చేసి, సరైన header లేని అభ్యర్థనలను తిరస్కరిస్తుంది. Ollama ఇప్పటికీ 127.0.0.1 నుంచే connections ను స్వీకరిస్తుంది. కాబట్టి లోపలికి వచ్చే ఏకైక మార్గం proxy మాత్రమే.

ముందుగా నిజమైన tokenను రూపొందించండి. దాన్ని చేతితో ఊహించి రాయవద్దు:

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;
    }
}

ఇక్కడి ఐదు పంక్తులు నిజమైన పని చేస్తాయి. వాటిలో ప్రతి ఒక్కటి లేకపోతే ఎదురయ్యే ఒక failureను నివారిస్తుంది.

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

location = /api/pull exact match. nginx, location / prefix కంటే exact matchలకు ఎక్కువ ప్రాధాన్యం ఇస్తుంది. అందువల్ల tokenను పరిశీలించకముందే ఆ మూడు endpoints తిరస్కరించబడతాయి. చెల్లుబాటు అయ్యే token inferenceకు మాత్రమే అనుమతి ఇస్తుంది. మీ diskను నింపే సామర్థ్యాన్ని ఇవ్వదు.

proxy_set_header Host 127.0.0.1:11434; అవసరం. Ollama incoming Host మరియు Origin headersను పరిశీలిస్తుంది. Proxy యొక్క public hostnameను నేరుగా పంపితే, nginx నుంచి కాకుండా Ollama నుంచి వచ్చిన 403 Forbidden ఏర్పడవచ్చు. దీన్ని debug చేయడం గందరగోళంగా ఉంటుంది. నిర్దిష్ట originకు అనుమతి అవసరమయ్యే browser client కోసం OLLAMA_ORIGINS మరో నియంత్రణ.

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

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 చేసి పరీక్షించండి:

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 ను ముద్రించాలి. రెండవది మీ model listను ముద్రించాలి. మొదటిదీ model listనే తిరిగి ఇస్తే, map block తప్పు scopeలో ఉంది. అది http స్థాయిలో ఉండాలి. అందువల్ల దాన్ని /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 ను అమలు చేయండి. ఒక naming trap ఉంది: Caddy v2.8కు ముందు directive basicauth. ఇప్పుడు అది basic_auth. అందువల్ల పాత guide నుంచి copy చేసిన config load కాదు. గుర్తించని directive పేరును Caddy చూపిస్తుంది.

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

రక్షణ 3: ప్రతి క్లయెంట్‌కు key జారీ చేసే gateway

ఒకరి కంటే ఎక్కువ మంది లేదా అప్లికేషన్లు model ను ఉపయోగించినప్పుడు, shared token సరిపోదు. Load కు కారణమైన క్లయెంట్ ఏదో గుర్తించలేరు. వారిలో ఒకరిని నిలిపివేయాలంటే అందరినీ నిలిపివేయాల్సి వస్తుంది. Proxy ఉన్న స్థానంలో gateway పనిచేస్తుంది. ఇది అదే OpenAI-compatible API తో కమ్యూనికేట్ చేస్తుంది, ప్రతి క్లయెంట్‌కు ప్రత్యేక 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 ని దాటిపోయి Ollama ను ఉపయోగించగలరు.

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

సర్వర్ యజమానులు firewall ను సరిగ్గా configure చేసినప్పటికీ, exposed instances ఎందుకు కనిపిస్తాయో దీనివల్ల అర్థమవుతుంది.

UFW (uncomplicated firewall) తన rules ను kernel యొక్క filter table లోని INPUT chain లోకి రాస్తుంది. Host కే ఉద్దేశించిన packets ను INPUT నిర్వహిస్తుంది. Docker యొక్క -p flag, nat table లోని PREROUTING chain లో destination NAT (network address translation) rule ను రాస్తుంది. Packet ఎక్కడికి వెళ్లాలో kernel నిర్ణయించే ముందు ఈ rule ను పరిశీలిస్తుంది. Routing decision జరిగే సమయానికి destination ఇప్పటికే container address గా మార్చబడుతుంది. అందువల్ల packet స్థానికంగా deliver కాకుండా forward అవుతుంది. అది INPUT బదులుగా FORWARD గుండా వెళ్తుంది. UFW యొక్క INPUT rules ను అసలు పరిశీలించరు. కాబట్టి packet firewall గుండా వెళ్లకుండా దాన్ని దాటిపోతుంది.

అందువల్ల ఈ sequence port 11434 ను internet కు open గా ఉంచుతుంది:

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

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

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 ను సెట్ చేస్తుంది. దాన్ని మార్చవద్దు. టెర్మినల్‌లో చేతితో ప్రారంభించిన సత్వర ollama serve, మీరు login చేసిన account గా నడుస్తుంది. అది root అయితే, authentication లేని API ఫైళ్లను root గా రాస్తుంది. ఏది జరుగుతుందో పరిశీలించండి:

ps -o user= -C ollama

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

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 తెరిచి ఉన్న సమయంలో ఎవరైనా దాన్ని కనుగొన్నారా అన్నది log చూపిస్తుంది:

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 రాకపోవడమే మీకు కావాల్సిన ఫలితం. Ollama గురించి ఈ భాగం మీకు కొత్త అయితే, VPSపై Ollama నడపడం install, model sizing మరియు ఏది వాస్తవంగా load అవుతుందో నిర్ణయించే memory limits గురించి వివరిస్తుంది.

FAQ

Ollama కు API key లేదా password ఉందా?

లేదు. మీరు నడుపుతున్న server కు ఎలాంటి authentication ఉండదు. API ను చేరుకోవడానికి authentication అవసరం లేదని official 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 అంటే public interface పై listener వాస్తవంగా అందుబాటులో ఉందని అర్థం. దాన్ని చేరుకోకుండా ఉంచడానికి మీరు firewall పైనే ఆధారపడుతున్నారు. Docker ఒక port ను publish చేసిన వెంటనే ఆ నమ్మకం విఫలమవుతుంది. ఎందుకంటే Docker జోడించే DNAT rule nat table లో, packet INPUT chain కు చేరుకునే ముందు పరిశీలించబడుతుంది. అక్కడే UFW పనిచేస్తుంది. అందువల్ల packet forward అవుతుంది, UFW దాన్ని చూడదు. 127.0.0.1 కు లేదా private tunnel address కు bind చేస్తే listener public interface నుంచి తొలగిపోతుంది. అప్పుడు firewall లోని పొరపాటుకు expose చేయడానికి ఏ 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 ఆ service ఏ port ద్వారా అందుకున్నా దాన్ని గుర్తిస్తుంది. Port మార్చడం వల్ల ప్రతి client యొక్క default కూడా పనిచేయదు. తరువాత మీ స్వంత setup ను అర్థం చేసుకోవడం కష్టమవుతుంది. Listener ను వేరే చోటుకు మార్చడం కాకుండా loopback కు bind చేయండి. అప్పుడు listener తొలగిపోతుంది.

ఎవరో నా 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 చేశారో తెలుస్తుంది, కానీ ఏది generate అయిందో తెలియదు.

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