Ollama rootless mit Podman auf einem VPS betreiben

Ollama in rootless Podman auf einem VPS ausführen

Damit Ollama in rootless Podman auf einem Server läuft, müssen fünf Voraussetzungen erfüllt sein, die bei einer Desktop-Anleitung entfallen können. Ein dedizierter Benutzer ohne privilegierte Rechte besitzt den Container. Für diesen Benutzer ist Lingering aktiviert, damit der Container nach dem Abmelden weiterläuft. Eine Quadlet-Datei übergibt den Container an systemd, damit er nach einem Reboot wieder startet. Das Modellverzeichnis trägt auf Distributionen mit aktivem SELinux ein entsprechendes SELinux-Label. Die API lauscht nur auf Loopback, und Sie greifen über einen SSH-Tunnel (Secure Shell) darauf zu.

Ollama ist ein Server für große Sprachmodelle (LLM). Es speichert die Modellgewichte auf der Festplatte, lädt sie in den Arbeitsspeicher und beantwortet HTTP-Anfragen auf Port 11434. Ollama bietet keine Anmeldung, keinen API-Schlüssel und keine Benutzerkonten. Daher ist das Netzwerk die einzige Zugriffskontrolle. Podman führt Container ohne Daemon und ohne root aus. Alles, was aus dem Container ausbricht, startet daher zunächst als normaler Benutzer ohne privilegierte Rechte. Wenn Sie zuerst den Laufzeitvergleich lesen möchten, lesen Sie wie sich Podman und Docker auf einem VPS unterscheiden. Wenn Sie Container vollständig vermeiden möchten, ist Ollama direkt auf einem VPS installieren der kürzere Weg.

SSD Nodes stellt Fedora in seinen Images bereit. Fedora liefert sowohl Podman als auch SELinux (Security-Enhanced Linux) standardmäßig aus. Jeder folgende Befehl läuft auf Distributionen mit Podman 5 oder neuer.

Warum die Laptop-Version auf einem Server angepasst werden muss

Fedora Magazine hat am 5 August 2026 eine verständliche Anleitung zu diesem Stack veröffentlicht: Ollama lokal mit Podman unter Fedora Linux ausführen von Yazan Monshed. Sie eignet sich gut für die erste Stunde mit den Tools. Sie richtet sich jedoch an einen Laptop. Vier ihrer Entscheidungen verhalten sich auf einem Rechner mit öffentlicher IP-Adresse anders.

• Der Container wird mit einem einfachen podman run -d gestartet. Ein manuell gestarteter Container wird nach einem Reboot nicht erneut gestartet, weil nie festgelegt wurde, dass er automatisch starten soll.
• Es wird das veränderliche Tag ollama/ollama verwendet. Auf einem Laptop bemerken Sie den Tag, an dem sich das Verhalten ändert. Auf einem Server ist das erste Anzeichen ein Script, das über Nacht nicht mehr funktioniert.
• Die Veröffentlichung erfolgt mit -p 11434:11434. Dadurch wird an jedes Interface gebunden. Hinter einem Heimrouter ist der Dienst aus dem Internet nicht erreichbar. Auf einem VPS ist er eine öffentliche Inference-API ohne Passwort.
• Der Dienst läuft unter Ihrem eigenen Login-Benutzer. Auf einem Server sollte das Konto, dem der Container gehört, keine anderen Ressourcen besitzen. Bei einem Ausbruch landet der Angreifer dadurch in einem leeren Home-Verzeichnis.

Nichts davon ist für den Rechner, für den die Anleitung geschrieben wurde, falsch. Jeder dieser Punkte ist lediglich eine Entscheidung, die Sie erneut prüfen sollten, wenn der Server von überall erreichbar ist und niemand davor sitzt.

Unprivilegierten Benutzer anlegen und subuid prüfen

Rootless Podman bildet die internen Benutzer-IDs (UIDs) des Containers auf einen Block nicht verwendeter IDs auf dem Host ab. Dieser Block ist in /etc/subuid und /etc/subgid definiert. Ohne ihn können Rootless-Container überhaupt nicht gestartet werden.

sudo dnf install -y podman        # or: sudo apt install -y podman
sudo useradd --create-home --shell /bin/bash --comment "Ollama container owner" ollama
sudo passwd --lock ollama
grep ollama /etc/subuid /etc/subgid

grep sollte zwei Zeilen ausgeben, eine aus jeder Datei. Jede Zeile muss einen Bereich mit 65536 IDs angeben:

/etc/subuid:ollama:100000:65536
/etc/subgid:ollama:100000:65536

Die Startnummer ist bei Ihnen möglicherweise eine andere. Das ist unproblematisch. Wenn grep keine Ausgabe liefert, wurde für useradd kein Bereich zugewiesen. Der erste podman-Befehl unter diesem Benutzer schlägt dann wie folgt fehl:

Error: cannot find UID/GID for user ollama: no subuid ranges found for user "ollama" in /etc/subuid

Weisen Sie einen Bereich zu, den kein anderer Benutzer verwendet. Teilen Sie Podman anschließend mit, dass seine alte Zuordnung veraltet ist:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ollama
sudo -iu ollama podman system migrate

Durch das Sperren des Passworts kann sich niemand direkt als ollama anmelden. Sie wechseln von Ihrem Administratorkonto mit sudo -iu ollama zu diesem Konto.

Lingering aktivieren, damit der Dienst nach der Abmeldung weiterläuft

Die systemd-Instanz eines Benutzers startet normalerweise bei der Anmeldung und wird bei der Abmeldung beendet. Dabei wird auch /run/user/<uid> entfernt. Jeder Rootless-Container dieses Benutzers wird im selben Moment beendet. Lingering hält die Benutzerinstanz ohne zugeordnete Sitzung aktiv.

sudo loginctl enable-linger ollama
loginctl show-user ollama --property=Linger

Die Ausgabe sollte Linger=yes enthalten. Aktivieren Sie Lingering, bevor Sie die Unit erstellen. Das von der Unit benötigte Verzeichnis /run/user/<uid> ist erst vorhanden, wenn Lingering aktiviert ist.

Es gibt noch einen weiteren Schritt, den viele nicht erwarten. sudo -iu ollama stellt zwar eine Shell bereit, aber keinen Session-Bus. Deshalb schlägt systemctl --user sofort fehl:

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

systemd sucht den Benutzerbus unter $XDG_RUNTIME_DIR/bus. sudo -i setzt diese Variable nicht. Setzen Sie sie daher in jeder Administrations-Shell, in der Sie diesen Dienst verwalten, manuell:

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user status

Wo die Modelldateien gespeichert werden und wie viel Speicherplatz einzuplanen ist

Ollama schreibt die Gewichte innerhalb des Containers nach /root/.ollama/models. Binden Sie ein Verzeichnis aus dem Home-Verzeichnis des Benutzers in diesen Pfad ein. Dann landen die Dateien an einem messbaren Speicherort: /home/ollama/ollama-data/models. Die Blobs liegen unter models/blobs als inhaltsadressierte Dateien. models/manifests enthält den kleinen Index, der diese Dateien benennt. Wenn Sie stattdessen ein benanntes Volume verwenden, wie im Beitrag des Fedora Magazine, liegt derselbe Verzeichnisbaum unter /home/ollama/.local/share/containers/storage/volumes/<volume>/_data.

Planen Sie den Speicherplatz, bevor Sie etwas herunterladen. Die veröffentlichten Downloadgrößen bilden die Untergrenze.

[
  {
    "label": "gemma3:4b",
    "download_gb": 3.3
  },
  {
    "label": "mistral:7b",
    "download_gb": 4.4
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2
  },
  {
    "label": "gemma3:12b",
    "download_gb": 8.1
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3
  },
  {
    "label": "gemma3:27b",
    "download_gb": 17
  },
  {
    "label": "qwen3:30b",
    "download_gb": 19
  }
]

Alle 7 Zeilen enthalten Zahlen, die auf ollama.com/library veröffentlicht wurden. Es handelt sich nicht um auf einem Datenträger gemessene Größen. Der kleinste Tag hier, gemma3:4b, benötigt beim Download 3.3 GB. Der größte, qwen3:30b, benötigt beim Download 19 GB. Das Container-Image belegt zusätzlich Speicher in Podmans eigenem Speicherbereich. Prüfen Sie daher beide Werte zusammen mit podman system df und df -h /home. Ein Modell benötigt während des Ladens außerdem ungefähr so viel RAM wie seine Dateigröße, zuzüglich Speicher für das Kontextfenster. Ein Modell mit 19 GB läuft daher nicht auf einem VPS mit 16 GB RAM.

Image-Tag festlegen und den vollständigen Registry-Namen verwenden

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
mkdir -p ~/ollama-data ~/.config/containers/systemd
podman pull docker.io/ollama/ollama:0.32.9

Verwenden Sie ein veröffentlichtes Versionstag, 0.32.9 Stand August 2026, und nicht latest. Ein festgelegtes Tag bedeutet, dass ein Neustart um 04:00 dieselbe getestete Binärdatei verwendet. Jede Verhaltensänderung geht damit auf eine von Ihnen vorgenommene Änderung zurück. Docker Hub veröffentlicht für dieselben Versionen außerdem die Tags -rc und -rocm. Verwenden Sie das einfache Tag, sofern Sie keine AMD-GPU haben.

Geben Sie auch den Registry-Host an. Unter Fedora kann ein Kurzname in einer systemd-Unit keine Eingabeaufforderung anzeigen, weil kein Terminal verfügbar ist. Die Unit schlägt dann mit folgendem Fehler fehl:

Error: short-name "ollama/ollama" did not resolve to an alias and no unqualified-search registries are defined

Das Image zunächst manuell zu beziehen, ist optional, aber sinnvoll. Dadurch wird der mehrere Gigabyte große Download aus dem Start-Timeout der Unit herausgehalten.

Die Quadlet-Unit, die einen Reboot übersteht

Quadlet ist der systemd-Generator von Podman. Sie erstellen eine .container-Datei, systemd wandelt sie beim Booten in einen Dienst um, und podman generate systemd ist nicht mehr erforderlich. Speichern Sie diese Datei als /home/ollama/.config/containers/systemd/ollama.container. Sie muss dem Benutzer ollama gehören.

[Unit]
Description=Ollama API (rootless)
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/ollama/ollama:0.32.9
ContainerName=ollama
PublishPort=127.0.0.1:11434:11434
Volume=/home/ollama/ollama-data:/root/.ollama:Z
Environment=OLLAMA_KEEP_ALIVE=30m
Environment=OLLAMA_MAX_LOADED_MODELS=1

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

Der Dateiname legt den Namen des Dienstes fest. Daher wird ollama.container zu ollama.service.

systemctl --user daemon-reload
systemctl --user start ollama.service
systemctl --user status ollama.service

status sollte active (running) anzeigen. Führen Sie systemctl --user enable ollama.service nicht aus. Die Unit ist nicht als Datei auf der Festplatte vorhanden. Daher lehnt systemd den Befehl ab:

Failed to enable unit: Unit file /run/user/1001/systemd/generator/ollama.service is transient or generated.

Der Abschnitt [Install] übernimmt diese Aufgabe bereits. Quadlet erstellt den Link für den Start beim Booten während daemon-reload selbst. Deshalb ist dieser Befehl erforderlich. TimeoutStartSec=900 deckt einen ersten Start ab, bei dem das Image noch heruntergeladen werden muss. Die standardmäßigen 90 Sekunden reichen für einen Download von zwei Gigabyte nicht aus. systemd beendet den Start dann mit einem Fehler. OLLAMA_KEEP_ALIVE=30m hält ein Modell zwischen Anfragen im Arbeitsspeicher, statt es nach fünf Minuten zu entladen. Die Vor- und Nachteile werden unter ein Ollama-Modell im Arbeitsspeicher behalten erläutert. Falls einige der hier verwendeten systemd-Begriffe neu für Sie sind, erklärt wie systemd-Dienste und Timer auf einem VPS funktionieren die Units selbst.

Warum das Modellverzeichnis unter SELinux mit „Permission denied“ abgelehnt wird

Auf Fedora, RHEL, Rocky und AlmaLinux ist SELinux standardmäßig aktiviert. Ein Containerprozess läuft in der container_t-Domäne, während ein Verzeichnis im Home-Verzeichnis eines Benutzers mit user_home_t gekennzeichnet ist. Die Richtlinie erlaubt diesen Zugriff nicht. Deshalb kann Ollama seine Modellstruktur nicht anlegen und der Container wird beendet. getenforce gibt auf diesen Systemen Enforcing aus, und die Ablehnung wird protokolliert:

sudo ausearch -m avc -ts recent

Sie sehen eine Zeile, in der die Domäne und das Ziel-Label genannt werden:

avc:  denied  { write } for  pid=1842 comm="ollama" name="models" dev="vda1" ino=131077 scontext=system_u:system_r:container_t:s0:c214,c827 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permlisted=0

Das :Z am Ende der Volume=-Zeile behebt das Problem. Es versieht das Host-Verzeichnis mit dem Label container_file_t und weist ihm eine private MCS-Kategorie (Multi-Category Security) zu, die nur dieser Container verwendet. Das kleingeschriebene :z verwendet stattdessen ein gemeinsam genutztes Label. Das ist erforderlich, wenn zwei Container dasselbe Verzeichnis lesen.

Beachten Sie bei :Z, dass der Befehl destruktiv und ohne Ausgabe arbeitet. Die Umkennzeichnung erfolgt rekursiv. Wenn Sie den Befehl auf /home/ollama anwenden, wird jede Datei in diesem Home-Verzeichnis umgekennzeichnet. Dadurch funktioniert der Zugriff dieses Benutzers auf SSH-Schlüssel nicht mehr. Übergeben Sie :Z daher immer ein eigenes Unterverzeichnis, das keine anderen Dateien enthält. Benannte Volumes benötigen den Befehl nicht, weil Podman sie beim Erstellen korrekt kennzeichnet. Weitere Informationen finden Sie unter SELinux-Grundlagen für einen Server. Ubuntu und Debian verwenden stattdessen AppArmor. Dort hat :Z keine Wirkung. Wenn der Befehl in der Unit verbleibt, ist das unproblematisch.

Port 11434 schließen und über SSH auf die API zugreifen

PublishPort=127.0.0.1:11434:11434 bindet die Host-Seite an das Loopback-Interface. Prüfen Sie dies:

ss -ltnp | grep 11434
curl http://127.0.0.1:11434

Die Ausgabe von ss muss 127.0.0.1:11434 anzeigen. 0.0.0.0:11434 oder *:11434 bedeutet, dass der Port aus dem Internet erreichbar ist, und auf curl muss Ollama is running antworten.

Achten Sie genau darauf, an welche Seite Sie binden. Die Adresse in PublishPort ist die Host-Adresse. Im Container muss Ollama weiterhin auf allen Interfaces lauschen. Das ist der Standard der Image-Konfiguration. Wenn Sie mit Environment=OLLAMA_HOST=127.0.0.1 an das Loopback-Interface des Containers binden, leitet Podman veröffentlichte Verbindungen stattdessen an die Netzwerkadresse des Containers weiter. Deshalb wird jede Anfrage abgewiesen, auch vom Host.

Ein offener Port 11434 verursacht zwei Probleme. Ollama bietet keine Authentifizierung. Jeder, der den Port erreicht, kann über /api/tags Ihre Modelle auflisten, über /api/generate Inferenz auf Ihrer CPU ausführen und Ihr Bandbreitenkontingent nutzen, neue Modelle auf Ihre Festplatte laden und vorhandene Modelle löschen. Außerdem werden Prompts und Ausgaben bei unverschlüsseltem HTTP zu einem entfernten Port im Klartext übertragen. Jeder Rechner entlang des Übertragungswegs kann sie lesen. Beide Probleme verschwinden, wenn der Port den Rechner nie verlässt.

Leiten Sie den Port von Ihrer Workstation über SSH weiter:

ssh -N -L 11434:127.0.0.1:11434 you@vps.example.com

Jetzt ist http://127.0.0.1:11434 auf Ihrem Laptop der Ollama-Dienst des Servers. Die Verbindung ist innerhalb der Verschlüsselung der SSH-Sitzung geschützt. Wenn auf Ihrem Laptop bereits Ollama läuft, schlägt die lokale Bindung mit bind [127.0.0.1]:11434: Address already in use fehl. Verwenden Sie -L 11435:127.0.0.1:11434 und richten Sie Ihren Client auf Port 11435.

Wenn ein Browser-Client benötigt wird, setzen Sie stattdessen einen Reverse Proxy mit Passwort davor. Ein Caddy-Site-Block umfasst vier Zeilen, und caddy hash-password gibt den benötigten bcrypt-Hash aus:

ollama.example.com {
  basic_auth {
    you $2a$14$replace_with_the_generated_hash
  }
  reverse_proxy 127.0.0.1:11434
}

Caddy ruft selbstständig ein Zertifikat über TLS (Transport Layer Security) ab, sodass der Datenverkehr verschlüsselt ist. Testen Sie Ihren Client zuerst. Viele Tools, die mit Ollama kommunizieren, bieten kein Feld für einen Authorization-Header. Sie schlagen bei der Basic-Authentifizierung mit einem einfachen 401 Unauthorized fehl. Der SSH-Tunnel hat dieses Problem nicht. Deshalb wird er hier standardmäßig empfohlen.

Ein Modell herunterladen und den gesamten Pfad prüfen

podman exec -it ollama ollama pull gemma3:4b
curl -s http://127.0.0.1:11434/api/tags
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"gemma3:4b","prompt":"Reply with the single word: ready","stream":false}'
du -sh ~/ollama-data/models

/api/tags gibt JSON mit einer Auflistung von gemma3:4b zurück. /api/generate gibt nach einer kurzen Pause, während die Gewichte vom Datenträger geladen werden, ein JSON-Objekt mit einem Feld response zurück. du sollte eine Zahl liefern, die nahe an der veröffentlichten Downloadgröße liegt. Beweisen Sie anschließend den Teil, um den es in dieser gesamten Anleitung geht:

sudo reboot
# reconnect, then:
sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user is-active ollama.service

active bedeutet, dass der Prozess weiterläuft. Der Abschnitt [Install] und daemon-reload haben ihre Aufgabe erfüllt. inactive bedeutet, dass einer der drei Bestandteile fehlt.

Fehlerbilder mit den angezeigten Meldungen

Der Container ist nach einem Reboot nicht mehr vorhanden. Prüfen Sie zuerst loginctl show-user ollama --property=Linger, weil die systemd-Instanz des Benutzers ohne Linger=yes beim Booten nicht gestartet wird. Wenn Lingering aktiviert ist, fehlt der Abschnitt [Install] in der Datei .container, oder Sie haben die Datei bearbeitet und systemctl --user daemon-reload nicht ausgeführt.

Error: statfs /home/ollama/ollama-data: no such file or directory. Das Quellverzeichnis des Bind-Mounts muss vor dem Start des Containers vorhanden sein. Podman erstellt keine Verzeichnisse auf dem Host. Führen Sie mkdir -p ~/ollama-data als Benutzer ollama aus.

Der Start schlägt nach 90 Sekunden fehl. journalctl --user -u ollama.service zeigt Start operation timed out. Terminating. an, weil der Image-Pull noch lief. Führen Sie den Pull manuell aus oder lassen Sie TimeoutStartSec=900 aktiviert.

Der Container startet und wird beendet. podman logs ollama und sudo ausearch -m avc -ts recent zeigen zusammen, ob das SELinux-Label die Ursache ist. Ein AVC, in dem container_t und user_home_t genannt werden, bedeutet, dass :Z fehlt.

Anfragen vom Host werden abgewiesen. curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused mit dem Dienst active bedeutet normalerweise, dass OLLAMA_HOST im Container auf eine Loopback-Adresse gesetzt wurde. Entfernen Sie diese Zeile.

Die Generierung dauert sehr lange, oder der Container wird beendet. Ohne GPU läuft die Inferenz auf der CPU und ist bei einem großen Modell naturgemäß langsam. Wenn ein Container während einer Anfrage beendet wird und die Logs signal: killed enthalten, war der Out-of-Memory-Killer des Kernels aktiv. Wählen Sie daher aus der obigen Tabelle einen kleineren Tag aus.

Ein gepinntes Image aktualisieren

Durch das Pinnen werden Aktualisierungen zu einem Vorgang, den Sie gezielt ausführen, statt zu etwas, das unkontrolliert geschieht. Bearbeiten Sie Image= in ollama.container und laden Sie anschließend neu und starten Sie den Dienst neu:

systemctl --user daemon-reload
systemctl --user restart ollama.service
podman exec ollama ollama --version

Die Modelle liegen im Bind-Mount und bleiben beim Image-Wechsel unverändert erhalten. AutoUpdate=registry im Abschnitt [Container] ist für den Betrieb mit einem veränderlichen Tag vorgesehen. Neben einem festen Versions-Tag hat es keinen Nutzen, weil sich der Inhalt dieses Tags nie ändert. Sichern Sie /home/ollama/ollama-data/models/manifests und die Datei .container. Lassen Sie die Blobs aus: Sie sind groß, und ollama pull lädt sie auf einem neuen System erneut herunter.

FAQ

Warum wird mein rootless Podman-Container beendet, wenn ich mich abmelde?

Die systemd-Instanz eines Benutzers und das zugehörige Verzeichnis /run/user/<uid> werden beendet, sobald die letzte Sitzung dieses Benutzers endet. Damit werden auch alle rootless Container beendet. Führen Sie sudo loginctl enable-linger ollama aus und bestätigen Sie, dass loginctl show-user ollama --property=Linger den Wert Linger=yes ausgibt. Aktivieren Sie Lingering, bevor Sie die Quadlet-Unit erstellen. Das von der Unit benötigte Laufzeitverzeichnis ist erst vorhanden, wenn Lingering aktiviert ist.

Benötige ich SELinux-Labels für das Ollama-Modellverzeichnis?

Unter Fedora, RHEL, Rocky und AlmaLinux ist das erforderlich, wenn Sie ein Hostverzeichnis einbinden. Der Container läuft in der Domäne container_t. Ein Verzeichnis im Home-Verzeichnis ist mit user_home_t gekennzeichnet. Dadurch wird der Schreibzugriff verweigert und Ollama beendet sich. Ergänzen Sie :Z in der Zeile Volume= und verwenden Sie dafür ein eigenes Unterverzeichnis. Die Neusetzung der Labels erfolgt rekursiv. Wenn Sie :Z auf ein vollständiges Home-Verzeichnis verweisen, funktioniert der Zugriff dieses Benutzers auf SSH-Schlüssel nicht mehr. Named Volumes werden von Podman korrekt gekennzeichnet und benötigen keine zusätzlichen Einstellungen.

Wie viel Speicherplatz benötigt ein Ollama-Modell?

Orientieren Sie sich zunächst an der veröffentlichten Downloadgröße auf ollama.com/library. Sie reicht von 3.3 GB für gemma3:4b bis zu 19 GB für qwen3:30b. Rechnen Sie zusätzlich das Podman-Image ein und lassen Sie freien Speicherplatz. Ein zweites Modell ersetzt das erste nicht auf dem Datenträger. Prüfen Sie df -h /home vor dem Abruf und du -sh ~/ollama-data/models danach. Planen Sie den Arbeitsspeicher entsprechend: Während des Ladens benötigt ein Modell ungefähr seine Dateigröße im Arbeitsspeicher, zusätzlich zum Context Window.

Ist es sicher, Port 11434 auf einem VPS bereitzustellen?

Nein. Ollama wird ohne jegliche Authentifizierung ausgeliefert. Jeder, der den Port erreicht, kann Ihre Modelle auflisten und löschen, neue Modelle auf Ihren Datenträger laden sowie Inferenz auf Ihrer CPU und innerhalb Ihres verfügbaren Bandbreitenkontingents ausführen. Unverschlüsseltes HTTP über das Internet überträgt außerdem jeden Prompt und jede Completion im Klartext. Binden Sie die Host-Seite mit PublishPort=127.0.0.1:11434:11434 an 127.0.0.1, bestätigen Sie dies mit ss -ltnp | grep 11434 und greifen Sie über einen SSH-Tunnel oder einen Reverse Proxy mit erforderlicher Passwortauthentifizierung darauf zu.