39_alexa.pm und alexa-fhem test version

[Loredo]

der fhem port wird doch automatisch aus deinem laufendem fhem ausgelesen.

falls das aus irgendeinem grund nicht passt editierst du das config file per edit files oder von hand und sagst ein mal start.

Allerdings wird der Port auch unter bestimmten Umständen wieder überschrieben, das hatte ich einige Male.
Bin nicht sicher wann genau, wahrscheinlich war es aber, wenn ich das alexa Device gelöscht und neu angelegt habe, dass das existierende File überschrieben statt recycled wurde.

[Loki]

Meine Instanz läuft über 2 Ports. Einer für ein lokalen Zugriff ohne Login und ein anderer für den externen Zugriff mit Login und eingeschränkten Rechten. Bei der Installation wurde der zweite Port in die conf übernommen.

Das Verhalten von Loredo kann ich bestätigen.

[justme1968]

das überschreiben des ports ist inzwischen behoben.

wenn es schon ein config gibt wird dieses inzwischen auch nicht mehr ersetzt. auch beim neu anlegen des alexa devices nicht.

wenn es hier immer noch probleme gibt: bitte melden. am besten auch wie es zu reproduzieren ist.

wenn es mehr als ein web device gibt wird WEB bzw. das erste genommen. das lässt sich in der tat nur mit sehr viel aufwand intelligenter machen. ich denke dieser aufwand wäre aktuell besser anders investiert.

immer dran denken: der default muss und soll für ,nur anwender' sein.

alle die mehr wollen oder speziellere anforderungen haben sollen diese trozdem umsetzen können. aber ohne das es für erstere komplizierter wird.

[Loki]

Ok, dem stimme ich zu!   

[gvzdus]

Guten Morgen,

es gab einen Programmierfehler, weswegen ich Accounts löschen musste. Hintergrund sind die Esjay-Probleme.
Inzwischen ist ein Patch auf dem SSH-Proxy eingespielt und die betroffenen Accounts gelöscht.

Mal die Enduser-Kurzfassung: <UserIDs> (Teil 1 des Reg.-Schlüssels) wurden doppelt vergeben.
Dadurch ist die Zuordnung nicht eindeutig, und es landeten Zugriffe von Amazon im ,,falschen
Kanal" beim falschen User, wo sie dann wegen falschem Bearer-Token erkannt wurden.

Das ist für den Betroffenen, der die Kommandos erhält, natürlich kein Problem - nicht umsonst
hatte ich ja meine User-ID im Security-Thread geschrieben und herzlich dazu eingeladen,
,,auf meinem Raspberry" vorbeizukommen. Allerdings hatte ich dazu eingeladen, und wollte
nicht anderen ebenfalls ungewollt Requests senden. Und problematisch daran ist, dass ja
nicht Test-Requests ankommen, sondern Requests eines anderen. Das Problem sehe ich
also darin, dass Alexa-Requests an den falschen geschickt wurden, der sie in seinem
Logfile ab Version 0.5.8 sehen konnte.

Deswegen habe ich alle Registrierungen, die mit

Code Auswählen Erweitern

130E36-
131C16-
131CF4-
1336F8-
13B3D8-
141489-
beginnen, gelöscht.

Bevor ich ausführlich auf den Fehler eingehe und wir im Sicherheitsthread über die Konzeption
diskutieren können, kurz das Vorgehen zum Fixen:

Bei den Betroffenen sollte sich der SSH-Tunnel im Alexa-Device permanent neu starten.
Im Logfile müssten Meldungen wie ,,Your public key is not known, please register first"
erscheinen.

Vorgehen:

• In FHEM-WEB im Alexa-Device ,,restart" auswählen.
• Es wird ein neuer Reg.-Key generiert, mit einem jetzt verbesserten Verfahren
• Skill bei Amazon trennen, und den neu generierten Reg.-Key (,,get alexa proxyKey") eingeben.

Wie ist das passiert?
Das Folgende setzt das Verständnis von des Abschnitts ,,Sicherheitskonzepte" aus dem Wiki
voraus.
Hier findet sich schon der problematische Satz:

Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

Da hätte ich beim Schreiben von ,,6-stellig" misstrauisch werden sollen. Integer sind nun mal 8-stellig. Der HashCode des PublicKey-Objektes ist aber richtig schlecht.
Das muss man nicht Java vorwerfen - der HashCode beim Programmieren hat eine andere Funktion als die Hashes in der Sicherheitstechnik. Teil 1 des Fixes besteht darin,
für neu generierte Reg-Keys eine bessere Hash-Funktion zu verwenden (konkret: https://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html#hashCode(byte[])

Teil 2 des Fehlers ist ein falsches Handling bei Hash-Kollisionen, also wenn bei 2 Public-Keys der gleiche HashCode entsteht. Über den Fall hatte ich beim Programmieren nachgedacht, aber dann doch einen Fehler gemacht.
Wie es gedacht war: Die Registrierung sollte abgelehnt werden. Der 2. hat halt Pech. Ist ohnehin ein Fall, der ausgehend von 32 bit, beim 10.000ten Nutzer mit einer Wahrscheinlichkeit von ca. 1:430.000 auftritt, beim 100. Nutzer mit noch 2 Nullen mehr dran. Bis dahin muss dann was Besseres her.

Tatsächlich habe ich die Funktion bei ,,ssh ... status" (Wie es beim Neustart von alexa-fhem aufgerufen wird) sauber implementiert. Hier wurde auf HashCode / UserID *und* vollständigen PublicKey geprüft. Falsch hingegen ist es beim ,,register" gewesen: Hier wurde einfach der PublicKey gespeichert.

Was bedeutete das konkret?
Benutzer 1 und Benutzer 2 hatten den gleichen HashCode, aus Systemsicht die gleiche UID. Beim Neustart wurde demjenigen, der sich als vorletzter registriert hatte, angezeigt: ,,Du bist nicht registriert". Also wurde ein neuer Registrierungskey generiert, aber wieder auf Basis des gleichen PublicKeys, also mit der gleichen UID im ersten Teil. Damit machte sich dann der Vorletzte wieder zum ersten. Bei Amazon existierten nun zwei Beamer-Tokens: <gemeinsame-uid>-<bearertoken1> und <gemeinsame-uid>-<bearertoken2>. Aus Amazons Sicht natürlich kein Problem: Einfach zwei unterschiedliche Strings. Aus Sicht des SSH-Proxies durchaus ein Problem, weil er ja nun für 2 Nutzer auf die gemeinsame UID guckt, und die Anfragen an den Nutzer schickt, der sich zuletzt verbunden hat.

Wie ist es jetzt behoben?
Erstens durch eine Hashfunktion, die den ganzen 32-Bit-Raum ausnutzt. Simulationsläufe zeigen, dass typischerweise 1 Kollision auf 100.000 Nutzer auftritt.
Zweitens: Wird beim Registrieren eine Kollision erkannt, wird einfach die nächst höhere Nummer vergeben (sofern frei). Und bei jedem Aufbau der SSH-Verbindung, ob ,,-R", ,,register" oder ,,status", wird stets der vollständige PublicKey verifiziert. Die Nummer ist nach Konzeption ja kein großes Geheimnis, sondern muss nur eindeutig sein.

Wie weiter?
Erst einmal ist das Verfahren damit wieder so, wie es sich aus der Beschreibung liest, und mit einem sauberen Kollisionshandling. Über das Verfahren kann man aber trotzdem diskutieren. Mein Anspruch war nicht, dass die vergebene UID für sich ein Geheimnis ist. Ist wie beim Usernamen: Jeder weiß, mit welchem Usernamen ich mich hier im Forum anmelde, nur mein Passwort kennt keiner.

Noch eine Bitte: Lasst uns bitte die Konzeption im Sicherheitsthread diskutieren, die ,,Benutzerführung" und Tomatenwürfe in einem der beiden anderen Threads.

Natürlich möchte ich mich an dieser Stelle für den Programmier- und Hash-Anwendungsfehler bei den betroffenen Nutzern entschuldigen! Und bei Esjay für die professionelle Vorgehensweise (Hinweis, Zeit für's Beheben geben) bedanken!

Ablauf war übrigens:

• Seit gestern, 22:12 Uhr, wurden neue Reg-Schlüssel mit dem guten Verfahren generiert
• Um 10:40 Uhr habe ich alle o.a. Reg-Keys gelöscht, und den Server restartet, um die bestehenden Verbindungen zu trennen

[Loredo]

Meine Instanz läuft über 2 Ports. Einer für ein lokalen Zugriff ohne Login und ein anderer für den externen Zugriff mit Login und eingeschränkten Rechten. Bei der Installation wurde der zweite Port in die conf übernommen.

Ähnlich hier. Meine Schlussfolgerung/Konsequenz wird nun sein, dass ich die FHEMWEB Default Instanz "WEB" auf Port 8083 nicht mehr als eingeschränkte Instanz konfiguriere, sondern den Spieß umdrehe, so dass diese Instanz möglichst nah am Default bleibt (auch der webname). Für den eingeschränkten Non-Admin-User-Zugriff gibts dann eine neue Instanz. Dann gibt es einfach weniger Probleme mit Modulen und auch der automatischen Erkennung wie jetzt bei alexa-fhem.

[eisman]

hi,

weis nicht ob es hier richtig ist, Alexa läuft immer noch

meine frage, kann man fhemIntents nutzen und wenn ja wie,
ich habe fast alle gelesenen, aber keine Antwort gefunden die auch funktioniert....

danke

gruss

[justme1968]

FHEM Connector ist nur für das smart home api


alles andere musst du erst mal wie bisher über einen eigenen custom skill machen.

du kannst aber die gleiche alexa-fhem instanz verwenden

[eisman]

hi, dankeschön
gruss

[justme1968]

@det.: die auth daten werden nur noch bei verbose im device im klartext ins log geschrieben.

[balli1187]

Da es nun etwas ruhig hier geworden ist und meine Fragen eventuell übersehen wurde, hol ich das nochmal hoch:

Moin,
Ich habe gestern von einer recht alten Version (0.4.4) auf diese neue Version geupdated. Alles läuft aktuell und funktioniert. HERZLICHEN DANK an die Entwickler.

Dennoch zwei Fragen:
- wie wäre das richtige Vorgehen, wenn ich von meinem eigenen (Entwickler)Skill auf den offiziellen Skill wechseln möchte? Würde was dagegen sprechen?
- das attr room lässt sich für das log nicht setzen. Soweit ich gelesen hab, ist das mehr oder weniger beabsichtigt. Ließe sich das ändern? Meine ordnungszwang hat was gegen das ,,unsorted"

Gesendet von iPhone mit Tapatalk

[justme1968]

das log device ist ab morgen in keinem raum mehr

[balli1187]

Ok.

Wie steht es um die andere Frage bezüglich des Skill-Wechsels


Gesendet von iPhone mit Tapatalk

[sTaN]

Hallo Zusammen,

mal wieder ein positives Feedback!
Habe soeben folgende Schritte ausgeführt:

1. Update FHEM
2. Alexa-Fhem gestoppt

Code Auswählen Erweitern

set alexa stop
3. alexa-fhem auf meinem RPi von Version 0.5.7 auf die 0.5.9 aktualisiert

Code Auswählen Erweitern

sudo npm update -g alexa-fhem
4. shutdown restart von fhem
5. RegKey geprüft und war identisch mit dem vor dem Update

Icon meines Alexa Devices blieb ebenso erhalten (zuvor waren sämtliche manuell gesetzten Attribute wie room und group sowie das Device icon verschwunden)
Der Connect klappte auch ohne Probleme, sowie die Geräte Steuerung!

Bisher bin ich sehr zufrieden Jungs!!! DANKE!

[gvzdus]

@balli1187: Der Vorteil des Entwickler-Skills ist, dass Du an allen Ecken basteln kannst wie Du möchtest. Und, dass Du Dir theoretisch eine sicherere Lösung schaffen kannst, ohne Dritte wie den Verein, Andre & mich ins Spiel zu bringen.

Den Vorteil der FHEM-Connector-Lösung sehe ich darin:
- Keine Gedanken mehr über den offenen Port
- Flotter, weil typischerweise die Lambda-Funktion "noch da ist" (sogenannte Cold-Start-Thematik) und die Authentifizierung nur in eine Richtung verläuft
- "Politisches Gewicht" ggü. Amazon