ThisCalculator

Everyday

Ollama Port Authentication: Lock Down Network Access

Updated · Standard formula, shown below

Ollama Port Authentication: Lock Down Network Access

Ollama’s default HTTP server on port 11434 has no built-in authentication, so anyone who can reach that port on your network can list models, pull new ones, and run prompts. You can add an authentication gate in front of it using a reverse proxy (like Nginx or Caddy) or by binding Ollama to localhost and tunneling through an authenticated SSH session. This article explains why the port is open, how to protect it, and what to watch out for.

Background: Why Ollama Exposes a Port

Ollama runs a local REST API server that listens on 127.0.0.1:11434 by default. The server is designed for single-user, local use: you call it from a terminal, a script, or a web UI on the same machine. There is no user database, no login prompt, and no per-request authorization. The API is intentionally simple—POST /api/generate sends a prompt and gets a response, GET /api/tags lists installed models, and POST /api/pull downloads a new model.

When you change the environment variable OLLAMA_HOST to 0.0.0.0 (or a specific LAN IP), the server starts listening on all network interfaces. That makes the API reachable from other devices on your local network—and, if your router forwards port 11434, from the internet. Because the API has no authentication, anyone who can connect can use your GPU, access your model files, and potentially read sensitive data you send in prompts.

How Authentication Is (and Isn’t) Handled

Ollama itself does not support API keys, tokens, or basic auth. The official documentation recommends putting a reverse proxy in front of the server if you need access control. A reverse proxy is a small program that sits between clients and Ollama: it accepts the client’s request, checks credentials, and then forwards the request to Ollama on localhost.

Common choices are Nginx, Apache, Caddy, and Traefik. All of them can require HTTP Basic Auth (username and password), client certificates, or an OAuth2 provider. The proxy runs on the same machine as Ollama (or on a separate host), listens on the public port, and forwards to 127.0.0.1:11434.

An alternative that avoids a proxy entirely is to keep Ollama bound to localhost and use SSH port forwarding. From your laptop, you run ssh -L 11434:localhost:11434 user@server, which creates an encrypted tunnel. Your local localhost:11434 then reaches the server’s Ollama, and the SSH login itself is the authentication gate.

How to Set Up an Authentication Proxy (Nginx Example)

Here is a minimal Nginx configuration that puts HTTP Basic Auth in front of Ollama. This works on a Linux server where Ollama is running on the default port.

  1. Install Nginx: sudo apt install nginx (Debian/Ubuntu) or sudo dnf install nginx (Fedora).
  2. Create a password file: sudo sh -c 'echo "admin:$(openssl passwd -apr1 YourStrongPassword)" > /etc/nginx/.htpasswd'.
  3. Edit the Nginx site config (e.g., /etc/nginx/sites-available/ollama) with the following:
server {
    listen 11434;
    auth_basic "Ollama Access";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11435;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Note that Ollama must be listening on a different port than the proxy (here, 11435) or on localhost only. Set OLLAMA_HOST=127.0.0.1:11435 in the Ollama service environment. Then enable the site and reload Nginx.

Now any request to http://server:11434 will prompt for the username and password you set. Without valid credentials, the client gets a 401 response and the request never reaches Ollama.

Choosing the Right Method for Your Use Case

There is no one-size-fits-all answer; it depends on your threat model and how you access Ollama.

  • Single user, same machine: Keep the default localhost binding. No extra work, and nothing is exposed.
  • Single user, remote access from personal devices: SSH tunnel is simple and secure. You need an SSH server on the Ollama machine, and you must authenticate with a key or password.
  • Multiple users, trusted LAN: A reverse proxy with Basic Auth is easy to set up and works with any client that supports HTTP auth (most do).
  • Multiple users, internet exposure: Use a proxy with OAuth2 (e.g., Authelia or Keycloak) or a VPN. Basic Auth over plain HTTP is not secure; you must enable TLS (HTTPS) on the proxy.

If you are using a web UI like Open WebUI, it already has its own login system and can be configured to connect to Ollama via a localhost proxy, so you don’t need to expose Ollama directly.

Common Problems and Misconceptions

One frequent mistake is setting OLLAMA_HOST=0.0.0.0 and then forgetting about it. The change is persistent across restarts, and many users only realize the port is open when they see it in a port scan. Always check your listening ports with netstat -tulpn | grep 11434 or ss -tulpn.

Another misconception is that Ollama’s API has a “token� feature. It does not. Some tools (like Open WebUI) generate their own API keys, but those are for the tool, not for Ollama. If you see a tutorial that says “add an API key to Ollama,� it is either outdated or referring to a third-party wrapper.

Also, Basic Auth over plain HTTP sends the password in base64, which is easily decoded. If you use a proxy, always enable HTTPS (TLS) with a valid certificate (Let’s Encrypt works well). Without TLS, the authentication gate is only a minor deterrent.

Costs and Safety Considerations

Adding a reverse proxy has essentially zero monetary cost—Nginx and Caddy are free and open-source. The main cost is configuration time and ongoing maintenance (updating certificates, managing password files).

From a safety perspective, the biggest risk is not the authentication method but the data you send to the model. Even with a proxy, prompts and responses travel in plain text if you don’t use HTTPS. If you are sending proprietary code or personal information, use a VPN or TLS. Also, remember that Ollama stores model files and conversation logs on disk; anyone with shell access to the server can read them, regardless of the proxy.

Alternatives to a Reverse Proxy

If you don’t want to run a proxy, you have two practical alternatives:

  • SSH tunnel: As described above, this is the simplest for a single remote user. It requires no extra software on the server beyond an SSH daemon.
  • VPN: Connect to your home or office network via WireGuard or OpenVPN, then access Ollama’s localhost address. This is more robust for multiple users and also encrypts all traffic.
  • Firewall rules: You can restrict access to specific IP addresses with iptables or ufw. This is not authentication, but it limits who can reach the port. Combine with a proxy for best results.

None of these are mutually exclusive; a layered approach (firewall + proxy + TLS) is the most secure.

Frequently Asked Questions

Does Ollama have built-in authentication?
No. Ollama’s API server has no authentication whatsoever. Any client that can connect to the port can use all endpoints.

Can I use an API key with Ollama?
No. Ollama does not support API keys. If you need them, you must put a proxy in front that validates keys and forwards requests.

Is it safe to expose Ollama to the internet if I use a proxy?
It is safer, but not completely safe. The proxy adds authentication, but you must also use HTTPS and keep the server patched. Exposing any service to the internet increases risk; a VPN is generally more secure.

Why does Ollama listen on 0.0.0.0 after I set OLLAMA_HOST?
That is the intended behavior. 0.0.0.0 means “all interfaces.� To restrict to a specific IP, set OLLAMA_HOST=192.168.1.10:11434.

How do I check if my Ollama port is exposed?
Run ss -tulpn | grep 11434 on the server. If it shows 0.0.0.0:11434 or *:11434, it is listening on all interfaces. From another device, try curl http://server-ip:11434/api/tags—if you get a JSON response, it is reachable.

Can I use Caddy instead of Nginx?
Yes. Caddy has automatic HTTPS and a simpler configuration. A basic Caddyfile would be: ollama.example.com { reverse_proxy 127.0.0.1:11434 }, and you can add basic_auth directives.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.