Bareos-Fehlermeldung: Unable to authenticate with File daemon at "gitlab.thehacker.local:9102".

Als ich neulich Nacht "noch schnell" (man weiß ja, dass Computer manchmal widerspenstig sein können – ganz besonders, wenn man es eilig hat ;-) ) einen neuen Host in das Bareos-Backup aufnehmen wollte, bekam ich die obige Fehlermeldung. Die Standard-Ursache, die man auf allen Google-Treffern nach dem Problem findet, ist, dass das Passwort falsch ist. Nachdem ich mehrere Male das Passwort überprüft und Versuche unternommen hab, andere Passwörter zu probieren, hab ich gemerkt, dass in meinem Fall das nicht die Ursache ist.

Dieser Artikel zeigt euch, was das Ursache ist und wie man überhaupt dem Problem auf die Spur kommt.

Symptome

Nachdem ich meinen neuen Client zur Sicherung mit Bareos eingerichtet hatte, wollte ich prüfen, ob alles ordnungsgemäß funktioniert. Hierzu logge ich mich am Director ein und frage nach dem Status des Clients:

root@bareos:~# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*status client=gitlab-fd
Connecting to Client gitlab-fd at gitlab.thehacker.local:9102
Failed to connect to Client gitlab-fd.
====
You have messages.

Tipp: Ihr könnt in diesem Artikel nachlesen, wie man einen neuen Client in Bareos konfiguriert.

Der Director zeigt die obige Fehlermeldung an. Details erhält man, wenn die Nachrichten mit dem Kommando messages (Kurzform m genügt) aufruft:

*m
22-Jun 09:36 bareos-dir JobId 0: Fatal error: Authorization key rejected by File Daemon gitlab-fd.
Please see http://doc.bareos.org/master/html/bareos-manuel-main-reference.html#AuthorizationErrors for help.
22-Jun 09:36 bareos-dir JobId 0: Fatal error: Unable to authenticate with File daemon at "gitlab.thehacker.local:9102". Possible causes:
Passwords or names not the same or
TLS negotiation failed or
Maximum Concurrent Jobs exceeded on the FD or
FD networking messed up (restart daemon).
Please see http://doc.bareos.org/master/html/bareos-manual-main-reference.html#AuthorizationErrors for help.

• 

Auf der Suche nach der Ursache

Wie eingangs schon erwähnt, habe ich alle "normalen" Fehlerquellen abgeklappert, ohne Erfolg. Hier sind u. a. die Ursachen aufgelistet, die man mit 2 Minuten Google-Suche immer wieder findet.

• Falsches Passwort?
  • Hierzu habe ich mehrere Male das Passwort geändert, Ausschau nach Sonderzeichen gehalten, die Probleme machen können und immer wieder die Dienste reloaded bzw. neugestartet.
• Falscher Director-Name?
  • Nicht nur das Passwort muss übereinstimmen. Auch der Name des Directors muss auf beiden Rechnern übereinstimmen.
• Network-Problem?
  • Ein Fehler bei IP-Adressen, DNS oder Routing kann dazu führen, dass der Director nicht zum Client verbinden kann. Das kann man einfach durch ping und telnet prüfen.
• Zu viele Verbindungen?
  • Ausgeschlossen, da im Default bis zu 20 Verbindungen möglich sind und bis auf die eine Verbindung, mit der der Director den Status anfordern möchte, ja niemand auf den Client verbindet.
• TLS?
  • Nutz ich im lokalen Netzwerk nicht. Die Server stehen ja praktisch "nebeneinander".
• Versionskonflikt?
  • Meine Bareos-Installation ist schon einige Zeit her und der Director hat entsprechend eine etwas ältere Version. Der frisch installierte Client hingegen hat eine brandneue Version. Das sollte aber kein Problem sein, weil nur Director vs. Storage versionsgebunden sind. Director vs. Client sind versionsunabhängig. Ein Director kann viele verschiedene Clients mit sehr unterschiedlichen Versionen sichern.
  • Vorsichtshalber habe ich den File-Daemon deinstalliert und Pakete aus anderen Distributionen (Ubuntu 16, die Version, aus der mein Director ist und Ubuntu 14, eine Version, die andere Clients von mir haben) probiert. In den Package-Beschreibungen sieht man aber, dass Bareos auch für das alte Ubuntu 14 eine Version 18.x im bareos-filedaemon-Package hat.

Debugging

Jetzt kommt der schwierige Part. Mögliche Fehlerursachen sind ausgeschlossen. Google hat auch keine weiteren Vorschläge mehr. Was nun?!

Zum Glück ist Bareos freie Software, d. h. der Quellcode ist frei verfügbar und die Entwickler haben Möglichkeiten vorgesehen, Fehler trotzdem zu finden :-) Zuerst stoppen wir auf dem Client den Bareos-File-Daemon. Danach starten wir den Daemon manuell und setzen dabei zusätzliche Flags, um Debug-Ausgaben zu aktivieren.

root@gitlab:~# service bareos-fd stop
root@gitlab:~# /usr/sbin/bareos-fd -f -m -d 200

Der Daemon startet und wir sehen mehrere Zeilen Ausgabe, wie der Daemon seine Konfiguration einliest, nach Plugins sucht und schließlich ein Socket aufmacht und auf Verbindungen wartet. Auf dem Director fragen wir im Anschluss nach dem Status des Clients. Jetzt können wir auf der Konsole des Clients die interessanten Log-Zeilen ablesen:

gitlab-fd (100): /lib/bsock.cc:81-0 Construct BareosSocket
gitlab-fd (100): /lib/bsock.cc:633-0 Identified from Bareos handshake: bareos-dir-R_DIRECTOR version not recognized
gitlab-fd (100): /lib/try_tls_handshake_as_a_server.cc:69-0 Connection to bareos-dir will be denied due to configuration mismatch
gitlab-fd (100): /lib/bsock.cc:129-0 Destruct BareosSocket

• 

Diese Zeilen geben uns die nötigen Infos :-) Zuerst die gute Nachricht, dass die Verbindung vom Director beim Client ankommt, also kein Netzwerkproblem vorliegt. In der zweiten Zeile sehen wir, dass es doch etwas mit der Version zu tun hat. Drum funktionieren alle meine alten Clients, aber der neue nicht mehr. Die Frage war an dieser Stelle nur, was ich tun kann, da doch in den offiziellen Paket-Quellen jetzt überall diese neue Client-Version enthalten ist.

Mit den neuen Erkenntnissen konnte ich nun nochmal Google befragen und auch die entsprechenden Quelldateien von Bareos lesen. Bareos ist auf GitHub gehostet. Der File-Daemon ist zusammen mit allen anderen Daemons im core-Verzeichnis zu finden. Die relevanten Quellcode-Stellen verweisen dann auf das lib-Verzeichnis, was wir schon in der Ausgabe sehen.

• 

Jetzt kommt der interessante Part: Die Log-Meldung "will be denied due to configuration mismatch" hat doch etwas mit TLS zu tun, obwohl ich es gar nicht aktiviert hatte. Wir sehen in der Datei try_tls_handshake_as_a_server.cc in der Zeile 71 (die Zeilennummern variieren natürlich etwas zwischen aktuellem Stand, master-Branch und meiner Version aus der Distribution), dass die Variable tls_policy eben nicht kBnetTlsNone ist bei mir. Mein Client erwartet eine TLS-Verbindung zum Director!

Diese Erkenntnis habe ich kurz mit Google verifiziert. Für Version 18 findet man viele Hinweise, dass Bareos etwas bei der Verschlüsselung gemacht hat. Auf die Schnelle habe ich keine Hinweise gefunden, dass TLS zum Default wurde, aber ich kann es mir denken.

Lösung

Nachdem nun klar ist, was das Problem ist, ist die Lösung trivial.

Mit Strg+C halte ich meinen manuellen File-Daemon wieder an. In der Konfiguration auf dem Client trage ich in den Director-Abschnitt ein TLS Enable = no ein, starte den Daemon mit service bareos-fd start regulär und probiere die Verbindung erneut. Nun klappt es! :-D

---

Wenn euch dieser Artikel geholfen hat, hinterlasst gerne einen Kommentar.