„MQTT Connection Refused: Not Authorized“ beheben (rc 5 und 0x87)

„MQTT Connection Refused: Not Authorized“ bedeutet, dass der Broker Ihr CONNECT-Paket empfangen und verstanden hat und entschieden hat, dass dieser Client sich nicht verbinden darf. In MQTT 3.1.1 ist das der CONNACK-Rückgabecode 5, in MQTT 5 der Reason Code 0x87. Dieser Leitfaden liefert Ihnen eine Schritt-für-Schritt-Checkliste zur Ursachensuche, von Zugangsdaten und Client IDs bis zu verwechselten Ports und Konten pro Broker, und zeigt, wie Sie jeden Schritt per Kommandozeile testen.

Was „Not Authorized“ Ihnen tatsächlich sagt

Der Fehler ist aussagekräftiger, als er aussieht. Damit Sie ihn überhaupt erhalten, muss bereits einiges funktionieren:

• DNS hat den Broker-Host aufgelöst.
• Die TCP-Verbindung und gegebenenfalls TLS wurden aufgebaut.
• Der Broker hat ein gültiges CONNECT-Paket geparst.
• Die Protokollversion wurde akzeptiert.

Das Netzwerk ist also in Ordnung. Das Problem liegt bei Identität oder Berechtigung. Je nach Tool sehen Sie den Fehler unterschiedlich formuliert:

Einen verwandten Code sollten Sie früh abgrenzen. Rückgabecode 4 (0x86 in MQTT 5) bedeutet „bad user name or password“: Die Zugangsdaten selbst stimmten nicht. Code 5 (0x87) ist weiter gefasst: Der Broker lehnt diesen Client aus einem Autorisierungsgrund ab. Manche Broker geben auch bei falschen Passwörtern 5 zurück. Behandeln Sie daher beide als „Identität prüfen“, lesen Sie aber den genauen Code. Der Leitfaden zu den MQTT-CONNACK-Rückgabecodes erklärt jeden Wert.

Die Checkliste zur Fehlerbehebung bei Not Authorized

Arbeiten Sie diese Schritte der Reihe nach ab. Die meisten Fälle sind spätestens mit Schritt 3 gelöst.

1. Prüfen Sie, mit welchem Broker Sie sich verbinden. Geben Sie zur Laufzeit Host und Port aus, die Ihr Code tatsächlich verwendet, nicht die, die Sie für konfiguriert halten. Umgebungsvariablen und Konfigurationsdateien überschreiben sich häufig gegenseitig.
2. Kopieren Sie die Zugangsdaten neu. Fügen Sie Benutzername und Passwort frisch von der Zugangsdatenseite des Brokers ein. Achten Sie auf führende oder abschließende Leerzeichen, Zeilenumbrüche durch das Kopieren und vertauschte Benutzernamen und Passwörter.
3. Verwenden Sie die Client ID, die zu den Zugangsdaten gehört. Viele verwaltete MQTT-Broker binden eine Client ID an das ausgegebene Konto. Erzeugt Ihr Code eine zufällige ID oder verwendet eine aus einem anderen Projekt, kann der Broker sie ablehnen, obwohl das Passwort stimmt.
4. Prüfen Sie, ob die Bibliothek die Zugangsdaten sendet. In Paho muss username_pw_set() vor connect() aufgerufen werden. Nutzen Sie in Arduino PubSubClient die Überladung connect(clientId, user, pass), nicht connect(clientId).
5. Prüfen Sie das Quoting der Shell. Passwörter mit $, ! oder & werden von Bash verstümmelt. Verwenden Sie einfache Anführungszeichen: -P 'p@ss$word!'.
6. Prüfen Sie Port und Transport. Port 1883 ist reines TCP, 8883 ist TLS, 8083 ist WebSocket und 8084 ist sicheres WebSocket mit dem Pfad /mqtt. Eine Verwechslung führt meist zu einem Timeout oder TLS-Fehler statt zu „not authorized“, doch ein falsch konfigurierter Client kann bei einem anderen Listener oder einer anderen Umgebung als beabsichtigt landen.
7. Prüfen Sie, ob das Konto aktiv ist. Zugangsdaten wurden möglicherweise neu generiert, ein Broker gelöscht oder neu angelegt, oder Sie verwenden Staging-Zugangsdaten gegen die Produktion.
8. Prüfen Sie die Verbindungskontingente. Ist das Verbindungslimit des Plans erreicht, erhalten MQTT-5-Clients 0x97 Quota exceeded, manche 3.1.1-Bibliotheken melden jedoch jede Ablehnung generisch. Zählen Sie Ihre aktiven Verbindungen.
9. Hören Sie auf, es in einer Schleife zu versuchen. Jeder Fehlversuch ist aus Sicht des Brokers eine fehlgeschlagene Anmeldung. Gehen Sie in den Backoff, während Sie untersuchen.

Zugangsdaten per Kommandozeile testen

Trennen Sie Ihre Anwendung vom Problem, indem Sie exakt dieselben Zugangsdaten mit den Mosquitto-Tools testen. Belegen Sie zuerst mit dem anonymen öffentlichen MQTT-Broker, der für Tests und nicht für Produktionsdaten gedacht ist, dass der Netzwerkpfad funktioniert:

mosquitto_sub -h broker.connectmq.com -p 1883 -i auth-check-2d9f \
  -t "connectmq/demo/2d9f/#" -d -C 1 -W 5

Sehen Sie received CONNACK (0), kann Ihr Rechner den Broker erreichen und MQTT sprechen. Testen Sie als Nächstes Ihre privaten Zugangsdaten über TLS:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u 'YOUR_USERNAME' -P 'YOUR_PASSWORD' -i 'YOUR_CLIENT_ID' \
  -t "test/#" -d -V mqttv5

Mit -V mqttv5 gibt eine Ablehnung den MQTT-5-Reason-Code aus, der genauer ist als der 3.1.1-Code. Verbindet sich dieser Befehl, Ihre Anwendung aber nicht, liegt das Problem in der Konfiguration Ihrer Anwendung, nicht im Konto. Schlägt auch dieser Befehl fehl, liegt das Problem bei Zugangsdaten, Client ID oder Konto.

Unter Windows steht --capath nicht in derselben Form zur Verfügung; verwenden Sie stattdessen --cafile mit einer CA-Bundle-Datei oder testen Sie mit einem grafischen MQTT-Client.

Den Fehler im Code beheben

Hier ein Python-Client, der die tatsächlich verwendete Konfiguration ausgibt und bei Autorisierungsfehlern aufhört, statt es endlos erneut zu versuchen:

import os
import ssl
import paho.mqtt.client as mqtt

HOST = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "8883"))
USERNAME = os.getenv("MQTT_USERNAME", "YOUR_USERNAME")
PASSWORD = os.getenv("MQTT_PASSWORD", "YOUR_PASSWORD")
CLIENT_ID = os.getenv("MQTT_CLIENT_ID", "YOUR_CLIENT_ID")

print(f"Connecting to {HOST}:{PORT} as user={USERNAME!r} client_id={CLIENT_ID!r}")

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print(f"Refused: {reason_code} (0x{reason_code.value:02X})")
        if reason_code.value in (0x85, 0x86, 0x87):
            print("Identity problem: check username, password and client ID")
            client.disconnect()
        return
    print("Connected")

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=CLIENT_ID,
    protocol=mqtt.MQTTv5,
)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.connect(HOST, PORT, keepalive=60)
client.loop_forever()

Die Formatierung !r gibt Werte mit Anführungszeichen aus, wodurch unsichtbare Leerzeichen sofort auffallen. Diese eine Zeile hat schon viele Untersuchungen nach dem Motto „mein Passwort stimmt ganz sicher“ beendet.

Beim ESP32 mit PubSubClient ist die Überladung der typische Fehler:

// Falsch: Es werden keine Zugangsdaten gesendet
mqtt.connect("YOUR_CLIENT_ID");

// Richtig: Client ID, Benutzername und Passwort
mqtt.connect("YOUR_CLIENT_ID", "YOUR_USERNAME", "YOUR_PASSWORD");

Not Authorized nach dem Verbindungsaufbau

Manchmal gelingt die Verbindung, aber spätere Operationen scheitern mit „not authorized“. In MQTT 5 sehen Sie dann 0x87 in einem SUBACK oder PUBACK oder in einem DISCONNECT. Das bedeutet, dass der Client sich verbinden, ein bestimmtes Topic aber nicht nutzen darf, etwa ein reserviertes Präfix. In MQTT 3.1.1 gibt es keinen Reason Code für ein abgelehntes Publish, die Nachricht kann also einfach verschwinden. Wenn Nachrichten verschwinden, verbinden Sie sich vorübergehend per MQTT 5, um den tatsächlichen Reason Code zu sehen. Die Referenz der MQTT Reason Codes listet jeden Code nach Pakettyp auf.

So funktioniert es bei ConnectMQ

Bei ConnectMQ erhält jeder Broker, den Sie im Portal anlegen, einen generierten Benutzernamen, ein Passwort und eine Client ID, und die Client ID ist an diese Zugangsdaten gebunden. Das sollten Sie zuerst prüfen, wenn Sie 0x87 sehen: Verwenden Sie alle drei Werte vom selben Broker? Broker sind pro Mandant isoliert, daher funktionieren Zugangsdaten eines Brokers nicht auf einem anderen, selbst innerhalb desselben Kontos.

Zwei weitere Plattformeigenschaften sollten Sie kennen:

• Fehlgeschlagene Anmeldungen werden begrenzt. Nach wiederholt fehlgeschlagenen Anmeldungen wird die Quell-IP-Adresse gesperrt. Ein Gerät, das mit veralteten Zugangsdaten in einer engen Reconnect-Schleife hängt, kann andere Geräte hinter demselben NAT aussperren, etwa alle Edge-Gateways einer Werkshalle, die über eine gemeinsame Firewall ins Internet gehen. Verwenden Sie exponentiellen Backoff.
• Verbindungslimits gelten pro Plan. Der kostenlose Serverless-Plan erlaubt bis zu 25 gleichzeitige Verbindungen. Eine Überschreitung führt bei MQTT-5-Clients zu 0x97 Quota exceeded, nicht zu „not authorized“ – ein Grund mehr, beim Debugging MQTT 5 zu bevorzugen.

Zur Absicherung über die Authentifizierung hinaus lesen Sie die Best Practices für MQTT-Sicherheit, und das MQTT-Tutorial liefert das Gesamtbild des Protokolls.

Sicher verbinden mit ConnectMQ

Ein verwalteter MQTT-Broker, der zueinander passende Zugangsdaten und Client IDs ausgibt, beseitigt die meisten Ursachen dieses Fehlers, bevor sie auftreten. Registrieren Sie sich unter app.connectmq.com für einen kostenlosen Serverless-Broker ohne Kreditkarte und bestätigen Sie mit dem browserbasierten MQTT-Client, dass Ihre Zugangsdaten funktionieren, bevor Sie auch nur ein Gerät flashen. Erfahren Sie mehr über den Betrieb eines Cloud-MQTT-Brokers.

Häufig gestellte Fragen

Was bedeutet „Connection Refused: not authorised“ in den Mosquitto-Tools?

Es ist der CONNACK-Rückgabecode 5. Der Broker hat ein gültiges CONNECT empfangen, den Client aber abgelehnt, meist wegen falscher Zugangsdaten, einer nicht an das Konto gebundenen Client ID oder Zugangsdaten für einen anderen Broker.

Ist „not authorized“ dasselbe wie „bad username or password“?

Nicht ganz. Bad username or password ist Code 4 (0x86) und bedeutet, dass die Zugangsdaten nicht stimmten; not authorized ist Code 5 (0x87) und umfasst weitergehende Berechtigungsprobleme. Manche Broker verwenden für beides Code 5, prüfen Sie also in jedem Fall zuerst die Zugangsdaten.

Warum verbindet sich mein Client mit mosquitto_sub, aber nicht aus meiner App?

Die App sendet etwas anderes: einen anderen Host, eine generierte Client ID, fehlende Zugangsdaten oder ein verstümmeltes Passwort. Geben Sie die tatsächlich wirksame Konfiguration zur Laufzeit aus und vergleichen Sie sie mit dem funktionierenden Befehl.

Können wiederholte fehlgeschlagene Anmeldungen Probleme verursachen?

Ja. Viele Broker, darunter ConnectMQ, sperren IP-Adressen nach wiederholt fehlgeschlagenen Anmeldungen. Verwenden Sie exponentiellen Backoff und hören Sie bei Autorisierungsfehlern auf, es erneut zu versuchen.