Ankündigung

Einklappen
Keine Ankündigung bisher.

Amazon Alexa Plugin

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    schuma
    ich gehe davon aus

    Zitat von schuma Beitrag anzeigen
    Jetzt habe ich in der Datei nginx/.alexa mein Passwort und Benutzername aus der Lambdafunktion eingefügt.
    hast du so gemacht ?

    Code:
    sudo htpasswd -c /etc/nginx/.alexa <username>
    Desweiteren muss bei der Lambda-Funktion der Port deines Nginx stehen (der Port der auf SSL hört).
    In der Nginx Config muss Du dann auf den Port der in der plugin.yaml steht routen.
    Code:
    # Alexa Plugin Weiterleitung
    location /alexa {
    auth_basic "Restricted Area: Alexa";
    auth_basic_user_file /etc/nginx/.alexa;
    
    # Zugreifendes Land erlaubt?
    if ($allowed_country = no) {
    return 403;
    }
    
    proxy_pass http://<SmartHomeNG LAN IP>:<Alexa Plugin Port>/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    }
    wobei
    Code:
    <SmartHomeNG LAN IP>  = 127.0.0.1
    sein kann wenn der Ngix auf Deiner ShNG-Maschine läuft.
    Code:
    <Alexa Plugin Port>            =  Port aus der plugin.yaml von shNG
    Nachtrag : Amazon will SSL - Zertifikat ist also ein MUSS
    Die aktuelle Config aus dem Image kenne ich nicht, es muss aber so sein, wie ich dem Verlauf entnehme, dass
    "alexa" als IP:Port irgendwo zu Beginn der config definiert wird. Also dort ändern und nicht bei der eigentlichen Location
    Ich will hier keine Verwirrung stiften


    Gruss Andre
    Zuletzt geändert von AndreK; 19.01.2020, 17:30. Grund: Nachtrag zum Thema Zertifikat

    Kommentar


      Ich denke in dem Image von Onkelandy ist ja schon einiges vorkonfiguriert. Ip und Port habe ich gefunden ist bei 9000.
      Passwort habe ich jetzt auch so gesetzt wie du gesagt hast (htpasswd).

      Ich habe auch mit setup_ all Zertifikate erstellen lassen und einen Revers Proxy eingerichtet. (Wobei ich hier absolut nicht verstehe was da vor sich geht,-( )

      Bei dem Lambda Test bekomme ich diese Fehlermeldung:

      Code:
      {
      "errorType": "Error",
      "errorMessage": "self signed certificate",
      "trace": [
      "Error: self signed certificate",
      " at TLSSocket.onConnectSecure (_tls_wrap.js:1321:34)",
      " at TLSSocket.emit (events.js:210:5)",
      " at TLSSocket._finishInit (_tls_wrap.js:794:8)",
      " at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:608:12)"
      ]
      }
      Muss ich nicht irgenwie der Lambda Funktion das Zertifikat mitteilen?

      Ich gebe für heute erstmal auf....

      Kommentar


        "errorMessage": "self signed certificate",
        Du brauchst ein öffentliches Zertifikat.
        Meine Installation: VM Debian Buster SH NG 1.8.1, SmartVISU 3.0, KNX, DMX, 1-wire, Fortigate 30E IPS, VMware vSphere 6.7

        Kommentar


          schuma

          Kurze Erklärung was passiert / passieren soll :

          - die Lambda will eine SSL-Verbindung, diese baut sie zu Deinem Nginx auf, dieser macht das SSL-Handling und stellt (hoffentlich) ein öffentliches Zertifikat zur Verfügung. ( das will Amazon so . (Punkt im Sinne von Punkt - da führt kein Weg dran vorbei)
          - der Nginx gibt die Nutzdaten via forwarding an das Plugin (Definition in der location der nginx-Config)
          - das Plugin verarbeitetet die Daten und gibt den Response via Nginx (das passiert automatisch da die Verbindung von Amazon via Nginx aufgebaut wurde) zurück

          schematisch :

          Code:
          amazon:<Port_aus_der_Lambda>  <=> Nginx-IN :<Port_aus_der_Lambda> <=> Nginx-OUT:<Port_aus_der_plugin.yaml> <=> plugin:<Port_aus_der_plugin.yaml>
          Die Erstellung eines offiziellen Let's encrypt Zertifikats, falls nicht vorhanden findest Du in der shNG-Doku wie oben verlinnkt.

          Ich denke das bringt etwas Licht ins Dunkel.

          Gruss Andre

          Kommentar


            Ok, vielen Dank euch Beiden!
            Das bringt wirklich etwas Licht ins dunkle.

            Ich versuche es morgen noch mal, mit der setup_all ein neues Zertifikat zu erstellen.

            Brauche ich denn überhaupt zwingend einen Reverse Proxy?
            Wenn Amazon mit dem Dyndns und Port die Verbindung aufbaut?
            Ich habe in der Fritte den Port 443 eh freigegeben...

            Kommentar


              Hallo schuma

              Zitat von schuma Beitrag anzeigen
              Brauche ich denn überhaupt zwingend einen Reverse Proxy?
              Wenn Amazon mit dem Dyndns und Port die Verbindung aufbaut?
              das würde schon gehen, aktuell kann man das Zertifikat auch direkt beim Alexa4P3 Plugin einbinden, ich kenne aber keinen der das so nutzt.
              Ob das funktioniert - kommt noch vom ursprünglichen Plugin - hab ich nie getestet. Würde aber auch davon Abstand nehmen. Die Kommunikation über den
              NGINX hat sich bewährt. Wenn Du das Zertifikat direkt im Plugin einbinden möchtest bekommst du noch mehr Trödel mit Berechtigungen usw.
              Ausserdem prüft das Plugin nicht auf User/PWD sondern stellt nur einen SSL-HTTP-Server zur Verfügung. Dort wird dann ohne Berechtigungsprüfung alles akzeptiert.
              Über den NGINX hast Du auch gleichzeitig noch ein Logging für Fehler und Zugriffe - find ich gut und wollte ich nicht missen.

              P.S. Ich nutze als Zugang zum NGINX ein abweichenden Port - nicht 443 - den wollte ich mir freihalten.

              Gruss Andre

              Kommentar


                Hallo schuma ,
                aus Sicherheitsgründen würde ich immer über einen Reverse Proxy gehen. Dieser gehört eigentlich auch auf einer eigenen Maschine in die DMZ. Das bekommts mit der Fritte aber nicht hin.

                Ich nutze für alexa auch einen anderen Port als tcp/443 .
                Man kann aber über tcp/443 auch mehrere Applikationen auf dem reverse proxy bringen. Der proxy entscheidet nach port und Hostname.

                PS. Um das SSL hardening mit ssllabs testen brauchst Du zwingen tcp/443. Ich will da immer ein A+

                Gruß
                Michael
                Zuletzt geändert von yachti; 19.01.2020, 19:14. Grund: Berichtigung
                Meine Installation: VM Debian Buster SH NG 1.8.1, SmartVISU 3.0, KNX, DMX, 1-wire, Fortigate 30E IPS, VMware vSphere 6.7

                Kommentar


                  Also ich bin jetzt kurz vor dem Aufgeben!!!

                  Beim Zertifikat erstellen muss man ja eine Domain angeben. Ich habe aber keine eigene Domain. Dadurch läuft das immer auf einen Fehler.
                  Was tragt Ihr hier ein?
                  Oder funktioniert das Zertifikat dann trotzdem?

                  Aktuell bekomme ich im Lamda folgende Fehlermeldung beim Test:
                  Code:
                  {
                  "errorType": "Error",
                  "errorMessage": "connect ECONNREFUSED xxx.xxx.xxx.xxx:9900",
                  "trace": [
                  "Error: connect ECONNREFUSED xxx.xxx.xxx.xxx:9900",
                  " at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1128:14)"
                  ]
                  }
                  Die IP passt und der Port auch.

                  Kommentar


                    Nahmd...

                    Nunja, Du benötigst eine Url, die mit fester IP oder über Dyndns aufgelöst wird.
                    Feste IP eher unwahrscheinlich, also Dyndns. Im Prinzip kannst Du dann die Url <name>.dyndns.org beantragen und für das Zertifikat verwenden.
                    Bei meinem dyndns Dienst war dann nur das Problem, dass letsencrypt für den zuviele Zertifikate generiert hatte und keine weiteren ausstellen wollte.
                    Also eine subdomain für meine eigene Domain erstellt und gut ist.
                    Versuch macht kluch und bei einem Smarthome darf auch mal ne eigene Domain abfallen.

                    Gruß Jürgen

                    Kommentar


                      Hallo schuma

                      wenn Du keine eigene Domain und feste IP Adresse hast mußt Du dynDNS dafür benutzen. Ohne Domain Name wird das mit dem öffentlichen Zertifikat nicht funktionieren.
                      Ich selber nutze kein dynDNS und kann daher keine Empfehlung für einen Anbieter nennen. Hier wird aber sicher jemand aus dem Forum weiterhelfen können.

                      Schönen Abend
                      Michael
                      Meine Installation: VM Debian Buster SH NG 1.8.1, SmartVISU 3.0, KNX, DMX, 1-wire, Fortigate 30E IPS, VMware vSphere 6.7

                      Kommentar


                        Ah, ich habe ja meinen myfritz Zugang.
                        Darüber läuft ja auch der dynDns.

                        Morgen letzter Versuch ;-)

                        Kommentar


                          Hallo schuma

                          ich würde empfehlen, so kurz vor dem Durchbruch, nicht aufzugeben. Ich nutze no-ip.com. Dort bekommst du kostenlos deine Dyn-Domain. Wenn diese regelmässig genutzt wird entfällt auch das bestätigen alle 30 Tage. Ich habe hier nur gute Erfahrungen gemacht.

                          Ich erinnere mich dunkel daran, das auch was mit myFritz was war, eventuell kann Cannon dazu noch was sagen. (Ist zu lange her, aber ich meine das hatte auch funktioniert - oh ich glaube doch nicht, man konnte dafür kein Zertifikat erstellen !?!)

                          Kurz zur Vorgehensweise mit einem DynDNS-Provider.

                          - DynDNS bei No-IP oder einem anderen Provider registrieren.
                          - Beim Provider die aktuelle IP-Adresse eintragen - geht meist mit automatischer Erkennung.
                          - danach mit einem ping auf die neue Domain prüfen ob die Domain auf deine aktuelle public IP-Adresse verweist. (Alle Nameserver aktuell sind)
                          - für Deine "neue, eigene" Domain das lets-encrypt Zertifikat auf dem NGINX erstellen,
                          - Zertifikat entsprechend Anleitung (die von smarthomeNG) im NGINX konfigurieren, den NGINX neustarten
                          - und bevor ichs vergesse, auf der Fritzbox noch eine Portweiterleitung auf den NGINX einstellen.
                          - dann auf der Fritzbox noch das automatische aktualisieren der Dyn-Domain aktivieren - hier gibts auch unterschiedliche Wege, das kann ich konkretisieren wenn der Provider feststeht und der Rest erstmal läuft.

                          dann sollte das auch funktionieren.

                          Gruss Andre
                          Zuletzt geändert von AndreK; 22.01.2020, 22:41.

                          Kommentar


                            Ich habe es jetzt noch mal mit no-ip probiert. (Myfritz geht wirklich nicht). DynDns Domain erstellt verbunden alles gut. IP-Adressen werden übermittelt, Ports sind frei aber geht irgenwie immer noch nicht. nginx läuft inzwischen auch gar nicht mehr. Er sucht beim Start nun immer das Zertifikat was aber nicht angelegt werden kann, weil der Server nicht antwortet. Wo ich das wieder aus der Setup nehmen kann habe ich nicht gefunden....

                            Ein erneutes Setup_all kann das auch nicht wieder rückgängig machen.

                            Ich warte jetzt einfach auf die nächste Version des Images von Onkelandy. Ich habe jetzt erstmal die Lust verloren da weiter zu forschen.

                            Kommentar


                              Hallo schuma

                              schau mal

                              Code:
                              etc/nginx/sites-available
                              entweder die default datei oder falls Du individuelle Datei angelegt hast diese mit Editor öffnen
                              Da sind wahrscheinlich 2 Zeilen
                              Code:
                              ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem;
                              ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem;
                              Diese auskommentieren oder löschen.
                              Dann nginx neu starten

                              mit
                              Code:
                              systemctl status nginx.service
                              prüfen ob der Service wieder läuft.
                              Sonst das Log prüfen und ggf hier posten

                              Gruß
                              Michael
                              Meine Installation: VM Debian Buster SH NG 1.8.1, SmartVISU 3.0, KNX, DMX, 1-wire, Fortigate 30E IPS, VMware vSphere 6.7

                              Kommentar


                                Ich habs jetzt doch noch mal probiert....
                                Also: Das Zertifikat konnte ich jetzt erstellen! Man muss in der Fritte den Fernzugang deaktivieren, sonst wird der Port 443 von dem Fernzugang benutzt!!!
                                Also Zertifikat erstellt. jetzt bekomme ich aber im AWS beim Test immer diese Fehlermeldung:

                                Code:
                                START RequestId: xxxxxxxxxxxxxxxxxxxxxxxxxxx Version: $LATEST
                                2020-01-23T19:08:39.061Z 7988384b-be82-453f-8c14-846710xxxxxx INFO requesting {"directive":{"header":{"namespace":"Alexa.Discove ry","name":"Discover","payloadVersion":"3","messag eId":"abc-123-def-456"},"payload":{"scope":{"type":"BearerToken","to ken":"access-token-from-skill"}}}}2020-01-23T19:08:39.194Z 7988384b-be82-453f-8c14-84671xxxxxx ERROR request failed Error: Client network socket disconnected before secure TLS connection was established
                                at connResetException (internal/errors.js:570:14)
                                at TLSSocket.onConnectEnd (_tls_wrap.js:1361:19)
                                at Object.onceWrapper (events.js:299:28)
                                at TLSSocket.emit (events.js:215:7)
                                at endReadableNT (_stream_readable.js:1183:12)
                                at processTicksAndRejections (internal/process/task_queues.js:80:21) {
                                code: 'ECONNRESET',
                                path: null,
                                host: 'yyyyyy.xxxxxxx.org',
                                port: '9900',
                                localAddress: undefined
                                }2020-01-23T19:08:39.194Z 7988384b-be82-453f-8c14-8xxxxxxxx ERROR Invoke Error {"errorType":"Error","errorMessage":"Client network socket disconnected before secure TLS connection was established","code":"ECONNRESET","path":null,"host ":"yyyyyy.xxxx.org","port":"9900","stack" :["Error: Client network socket disconnected before secure TLS connection was established"," at connResetException (internal/errors.js:570:14)"," at TLSSocket.onConnectEnd (_tls_wrap.js:1361:19)"," at Object.onceWrapper (events.js:299:28)"," at TLSSocket.emit (events.js:215:7)"," at endReadableNT (_stream_readable.js:1183:12)"," at processTicksAndRejections (internal/process/task_queues.js:80:21)"]}END RequestId: 7988384b-be82-453f-8c14-8xxxxxxxxx
                                REPORT RequestId: 7988384b-be82-453f-8c14-846xxxxxxx Duration: 241.50 ms Billed Duration: 300 ms Memory Size: 512 MB Max Memory Used: 75 MB Init Duration: 128.98 ms
                                Kann hiermit jemand auf die Schnelle was anfangen?

                                Grüße, Marc

                                Kommentar

                                Lädt...
                                X