Hallo,
wer kann mir helfen, mein Passwort und username für mqtt in die Secret.yaml auszulagern. Da diese Zugangsdaten ja bei einigen Sachen eingetragen werden muss, ist es einfacher es über die Secret.yaml zu machen.
Bekomme es aber irgendwie nicht hin.
Was sind bei Dir denn “einige Sachen”? Wenn es um die Zugangsdaten zu dem MQTT Broker geht kannst Du diese nicht in die secret.yaml auslagern, da diese bei Geräten und z.B. Addons immer an unterschiedlichen Orten eingetragen werden. D.h. die auslagern kannst Du therotisch schon, nur macht es nicht wirklich Sonn.
VG Jim
Das wäre auch meinen Frage gewesen.
In den Addon’s direkt kannst Du nicht auf die secrets.yaml zugreifen.
Selbst die ZigBee2MQTT configuration.yaml kann nichts mit der secrets.yaml anfangen.
Gruß
Osorkon
Weil es hier gerade passt und unabhängig von der Frage von @thphilipp, nur mal eine Anmerkung zu dem Thema secret.yaml. Viele HA Einsteiger stolpern irgendwann über den Begriff und die Datei secret.yaml. Oftmals wird das dann, weil “secret” ja für “Geheimnis” und somit “geheim” steht, mit dem Thema Sicherheit asozialisiert, sprich das man eine Secret.yaml braucht und/oder benutzen sollte, um ggf. die Sicherheit des Systems zu erhöhen. Eine Secret.yaml hat nichts mit dem Thema Sicherheit zu tun und die Sicherheit von HA wird dadurch um kein Stück erhöht!
Eine Secret.yaml Datei ist nichts anderes wie jede andere *.yaml Datei in die man irgendwelche Daten hin auslagern kann. D.h. man fasst in solchen Dateien nur irgendwelche Dinge zusammen (im Fall der Secret.yaml halt Zugangsdaten), um dadurch anderen Dateien (die configuration.yaml) nicht so aufzublähen und die Konfigurationen etwas übersichtlicher zu gestalten. Man könnte statt Secret.yaml auch eine Datei mit z.B. dem Namen “MeinegeheimenDaten.yaml” benutzen und darin seine Zugangsdaten abspeichern. Das wäre genauso sicher oder unsicher wie die Secret.yaml.
HA hinkt in Sachern Sicherheit leider bis heute immer noch hinterher und bis heute ist es so das Zugangsdaten (Namen und Passwörter) bei HA unverschlüsselt in Konfigurationsdateien vorhanden sind. Das betrifft nicht nur einzelne bei HA eingerichtete Geräte sondern alle Geräte und Dienste die bei HA eingerichtet sind, oder auch z.T. mal eingerichtet waren. Wer also z.B. seinen Router, sein NAS, irgendwelche Kameras, oder Cloud-Zugangsdaten usw. bei HA eingebunden hat oder hatte und dafür die normalen HA Funktionen und Integrationen benutzt hat, kann und sollte davon ausgehen das seine Zugangsdaten unverschlüsselt bei HA abgespeichert sind und wurden. Anders sieht das z.B. bei manchen Addons aus, sprich teilweise werden dort die Zugangsdaten durch das Addon verschlüsselt. Auch gibt es natürlich auch Dienste die per 2FA eingebunden sind/wurden, sodass auch dafür nicht unbedingt unverschlüsselte Zugangsdaten bei HA vorhanden sind.
D.h. jeder der auf HA Zugriff hat oder bekommt hat somit auch gleichzeitig Zugriff auf alle Benutzerdaten von allen Geräten die bei HA einrichtet sind oder waren und diese Daten sind unverschlüsselt bei HA gespeichert. Ausnahmen siehe Absatz vorher. Das gilt natürlich auch für irgendwelche “bösen Mädels und Jungs” 
sofern das HA System ggf. kompromittiert wurde. Auch diese haben dann direkten Zugriff auf diese unverschlüsselten Daten. Da hilft auch eine/die Secret.yaml kein Stück. 
Da dies ja eh schon lange ein offenes Geheimnis ist: Wer mal sehen möchte was HA da so alles wie speichert, sollte einfach mal einen Blick auf die mit core. beginnenden Daten unter homeassistant/.storage/ werfen.
Mal angenommen man hat sein NAS bei HA eingebunden findet man dort in einer config dann z.B. alles was man braucht um auf das NAS zugreifen zu können.
{
"entry_id": "a10e36c4b13ea1d43469de3925b977f0",
"version": 1,
"minor_version": 1,
"domain": "synology_dsm",
"title": "DS720",
"data": {
"host": "192.168.178.120",
"port": "5001",
"ssl": true,
"verify_ssl": false,
"username": "Hier steht der Username für den NAS Zugang unverschlüsselt",
"password": "Hier steht das Passwort für den NAS Zugang unverschlüsselt",
"mac": [
"90-09-D0-41-51-A1",
"90-09-D0-41-51-A1"
Anm.: Nein das sind jetzt keine Realdaten von meinem NAS. 
Daher secrect.yaml um es etwas übersichtlicher gestalten zu können und nicht um etwas ggf. sicherer zu machen.
VG Jim
Nichts anders steht ja auch in der offiziellen Dokumention. Die secrets.yaml dient nur dazu die Zugangsdaten an einer Zentralen Stelle zu verwalten. Und soll das teilen von yaml configuration erleichtern, ohne jedesmal die Passwörter löschen zu müssen.
Deshalb, hat man zu einem die Möglichkeit die Backups zu verschlüsseln. Und schickt diese hoffentlich nicht unverschlüsselt zu Google, oder wo auch immer manch einer die Backups hin schiebt.
Der Zugang zu Home Assistant ist hoffentlich auch mit 2FA versehen. Und der SSH Zugang deaktiviert, oder zumindest über ein key gesichert.
Und samba Share mit einem sicheren Passwort gesichert.
Gruß
Osorkon
Die sich vermutlich so gut wie kein User (extra) anschaut wenn er in irgendwelchen Anleitungen und/oder Diskussionen das Thema secrets.yaml liest oder aufschnappt.
Auch heute noch gibt es jede Menge Anleitungen auf Webseiten und/oder Diskussionen in irgendwelchen Foren, die suggerieren und/oder auch sogar (steif und fest) behaupten, dass die Benutzung einer secrets.yaml die Sicherheit bei HA erhöhen würde.
Außerdem meine ich zumindest das man nicht oft genug auf diesen Umstand hinweisen kann, einfach auch um User mal ggf. dazu zu bringen darüber nachzudenken und ggf. ein wenig zu sensibilisieren, was sie alles so in HA einbinden und ob es unter den Umständen ggf. wirklich eine gute Idee ist z.B. sein NAS, auf dem sich ggf. auch sensible Daten befinden, bei HA mit einzubinden und im schlimmsten Fall dann auch noch und weil es ja so schön bequem ist, mit einem User-Account bei dem NAS der Admin-Rechte hat. 
Also ja, man kann in der HA Doku auch etwas zu secrets.yaml lesen und schön das Du darauf (zusätzlich) hinweist, aber ob die User und gerade HA Einsteiger, das dann auch tatsächlich lesen, oder einfach eine secrets.yaml erstellen weil sie das mal irgendwo so aufgeschnappt haben und meinen das alles was darin steht ja dann “geheim” wäre, bleibt m.M.n. durchaus fraglich.
VG Jim
OT an:
Das scheint eine art Krankheit zu sein.
Erst Doku Lesen und dann erst Fragen stellen. Scheint aus der Mode gekommen zu sein?!
Dabei hat Home Assistant eine vorbildliche Dokumentation.
Da verlässt man sich dann lieber auf die vermeintlichen Experten, die mit gefährlichen Halbwissen um sich werfen.
OT aus:
Gruß
Osorkon
OT
Nein am liebsten würde man heutzutage einen komplett fertig, sofort funktionierenden Code für sein System geliefert bekommen. Dann brauch man nix mehr lernen bzw lesen! Ein Hoch auf das Smartphone!
Der Beitrag klingt irgendwie, als wäre es möglich, dass HA die Daten auch komplett verschlüsselt speichern kann und man selbst mit Vollzugriff auf das System in diesem Fall keine Möglichkeit hätte die Daten zu entschlüsseln.
Nur ist dies eben technisch nicht möglich. Das System muss ja die gespeicherten Passwörter wieder in Klartext auslesen / entschlüsseln können, um diese an die Dienste bei denen es sich anmeldet zu liefern.
Also muss das System irgendwo den Code zum entschlüsseln liegen haben.
Nun soll das System ja ohne Zugriff oder extra Eingaben von Passwörtern funktionieren. Also müsste diese Möglichkeit zur Entschlüsselung irgendwo auf dem System offen liegen.
Und damit kann man, wenn man Zugriff auf das System hat, in jedem Fall diese Daten auslesen. Egal ob verschlüsselt oder nicht.
Wenn man als Dienst, bei dem sich angemeldet wird, Passwörter verschlüsselt, läuft dies zumeist eher über Hashwerte. Das funktioniert one-way, weil immer wieder die selben Werte heraus kommen, wenn man das selbe eingibt. Aber in diesem Fall wird ja von außen noch mal ein Passwort eingegeben. Und genau dieser Schritt würde bei HA immer fehlen.
Die Zugangsdaten von angelegten HA Benutzern zum Beispiel kann man nicht einfach im Klartext auslesen, oder?
Da muss zur Anmeldung ja aber auch das Passwort eingegeben werden.
Also ich bin kein Entwickler und habe mich auch noch nie mit dem Thema befasst wie man irgendwelche Zugänge ggf. “hacken” könnte. Aber ich gehe davon aus das die PW um sich bei HA als User einloggen zu können verschlüsselt sind. Die bei und für HA selber angelegten User und deren User-Name und ID, ist in Klarschrift in den configs gespeichert.
Mir ging es hier auch weniger darum ob und was wie verschlüsselt ist, sondern:
a) Um das Thema secrets.yaml und das User denken könnten das dadurch die Sicherheit erhöht wird.
b) Darauf hinzuweisen das Zugangsdaten zu fast allen bei HA eingebundenen Geräten und Diensten unter HA unverschlüsselt gespeichert werden und das das eine potentielle Gefahr beinhaltet. D.h. wenn jemand - wer auch immer das dann sein sollte - Zugang zu HA hat, hat er auch gleichzeitig Zugang zu fast allen Geräten und Diensten die bei HA eingebunden sind bzw. wurden, eben weil er dann ganz einfach die Userdaten zu diesen Geräten und Diensten über die HA Configs. bekommt, bzw. bekommen kann.
Ich will das weder bewerten noch kann ich beurteilen wie “normal” so etwas ggf. ist. Das kann und muss jeder für sich selber machen.
VG Jim
Richtig. Jemand der Zugang zu HA hat, hat Zugriff auf alles was dort eingebunden ist. Korrekter Weise wäre dies, wenn die Daten noch einmal verschlüsselt wären, auch nichts anderes.
Wenn HA Zugriff hat, haben die Personen, die vollen Zugriff auf HA haben eben vollen Zugriff. Genau das ist ja Sinn der Hausautomatisierung
Die Diskussion ist so sinnig, wie zum Beispiel bei einer Schließanlage.
Wenn ich einen Generalhauptschlüssel habe, kann ich damit alle Türen öffnen. Und wenn dann eine andere Person diesen Schlüssel bekommt, kann diese Person alle Türen öffnen. 
Der Vergleich mit dem Generalhauptschlüssel hinkt ein wenig. 
Die HA-Login-Daten lassen sich nicht als Login-Daten für andere Geräte benutzen, somit sind diese kein “Generalhauptschlüssel”. Um bei dem Beispiel Schlüssel zu bleiben: Du hast mit den HA-Login-Daten nur den Schlüssel für einen Schlüsselkasten in dem dann die ganzen Schlüssel für alle möglichen anderen Türen hängen. Mit diesen Schlüsseln kannst Du dann alle möglichen anderen Türen aufschließen.
Ähm doch. 
Wenn die Daten für die anderen Geräte und Dienste unter HA nicht in Klarschrift gespeichert werden sondern verschlüsselt, müssten diese erst wieder entschlüsselt werden wenn ich mich damit bei einem anderen Gerät oder Dienst anmelden wollte. Mit den verschlüsselten Daten allein könnte ich mich nicht bei dem Gerät oder Dienst anmelden.
Ja Du hast Recht wenn der Zugriff auf die anderen Geräte und Dienste über HA selber erfolgt, bzw. erfolgen würde, dann müsste und würde HA die verschlüsselten Daten wieder so entschlüsseln und dann an das Gerät oder den Dienst übergeben, sodass sie dort dann auch funktionieren.
Oder anders gefragt: Warum gibt es denn auch unter HA einzeln Geräte und Dienste für die deren Zugangsdaten (Username und PW) eben nicht in Klarschrift sondern verschlüsselt gespeichert sind und werden? Das wäre dann ja ebenfalls überflüssig und sinnlos.
BTW: Es geht auch nicht unbedingt nur darum das Leute die Vollzugriff auf HA haben dann Zugriff auf die Login-Daten für fast alle bei HA eingebundenen Geräte und Dienste haben, sondern auch darum das jemand von außen, der z.B. durch eine evtl. mal auftretende Sicherheitslücke bei HA, Zugriff auf den /.storage Ordner hat/bekommt, somit über die Config-Dateien dort alle Zugangsdaten (unverschlüsselte Usernamen und PW) für die unter HA eingebundenen Geräte und Dienste bekommt.
Wie gesagt bin ich kein Entwickler und ich weiß nicht wie sich Verschlüsselungen von Zugangsdaten einbinden und nutzen lassen, oder eben vielleicht auch nicht. Das es aber durchaus möglich ist zeigen ja die Beispiele unter HA bei denen die Zugangsdaten für einzelne Geräten und Diensten verschlüsselt und eben nicht in Klarschrift gespeichert werden. D.h. selbst von jemand es dann gelingen sollte Zugriff auf die Config.-Datein unter dem /.storage Ordner zu bekommen, kann er mit diesen verschlüsselten Daten m.M.n. nichts anfangen.
Aber wie auch schon gesagt geht es mir hier eher um die Punkte a) und b) die ich oben genannte hatte und weniger um eine Grundsatzdiskussion wie sicher HA ggf. ist und/oder wie und ob sich irgendwelche Verschlüsselungen nutzen lassen, oder ggf. auch nicht. Daher klinke ich mich hier jetzt mal aus.
VG Jim
Stimmt. Es wäre eher ein Schlüsselkasten in dem sämtliche Schlüssel hängen…
Welche genau wären das? Dinge wie Login Daten? Weil es da technisch möglich ist, vielleicht?
Das ist der Punkt. Es ist keine Diskussion auf Fakten sondern eher Gefühlen.
HA gehört zu den Top 10 der aktivsten Open Source Projekte der Welt. Vor einigen Monaten gab es ein Security Audit, dass auch noch einmal bestätigt hat, dass die Software sicher ist. (Security audits of Home Assistant - Home Assistant)
No authentication bypass issues have been found.
Hier also zu postulieren, dass es evtl. mal eine Sicherheitslücke geben könnte, über die dann auf die Zugangsdaten zugegriffen werden kann. Und gleichzeitig das Gefühl zu erwecken als könnte man mit Verschlüsselung dieses Geschehnis verhindern. Das ist haltlose Angstmacherei.
Aber ausgehend davon, dass kein System zu 100% sicher ist. Wenn ein Angreifer eine Lücke in HA ausnutzen wollte. Welche Möglichkeiten hätte er? Die übers Internet, richtig?
Einmal gibt es die Möglichkeit über die Nabu Casa Cloud. Da besteht aber die erste Problematik bereits darin ein HA zu finden, aufgrund der kryptischen URI. Und da bin ich dann nicht einmal sicher, ob diese direkt auf die HA Instanz verweist bzw. bin der Meinung, dass dies nicht der Fall ist. (Es wird ja auch ohne Portforwarding gearbeitet.)
Dann hätte der Angreifer also Daten für Geräte in einem lokalen Netzwerk, von dem er dann noch nicht einmal weiß, wo auf der Welt sich dieses befindet. Dass er von außen vermutlich nicht einmal darauf zugreifen kann, mal ganz abgesehen.
Und evtl. hat der dann nen API Schlüssel zu online Diensten wie einem Wetterdienst. (Also bis man den API Schlüssel sperrt.)
Jetzt irgendwie nicht so richtig erfolgversprechend, oder?
Dann gibt es Dinge wie die Cloudflare Tunnel. Das selbe in grün, da Cloudflare eben auch die Server Standorte zu verbergen versucht.
Die nächste Möglichkeit ist, dass man ein Port Forwarding im Router eingerichtet hat. Dann kann man ebenfalls auf die Login Maske zugreifen und kennt sogar die IP. 
Ändert am Rest der Umstände aber nichts, wenn andere Dienste nicht ebenfalls ins Internet exposed sind. Wenn doch, wären eben nur diese Dienste erreichbar.
Dass jemand von außen nur auf die Dateiebene o.ä. zugreifen kann, wäre technisch nicht möglich, da dieser Port / Dienst ja gar nicht über das Internet erreichbar ist.
Die Möglichkeit, dass jemand direkt auf das Gerät zugreifen kann hat also die Voraussetzung, dass diese Person Zugriff auf Dein privates Netzwerk oder physikalischen Zugriff auf das Gerät selbst hat.
Ist jemand unbefugtes in Deinem lokalen Netzwerk, hast Du ein ernsthaftes Problem. Diese Person deswegen aber noch keinen Zugriff auf HA. Dafür braucht es ja die postulierte Lücke zusätzlich.
Ist jemand unbefugtes in Deiner Wohnung und hat physikalischen Zugriff auf das Gerät, braucht es weiterhin die postulierte Lücke. Dein Problem ist nur deutlich größer.
Denn wozu brauche ich noch Zugangsdaten, wenn ich vor Ort auf die Geräte selbst zugreifen kann? Da kann ich das Gerät selbst nehmen, ersetzen oder sonst was tun.
In welchem Szenario wäre eine mögliche Lücke also ein (weitergehendes) Problem? Und wie viel muss vorher bereits falsch gelaufen sein?
Da ist es doch deutlich wahrscheinlicher, dass man überall die gleichen Passwörter verwendet und darüber Zugangsdaten bekannt werden. haveibeenpwned.com lässt grüßen.
Außerdem sollte man dann eher überlegen, was man sind alles für Geräte mit China Cloud und Co ins Netzwerk hängt und diesen den Internetzugriff ermöglicht und was diese Geräte (potenziell) für Daten abgreifen und weiterleiten können.
Daher setze HA ja auf lokale Verfügbarkeit und Sicherheit.
In meinem Netzwerk habe ich übrigens die Netze voneinander getrennt. IoT Geräte können weder auf mein Netzwerk noch das Internet zugreifen. Reine Cloud Geräte kommen grundsätzlich nicht zum Einsatz. Die einzige Schnittstelle ist HA.
Und auch dies ist aus dem Netzwerk nur auf dem Port 443 erreichbar. Also 8123 in einer Standard Installation. Aber ich nutze ein Let‘s Encrypt Zertifikat und mich nervte der Port am Ende der Domain. In meinem Fall ha.hates.social
Und wer jetzt versucht die Domain aufzulösen wird feststellen, dass die IP dahinter 172.23.107.2 ist. Also ein privates Netzwerk, das von außen gar nicht erreichbar ist.
Der externe Zugriff ist bei mir über eine Wireguard VPN ermöglicht, über welche ich von außerhalb in mein Netzwerk komme, um dann auf mein HA (und andere Dienste) zuzugreifen.
Ich könnte hier also auch die Zugangsdaten zu meiner Home Assistant Instanz und sogar die (feste) IP Adresse posten. Ein Zugriff wäre ohne VPN Zugang ins Netzwerk oder lokalen Zugriff auf selbiges nicht möglich.
Wie hoch wäre dann also die Gefahr einer Sicherheitslücke? 
Wohl gemerkt hat HA die Möglichkeit sowohl meine Haus- als auch meine Wohnungstüre zu öffnen.
Wäre ein unbefugter Zugriff auf HA möglich, könnte man damit also meine Wohnung öffnen und betreten. Vollkommen egal, ob die Zugangsdaten zu den Shelly die dort verbaut sind im Klartext oder verschlüsselt gespeichert sind.
Um nochmal die Frage bzw. das Thema zuzufassen.
Die secret.yaml hat 2 “Vorteile”:
Zentrale Verwaltung der Zugangsdaten. Also wenn man welche ändert, weiß man wo man das entsprechend in HA anpassen kann. Denn die größte Hürde ist doch, dass man/ich eigentlich die Zugangsdaten nie ändert, weil man/ich den Überblick “verloren” hat, wo überall (App, Hardware usw.) man die schon eingetragen hat.
Man nicht aus Versehen seine Zugangsdaten irgendwo postet, wenn man seine configuration.yaml o.ä. veröffentlicht.
ein alter Post, aber ich beschäftige mich heute erst mit der secrets.yaml in meinem System.
und die ist bisher noch leer:
# Use this file to store secrets like usernames and passwords.
# Learn more at https://www.home-assistant.io/docs/configuration/secrets/
some_password: welcome
jetzt sieht man in einigen codes zB bei ESPHome ja meist so etwas am Anfang:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
das habe ich dann immer durch meine persönlichen Daten ersetzt, ist auf Dauer etwas umständlich vor allem wenn man den code öffentlich teilen will.
Hat sich an der Kernfrage MQTT in der screts.yaml irgend etwas geändert oder geht das immer noch nicht?