Ollama-API-Schlüssel: Ihr lokales Ollama hat keinen. So verlangen Sie einen

Von MV2 von Munim, Inc. Geprüft am 12. Oktober 2026 anhand der Ollama-Dokumentation zur Authentifizierung, der Ollama-FAQ, der n8n-Dokumentation zu Ollama-Zugangsdaten, der API-Dokumentation von Open WebUI und der Caddy-Dokumentation zu Matchern. Nur für Ihre eigenen Rechner. Diese Seite wurde mit KI aus dem englischen Original übersetzt; bei Abweichungen gilt das Original.

Die kurze Antwort

Wird Ollama nur auf dem Rechner genutzt, auf dem es läuft, brauchen Sie nichts davon. Lassen Sie es auf 127.0.0.1; die Checkliste zum Absichern zeigt, wie Sie das prüfen.

Variante A: Open WebUI läuft schon? Nutzen Sie es als Zugang

Open WebUI reicht Anfragen unter /ollama/ an Ollama weiter und prüft dabei seine eigenen API-Schlüssel. Ollama bleibt intern, und Sie brauchen keine zusätzliche Software.

  1. Legen Sie in Open WebUI unter Settings > Account einen Schlüssel an (in der deutschen Oberfläche „Einstellungen“ und „Konto“; Schlüssel beginnen mit sk-). Sehen Sie die Option nicht, muss ein Admin API-Schlüssel erst erlauben; siehe die Dokumentation von Open WebUI zu API-Schlüsseln.
  2. Rufen Sie die native API von Ollama über Open WebUI auf: 
    curl https://webui.example.home/ollama/api/tags -H "Authorization: Bearer sk-..."
    oder nutzen Sie den OpenAI-kompatiblen Endpunkt von Open WebUI, /api/chat/completions.
  3. Setzen Sie in n8n die Base URL der Ollama-Zugangsdaten auf https://webui.example.home/ollama und den API Key auf den sk--Schlüssel. Die n8n-Dokumentation nennt Open WebUI als Beispiel für genau diesen Aufbau.

Der Schlüssel trägt die Rechte des jeweiligen Open-WebUI-Benutzers. Legen Sie deshalb für jede App einen eigenen Benutzer an und halten Sie Open WebUI aktuell (siehe Sicherheitshinweise zu Open WebUI (Englisch)).

Variante B: ein kleiner Proxy, der einen Schlüssel prüft

1. Ollama lokal lassen und einen Schlüssel erzeugen

Ollama muss auf 127.0.0.1:11434 lauschen (der Standard). Haben Sie früher OLLAMA_HOST=0.0.0.0 gesetzt, machen Sie das wie in Schritt 2 der Checkliste rückgängig. Sonst können andere den Proxy umgehen, indem sie direkt Port 11434 ansprechen. Erzeugen Sie dann einen langen Zufallsschlüssel:

openssl rand -hex 32
# or
python3 -c "import secrets; print(secrets.token_urlsafe(32))"

(Einer der beiden Befehle genügt.)

2a. Caddy

Caddy besorgt sich selbst ein HTTPS-Zertifikat, wenn ollama.example.com eine echte Domain ist, die auf diesen Rechner zeigt. Ersetzen Sie die Domain und PASTE_YOUR_KEY_HERE (durch Ihren Schlüssel):

ollama.example.com {
    @key header Authorization "Bearer PASTE_YOUR_KEY_HERE"
    handle @key {
        reverse_proxy 127.0.0.1:11434 {
            header_up Host localhost:11434
            header_up -Authorization
        }
    }
    handle {
        respond "Missing or wrong API key" 401
    }
}

Name nur im LAN (etwa ollama.home): Es gibt kein öffentliches Zertifikat. Nutzen Sie daher tls internal im Site-Block und installieren Sie das Root-Zertifikat von Caddy auf Ihren Clients. Oder verzichten Sie auf den Proxy und nutzen ein privates Netz wie Tailscale oder WireGuard (siehe Ollama aus der Ferne nutzen). Senden Sie den Schlüssel nicht über unverschlüsseltes http:// in einem Netz, dem Sie nicht vertrauen; jeder in diesem Netz könnte ihn mitlesen.

2b. nginx

Legen Sie Folgendes in /etc/nginx/conf.d/ollama.conf ab. Dateien in conf.d werden innerhalb des http-Blocks gelesen, wo map hingehört. Verwenden Sie Ihre eigenen Zertifikatspfade, zum Beispiel von certbot:

map $http_authorization $ollama_key_ok {
    default                        0;
    "Bearer PASTE_YOUR_KEY_HERE"   1;
}

server {
    listen 443 ssl;
    server_name ollama.example.com;
    ssl_certificate     /etc/letsencrypt/live/ollama.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.example.com/privkey.pem;

    location / {
        if ($ollama_key_ok = 0) { return 401; }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
        proxy_set_header Authorization "";   # don't pass the key on to Ollama
        proxy_buffering off;                 # stream tokens as they come
        proxy_read_timeout 600s;             # long generations
        client_max_body_size 0;              # model uploads (ollama create)
    }
}

(Die Kommentare bedeuten der Reihe nach: den Schlüssel nicht an Ollama weitergeben; Tokens sofort streamen; lange Generierungen zulassen; Modell-Uploads mit ollama create erlauben.) Fügen Sie für jeden weiteren Schlüssel eine Zeile in die map ein. Führen Sie dann sudo nginx -t && sudo systemctl reload nginx aus und machen Sie die Datei nur für root lesbar (sudo chmod 600 /etc/nginx/conf.d/ollama.conf; nginx liest sie beim Start als root).

2c. Ollama in Docker

Geben Sie dem Dienst ollama überhaupt kein ports: und veröffentlichen Sie nur Caddy. Verwenden Sie im Caddyfile oben reverse_proxy ollama:11434. Ergänzen Sie beim Dienst ollama Ihre üblichen GPU-Einstellungen.

services:
  ollama:
    image: ollama/ollama
    volumes: [ "ollama:/root/.ollama" ]
    # no "ports:" - only containers on this network can reach it
  caddy:
    image: caddy:2
    ports: [ "80:80", "443:443" ]
    volumes: [ "./Caddyfile:/etc/caddy/Caddyfile:ro", "caddy_data:/data" ]
volumes:
  ollama: {}
  caddy_data: {}

(Der Kommentar bedeutet: kein „ports:“, nur Container in diesem Netz erreichen Ollama.)

3. Testen

# no key: should print 401
curl -s -o /dev/null -w "%{http_code}\n" https://ollama.example.com/api/version

# with the key: should print {"version":"..."}
curl -H "Authorization: Bearer YOUR_KEY" https://ollama.example.com/api/version

# from ANOTHER machine, straight to Ollama: should fail to connect
curl http://<server LAN IP>:11434/api/version

(Erwartet wird: ohne Schlüssel 401; mit Schlüssel eine Versionsangabe; und von einem ANDEREN Rechner direkt an Ollama soll die Verbindung scheitern. YOUR_KEY ist Ihr Schlüssel, <server LAN IP> die LAN-IP des Servers.) Antwortet der letzte Befehl mit einer Version, lässt sich der Proxy umgehen. Prüfen Sie OLLAMA_HOST und die Docker-ports: noch einmal. Unter Linux blockiert ufw keine Ports, die Docker veröffentlicht.

Ihre Apps verbinden

Fehler, die Sie vermeiden sollten

Lieber prüfen lassen?

MV2 von Munim, Inc. bietet einen lokalen KI-Gesundheitscheck für 49 US-Dollar für einen Rechner an, oder einen Check für kleine Büros für 199 US-Dollar für bis zu 5 Rechner oder einen gemeinsam genutzten Ollama- oder Open-WebUI-Server. Sie erhalten einen schriftlichen Bericht darüber, was offen, riskant oder langsam ist und was Sie zuerst beheben sollten, mit genauen Befehlen für Ihr Betriebssystem. Der Bericht ist auf Englisch. Beispielbericht ansehen (Englisch). 49 $ zahlen oder 199 $ zahlen über Stripe, und senden Sie dann an munimversion2@gmail.com die Ausgabe von python3 local_ai_checkup.py --json aus dem kostenlosen Skript local-ai-checkup, Ihr Betriebssystem und wofür Sie es nutzen. MV2 fragt nie nach Passwörtern, Schlüsseln oder Fernzugriff, also senden Sie Ihren API-Schlüssel nicht mit.