Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Datenbanken 15.06.2026 · 9 min Lesezeit

Elasticsearch 9 nativ auf Ubuntu/Debian installieren und absichern (APT, TLS, UFW)

Elasticsearch 9 nativ auf Ubuntu und Debian: APT-Repository mit Schlüsselprüfung, automatisches TLS, Passwort sichern, http.host absichern, UFW-Regeln für 9200 und 9300, Heap und Updates, ohne Docker.

Geprüft am 30.09.2026

WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Geschlossenes Vorhängeschloss auf einem Rack-Server in einem Rechenzentrumsgang mit blauen Status-LEDs

Die native Installation von Elasticsearch als systemd-Dienst, gepflegt per APT, vermeidet Container-Netzwerk und Cgroup-Grenzen und lässt sich direkt über journald und systemd überwachen. Seit Elasticsearch 8 richtet das Paket bei der Installation TLS und ein Passwort für den Superuser elastic automatisch ein. Diese Anleitung führt Sie von der Repository-Einrichtung über Netzwerkbindung und UFW bis zu Heap und Updates.

Voraussetzungen

  1. Betriebssystem: Ubuntu 22.04 LTS, 24.04 LTS oder 26.04 LTS bzw. Debian 12 oder 13, amd64 oder arm64; maßgeblich ist die Support-Matrix von Elastic
  2. RAM: Mindestens 2 GB (für Tests); Empfehlung für Produktion: 8 GB oder mehr
  3. Festplatte: Mindestens 20 GB freier Speicherplatz für Daten und Logs
  4. Zugang: Root- oder sudo-Berechtigung auf dem Server
  5. Netzwerk: Internetverbindung zum Elastic APT-Repository (artifacts.elastic.co)
  6. Firewall: UFW vorinstalliert (bei Ubuntu standardmäßig vorhanden; sudo apt install ufw falls nicht)

Schritt 1: Abhängigkeiten installieren und GPG-Schlüssel einrichten

Installieren Sie die benötigten Pakete und importieren Sie den Signaturschlüssel von Elastic.

sudo apt update
sudo apt install -y ca-certificates curl gpg

GPG-Schlüssel herunterladen und im Keyring ablegen:

sudo install -d -m 0755 /usr/share/keyrings
curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch \
  | sudo gpg --dearmor --yes -o /usr/share/keyrings/elasticsearch-keyring.gpg
sudo chmod 0644 /usr/share/keyrings/elasticsearch-keyring.gpg

Fingerprint des importierten Schlüssels anzeigen und prüfen:

gpg --no-default-keyring \
  --keyring /usr/share/keyrings/elasticsearch-keyring.gpg \
  --fingerprint

Verifizieren: Die Ausgabe muss den Fingerprint 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 enthalten. Weicht der Wert ab, brechen Sie ab und installieren Sie nichts.

Schritt 2: APT-Repository hinzufügen

Das Elastic APT-Repository verwendet die Suite-Bezeichnung stable – nicht den Ubuntu-Codenamen wie jammy oder noble. Ein Codename führt zu 404-Fehlern bei apt update.

DEB822-Format:

printf '%s\n' \
  'Types: deb' \
  'URIs: https://artifacts.elastic.co/packages/9.x/apt' \
  'Suites: stable' \
  'Components: main' \
  'Architectures: amd64 arm64' \
  'Signed-By: /usr/share/keyrings/elasticsearch-keyring.gpg' \
  | sudo tee /etc/apt/sources.list.d/elasticsearch.sources

Legen Sie nur eine der beiden Varianten an (DEB822 oder elastic-9.x.list), sonst meldet APT doppelte Quellen.

Repository-Einbindung testen:

sudo apt update

Verifizieren: apt update darf keinen Fehler für artifacts.elastic.co ausgeben. Ein Hit oder Get in der Ausgabe bestätigt die korrekte Einbindung.

Schritt 3: Elasticsearch installieren und als systemd-Dienst einrichten

sudo apt install elasticsearch

Die Installation gibt einen Block Security autoconfiguration information aus. Er enthält die Zeile The generated password for the elastic built-in superuser is : …. Speichern Sie das Passwort sofort in Ihrem Passwortmanager; es erscheint nur hier und nicht im Journal.

Danach systemd-Konfiguration neu laden, Autostart aktivieren und den Dienst starten:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service

Dienststatus prüfen:

sudo systemctl status elasticsearch.service

Verifizieren: Die Ausgabe zeigt Active: active (running). Der Status activating ist beim ersten Start für bis zu etwa eine Minute normal.

Schritt 4: Passwort sichern oder zurücksetzen

Haben Sie das Passwort aus Schritt 3 nicht gesichert, setzen Sie es bei laufendem Dienst neu, interaktiv mit selbst gewähltem Passwort:

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -i -u elastic

Ohne -i erzeugt das Werkzeug ein zufälliges Passwort und gibt es aus.

Verifizieren: Schritt 5 liefert mit dem Passwort eine JSON-Antwort statt 401.

Schritt 5: Installation testen (HTTPS mit Auto-TLS)

Elasticsearch hört nach dem Erststart bereits auf HTTPS. Das automatisch generierte CA-Zertifikat liegt unter /etc/elasticsearch/certs/http_ca.crt und wird beim Test-Request als vertrauenswürdige CA angegeben:

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt \
  -u elastic \
  https://localhost:9200

Verifizieren: Die Antwort ist ein JSON-Objekt mit den Feldern cluster_name, version.number (z. B. 9.5.4) und tagline: "You Know, for Search". curl fragt das Passwort ab, damit es nicht in der Shell-History landet.

Schritt 6: Produktionskonfiguration in elasticsearch.yml

Die zentrale Konfigurationsdatei liegt unter /etc/elasticsearch/elasticsearch.yml. Die Auto-Konfiguration hat dort am Ende einen Block angehängt, unter anderem mit cluster.initial_master_nodes und http.host: 0.0.0.0. http.host hat Vorrang vor network.host; solange die Zeile steht, lauscht die REST-API auf allen Interfaces.

sudo nano /etc/elasticsearch/elasticsearch.yml

Passen Sie die Datei für einen Einzelserver so an; entfernen Sie die Zeilen cluster.initial_master_nodes und http.host: 0.0.0.0 im automatisch erzeugten Block:

# Cluster- und Node-Identitaet (immer explizit setzen)
cluster.name: mein-prod-cluster
node.name: node-01

# Netzwerk: nur lokal oder interne IP, NICHT 0.0.0.0
# (http.host: 0.0.0.0 aus der Auto-Konfiguration entfernen)
network.host: 127.0.0.1
# Fuer Zugriff aus dem internen Netz:
# network.host: 10.0.1.5

# Ports
http.port: 9200
transport.port: 9300

# Einzelinstanz; cluster.initial_master_nodes muss dann entfernt sein
discovery.type: single-node

# Datenpfade (korrekt durch APT gesetzt)
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

# Security (automatisch vom Erststart geschrieben - nur pruefen, nicht loeschen)
xpack.security.enabled: true
xpack.security.enrollment.enabled: true

xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/http.p12

xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12

Nach Änderungen Dienst neu starten:

sudo systemctl restart elasticsearch.service

Bleibt cluster.initial_master_nodes neben discovery.type: single-node stehen, startet Elasticsearch nicht (setting [cluster.initial_master_nodes] is not allowed when [discovery.type] is set to [single-node]). Mit network.host auf einer anderen Adresse als Loopback aktiviert Elasticsearch die Bootstrap-Checks für den Produktionsbetrieb.

Verifizieren: sudo grep -nE '^(http\.host|network\.host|cluster\.initial_master_nodes|discovery\.type)' /etc/elasticsearch/elasticsearch.yml zeigt nur network.host und discovery.type; systemctl is-active elasticsearch meldet active.

Schritt 7: JVM-Heap korrekt dimensionieren

Elasticsearch berechnet den Heap automatisch aus Rolle und Arbeitsspeicher; Elastic empfiehlt diese Voreinstellung für die meisten Produktivsysteme. Setzen Sie den Heap nur manuell, wenn weitere Dienste auf dem Host Speicher brauchen. Obergrenzen: höchstens 50 % des RAM und unter der Grenze für Compressed Object Pointers (etwa 26 GB sicher, auf manchen Systemen bis 30 GB).

Manuelle Vorgabe, Beispiel für 8 GB RAM:

printf '%s\n' '-Xms4g' '-Xmx4g' \
  | sudo tee /etc/elasticsearch/jvm.options.d/heap.options
sudo systemctl restart elasticsearch.service

-Xms und -Xmx müssen gleich sein.

Server-RAMEmpfohlener Heap (-Xms/-Xmx)Hinweis
4 GB2gMinimum für Testsysteme
8 GB4gTypisches KMU-Szenario
16 GB8gProduktionsserver (klein)
32 GB16gProduktionsserver (mittel)
64 GB+26gCompressed-Oops-Grenze beachten

Verifizieren: sudo journalctl -u elasticsearch -n 200 | grep 'heap size' oder /var/log/elasticsearch/*.log zeigt compressed ordinary object pointers [true].

Schritt 8: UFW-Firewall-Regeln setzen

Port 9200 (REST-API) und 9300 (Transport) dürfen nur für vertrauenswürdige IPs oder Subnetze erreichbar sein. Die Grundabsicherung beschreibt die Anleitung VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban.

Grundlegende UFW-Konfiguration sicherstellen:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH

Elasticsearch-Ports gezielt freigeben:

# Port 9200 nur fuer eine bestimmte Anwendungs-IP:
sudo ufw allow from 192.168.1.50 to any port 9200 proto tcp

# Oder fuer ein ganzes internes Subnetz:
sudo ufw allow from 10.0.1.0/24 to any port 9200 proto tcp

# Port 9300 (Transport) nur intern (fuer Cluster-Setups):
sudo ufw allow from 10.0.1.0/24 to any port 9300 proto tcp

UFW aktivieren und Status prüfen:

sudo ufw enable
sudo ufw status numbered

Aktive Listener kontrollieren:

sudo ss -tlnp | grep -E ':9200|:9300'

Verifizieren: ss zeigt Port 9200 nur auf der in network.host konfigurierten Adresse, nicht auf 0.0.0.0 oder *. ufw status listet die definierten Regeln für Ports 9200 und 9300.

Schritt 9: Weitere Built-in-User einrichten (optional)

Für Kibana oder Logstash setzen Sie die Passwörter der internen Benutzer (für Kibana ist alternativ ein Enrollment-Token vorgesehen):

# Kibana-System-Benutzer:
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u kibana_system

# Logstash-System-Benutzer:
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u logstash_system

Verifizieren: curl --cacert /etc/elasticsearch/certs/http_ca.crt -u kibana_system https://localhost:9200/_security/_authenticate liefert "username":"kibana_system".

Schritt 10: Manuelles TLS-Zertifikat mit elasticsearch-certutil (optional)

Für eine eigene CA oder gezielt gesetzte Hostnamen und SANs (Subject Alternative Names) nutzen Sie elasticsearch-certutil:

# Eigene CA erzeugen:
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil ca \
  --out /etc/elasticsearch/certs/elastic-stack-ca.p12

# HTTP-Zertifikat erzeugen (interaktiv, Ergebnis als ZIP):
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil http

Keystore-Passwort sicher hinterlegen:

sudo /usr/share/elasticsearch/bin/elasticsearch-keystore add \
  xpack.security.http.ssl.keystore.secure_password

Die neuen Dateien müssen für die Gruppe elasticsearch lesbar sein:

sudo chown root:elasticsearch /etc/elasticsearch/certs/*.p12
sudo chmod 0640 /etc/elasticsearch/certs/*.p12

Verifizieren: openssl s_client -connect localhost:9200 -servername ihr-host </dev/null | openssl x509 -noout -issuer -ext subjectAltName zeigt Ihre CA und die gewünschten SANs.

Schritt 11: Elasticsearch aktualisieren

Lesen Sie vor jedem Minor-Update die Release Notes und legen Sie einen Snapshot an:

sudo apt update
sudo apt install --only-upgrade elasticsearch
sudo systemctl restart elasticsearch.service

Damit ein unbeaufsichtigtes apt upgrade Elasticsearch nicht mitaktualisiert, halten Sie das Paket fest (vor dem Update mit apt-mark unhold lösen):

sudo apt-mark hold elasticsearch

Verifizieren: Die Abfrage aus Schritt 5 zeigt die neue version.number.

Übersicht: Wichtige Pfade und Ports

ZweckPfad / Port
Hauptkonfiguration/etc/elasticsearch/elasticsearch.yml
JVM-Optionen (benutzerdefiniert)/etc/elasticsearch/jvm.options.d/*.options
Umgebungsvariablen/etc/default/elasticsearch
TLS-Zertifikate (auto-generiert)/etc/elasticsearch/certs/
CA-Zertifikat für Clients/etc/elasticsearch/certs/http_ca.crt
Datenpfad/var/lib/elasticsearch
Logpfad/var/log/elasticsearch
Binaries und Tools/usr/share/elasticsearch/bin/
Systemd-Unit/usr/lib/systemd/system/elasticsearch.service
HTTP-REST-APIPort 9200 (HTTPS)
Node-to-Node-TransportPort 9300 (TCP)

Troubleshooting / Typische Fehler

Passwort beim Erststart verpasst

Das Passwort erscheint nur einmal in der Ausgabe von apt install. Setzen Sie es neu: sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -i -u elastic.

Repository-Suite falsch angegeben

Die Suite im APT-Eintrag muss stable heißen, nicht jammy, focal oder ein anderer Ubuntu-Codename. Falscher Eintrag führt zu 404-Fehlern beim apt update.

curl gibt „SSL certificate problem“ zurück

Geben Sie --cacert /etc/elasticsearch/certs/http_ca.crt an. Nach einem manuellen certutil-Lauf muss der Client das neue CA-Zertifikat verwenden.

Dienst startet nach YAML-Änderung nicht mehr

YAML verlangt Leerzeichen statt Tabs; doppelte Schlüssel (etwa xpack.security.http.ssl zweimal) führen ebenfalls zum Abbruch. Logs: sudo journalctl -u elasticsearch.service -n 50.

Security-Auto-Config wurde nicht ausgeführt

Die automatische Sicherheitskonfiguration läuft nur bei der Erstinstallation und nur, wenn Security nicht bereits konfiguriert oder abgeschaltet ist. Andernfalls richten Sie TLS und Passwort manuell ein (Schritt 4 und 10).

Heap-Warning: „heap size is too high“

Verkleinern Sie die Werte in /etc/elasticsearch/jvm.options.d/heap.options oder löschen Sie die Datei, damit die automatische Berechnung greift, und starten Sie den Dienst neu.

Zertifikatspfade falsch oder Berechtigungen fehlen

Wenn http.p12 oder transport.p12 nicht in /etc/elasticsearch/certs/ liegen oder die Rechte für den Benutzer elasticsearch nicht stimmen, startet der Dienst nicht. Prüfen mit ls -la /etc/elasticsearch/certs/.

Häufige Fragen

Wird Docker benötigt?

Nein. Das Debian-Paket läuft als systemd-Dienst direkt auf dem Host.

Ist TLS bei Elasticsearch 9 standardmäßig aktiv?

Ja. Seit Version 8.0 richtet die Paketinstallation TLS für HTTP und Transport ein und legt die Zertifikate unter /etc/elasticsearch/certs/ ab.

Wie groß soll der JVM-Heap sein?

In der Regel lassen Sie Elasticsearch den Heap automatisch berechnen. Manuell höchstens 50 % des RAM und nicht über etwa 26 GB, siehe Schritt 7.

Was ist der Unterschied zwischen Port 9200 und 9300?

Port 9200 ist die HTTPS-REST-API für alle Clients (Anwendungen, Kibana, Logstash). Port 9300 ist der interne TCP-Transport-Port für die Node-zu-Node-Kommunikation im Cluster. Beschränken Sie beide per UFW auf vertrauenswürdige IPs.

Kann Elasticsearch auf ARM-Servern betrieben werden?

Ja. Das APT-Repository enthält Pakete für amd64 und arm64.

Was passiert, wenn cluster.initial_master_nodes in der Config bleibt?

Die Auto-Konfiguration schreibt sie für den ersten Clusterstart; danach sollte sie entfernt werden. Zusammen mit discovery.type: single-node ist sie unzulässig, Elasticsearch startet dann nicht.

Fazit

APT-Repository und automatische Sicherheitskonfiguration machen die native Installation überschaubar. Entscheidend für den Betrieb sind drei Punkte: http.host: 0.0.0.0 durch eine lokale oder interne Adresse ersetzen, Ports 9200 und 9300 per UFW begrenzen und das Passwort des Superusers sicher verwahren.

Weiterführende Anleitungen und Quellen

  1. VPS absichern und härten: UFW, SSH-Keys und Fail2Ban – Basis-Härtung für jeden Linux-Server
  2. PostgreSQL nativ installieren und absichern (Ubuntu/Debian, ohne Docker) – natives Datenbank-Setup im selben Cluster-Stil
  3. MongoDB nativ installieren und absichern (Ubuntu/Debian, ohne Docker) – weiteres NoSQL-Pendant zur nativen Elasticsearch-Anleitung
  4. Linux-Server absichern: UFW-Firewall und Fail2Ban – ergänzende Absicherungsmaßnahmen
  5. Elasticsearch: Install with Debian Package (offizielle Elastic-Dokumentation)
  6. Elasticsearch: Security mit automatischer Konfiguration (offizielle Elastic-Dokumentation)