Mosquitto-Befehle: MQTT-Broker betreiben und absichern

mosquitto, mosquitto_pub und mosquitto_sub sind die Werkzeuge des MQTT-Brokers Eclipse Mosquitto. MQTT ist ein leichtes Publish/Subscribe-Protokoll für Geräte mit wenig Bandbreite und Energie – der Standard in IoT und Gebäudeautomation.

Broker starten und prüfen

mosquitto -c /etc/mosquitto/mosquitto.conf -v
systemctl status mosquitto
systemctl enable --now mosquitto

# Läuft der Port?
ss -lntp | grep 1883
ss -lntp | grep 8883        # TLS

Publizieren und abonnieren

# Zuhören
mosquitto_sub -h localhost -t 'haus/+/temperatur' -v
mosquitto_sub -h localhost -t 'haus/#' -v -q 1

# Nachricht senden
mosquitto_pub -h localhost -t 'haus/wohnzimmer/temperatur' -m '21.5'
mosquitto_pub -h localhost -t 'haus/wohnzimmer/temperatur' -m '21.5' -q 1 -r

# Mit Benutzer und Passwort
mosquitto_pub -h broker.example.org -u sensor -P geheim \
  -t 'fabrik/presse/druck' -m '4.2' -q 2

# TLS
mosquitto_sub -h broker.example.org -p 8883 \
  --cafile /etc/ssl/certs/ca.pem -t 'haus/#'

Das Topic-Modell ist hierarchisch: + passt auf genau eine Ebene, # auf alle folgenden. haus/+/temperatur erhält also haus/wohnzimmer/temperatur, aber nicht haus/og/schlafzimmer/temperatur.

Quality of Service und letzte Nachricht

  • QoS 0: höchstens einmal – schnell, Verlust möglich.
  • QoS 1: mindestens einmal – Bestätigung, dafür Duplikate möglich.
  • QoS 2: genau einmal – aufwendiger Handshake, langsamer.
  • Retained Message (-r): Der Broker speichert die letzte Nachricht eines Topics und liefert sie jedem neuen Abonnenten sofort aus. Damit erhält ein neu gestartetes Gerät den aktuellen Zustand, ohne zu warten.
  • Last Will: Beim Verbinden kann ein Gerät festlegen, welche Nachricht der Broker verschickt, wenn die Verbindung unerwartet abbricht – die übliche Art, „Gerät offline“ zu melden.
# Letzte Nachricht löschen
mosquitto_pub -h localhost -t 'haus/wohnzimmer/temperatur' -r -n

# Will-Nachricht setzen
mosquitto_sub -h localhost -t 'haus/keller/temperatur' \
  --will-topic 'status/keller' --will-payload 'offline' --will-qos 1 -v

Benutzer und Zugriffskontrolle

# Passwortdatei anlegen
mosquitto_passwd -c /etc/mosquitto/passwd sensor
mosquitto_passwd /etc/mosquitto/passwd arbeiter

# Konfiguration (Auszug)
# listener 1883
# allow_anonymous false
# password_file /etc/mosquitto/passwd
# acl_file /etc/mosquitto/acl
#
# acl-Datei:
# user sensor
# topic write fabrik/presse/#
# user arbeiter
# topic read fabrik/#

Der wichtigste Sicherheitshinweis: Ohne allow_anonymous false und eine ACL darf jedes Gerät im Netz jedes Topic lesen und schreiben – auch die Steuerbefehle der Heizung. Ein offener MQTT-Broker im Internet ist eine der häufigsten IoT-Schwachstellen überhaupt. Für Produktionsbetrieb gehören TLS mit Zertifikaten, Benutzer je Gerät und eng gefasste ACLs dazu.

Diagnose

# Alle Topics beobachten (Vorsicht: viel Ausgabe)
mosquitto_sub -h localhost -t '#' -v

# Verbindungszustand im Broker-Log
journalctl -u mosquitto -f

# Topics auflisten – MQTT kennt keine Topic-Liste!
# Hilfsmittel: Nachrichten mitschneiden und Topics sammeln
mosquitto_sub -h localhost -t '#' -v | awk '{print $2}' | sort -u

Praxis-Tipps

  • Kein Topic-Verzeichnis: MQTT kennt nur Topics, die gerade benutzt werden. Ein Schema gehört in die Dokumentation, sonst entsteht Wildwuchs, den niemand mehr überblickt.
  • Retained Messages bewusst nutzen: Für Zustandswerte sinnvoll, für Ereignisse („Tür geöffnet“) falsch – ein später Abonnent bekäme sonst eine alte Meldung als aktuell.
  • QoS 2 sparsam: Es kostet vier Pakete pro Nachricht. In den meisten Fällen genügt QoS 1 mit idempotenter Verarbeitung.
  • Testablauf mit -v: Die Option zeigt Topic und Nutzlast – unverzichtbar, um zu prüfen, ob ein Gerät überhaupt sendet.

Verwandte Grundlagen: Message Queue, IoT, Message Broker, TLS 1.3.