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

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
- Betriebssystem: Ubuntu 22.04 LTS, 24.04 LTS oder 26.04 LTS bzw. Debian 12 oder 13,
amd64oderarm64; maßgeblich ist die Support-Matrix von Elastic - RAM: Mindestens 2 GB (für Tests); Empfehlung für Produktion: 8 GB oder mehr
- Festplatte: Mindestens 20 GB freier Speicherplatz für Daten und Logs
- Zugang: Root- oder
sudo-Berechtigung auf dem Server - Netzwerk: Internetverbindung zum Elastic APT-Repository (
artifacts.elastic.co) - Firewall: UFW vorinstalliert (bei Ubuntu standardmäßig vorhanden;
sudo apt install ufwfalls 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 gpgGPG-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.gpgFingerprint des importierten Schlüssels anzeigen und prüfen:
gpg --no-default-keyring \
--keyring /usr/share/keyrings/elasticsearch-keyring.gpg \
--fingerprintVerifizieren: 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.sourcesLegen Sie nur eine der beiden Varianten an (DEB822 oder elastic-9.x.list), sonst meldet APT doppelte Quellen.
Repository-Einbindung testen:
sudo apt updateVerifizieren: 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 elasticsearchDie 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.serviceDienststatus prüfen:
sudo systemctl status elasticsearch.serviceVerifizieren: 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 elasticOhne -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:9200Verifizieren: 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.ymlPassen 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.p12Nach Änderungen Dienst neu starten:
sudo systemctl restart elasticsearch.serviceBleibt 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-RAM | Empfohlener Heap (-Xms/-Xmx) | Hinweis |
|---|---|---|
| 4 GB | 2g | Minimum für Testsysteme |
| 8 GB | 4g | Typisches KMU-Szenario |
| 16 GB | 8g | Produktionsserver (klein) |
| 32 GB | 16g | Produktionsserver (mittel) |
| 64 GB+ | 26g | Compressed-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 OpenSSHElasticsearch-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 tcpUFW aktivieren und Status prüfen:
sudo ufw enable
sudo ufw status numberedAktive 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_systemVerifizieren: 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 httpKeystore-Passwort sicher hinterlegen:
sudo /usr/share/elasticsearch/bin/elasticsearch-keystore add \
xpack.security.http.ssl.keystore.secure_passwordDie 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/*.p12Verifizieren: 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.serviceDamit 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 elasticsearchVerifizieren: Die Abfrage aus Schritt 5 zeigt die neue version.number.
Übersicht: Wichtige Pfade und Ports
| Zweck | Pfad / 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-API | Port 9200 (HTTPS) |
| Node-to-Node-Transport | Port 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
- VPS absichern und härten: UFW, SSH-Keys und Fail2Ban – Basis-Härtung für jeden Linux-Server
- PostgreSQL nativ installieren und absichern (Ubuntu/Debian, ohne Docker) – natives Datenbank-Setup im selben Cluster-Stil
- MongoDB nativ installieren und absichern (Ubuntu/Debian, ohne Docker) – weiteres NoSQL-Pendant zur nativen Elasticsearch-Anleitung
- Linux-Server absichern: UFW-Firewall und Fail2Ban – ergänzende Absicherungsmaßnahmen
- Elasticsearch: Install with Debian Package (offizielle Elastic-Dokumentation)
- Elasticsearch: Security mit automatischer Konfiguration (offizielle Elastic-Dokumentation)


