fhem-va für fhem-alexa Server selbst hosten?

[fhem@supergut]

Hallo und danke für die gute Arbeit.

Gibt es die Option, einen fhem-va Server für fhem-alexa selbst zu hosten? Ich hätte da einen Server in FFM mit Anbindung zum DECIX und anderen.

Danke im Voraus.

[justme1968]

was ist ein fhem-va server? was ist fhem-alexa?

wenn du alexa-fhem ohne den vereinsserver betrieben möchtest: einfach wie 'früher' mit port forwarding einen privaten skill einrichten. siehe https://wiki.fhem.de/wiki/Alexa-Fhem. die beschreibung ist leider nicht mehr ganz aktuell da sich die amazon seiten weiter entwickelt haben. das prinzip ist aber gleich.

oder statt port forwarding nimmst du den code des vereins proxy den georg veröffentlicht hat und baust darauf auf. auch dann musst du einen privaten skill bei amazon anmelden.

[gvzdus]

Und nochmal sind 2 Monate ins Land gegangen: https://github.com/gvzdus/sshd-oauthmux

[fhem@supergut]

Und nochmal sind 2 Monate ins Land gegangen: https://github.com/gvzdus/sshd-oauthmux

Moin,

ich habe mal Zeit zum testen gefunden und hänge nun bei: kex_exchange_identification: Connection closed by remote host.

Ich habe die hardcodierten Einträge fhem-va.fhem.de entfernt und durch meine FQDN ersetzt.

Und ich haben den öffentlichen ssh.key kopiert:

Code: [Auswählen]

cat /etc/ssh/ssh_host_rsa_key.pub > /etc/sshd-oauthmux/hostkey.ser
Aber leider fehlen mir beiden Dateien /etc/sshd-oauthmux/application.properties und /etc/sshd-oauthmux/log4j.xml , wo finde ich diese?

Danke im Voraus.

Code: [Auswählen]

root@saturn:/etc/sshd-oauthmux# sudo -u fhem ssh -vvvA -p 58824 127.0.0.1 register
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 127.0.0.1 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/opt/fhem/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/opt/fhem/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 58824.
debug1: Connection established.
debug1: identity file /opt/fhem/.ssh/id_rsa type 0
debug1: identity file /opt/fhem/.ssh/id_rsa-cert type -1
debug1: identity file /opt/fhem/.ssh/id_dsa type -1
debug1: identity file /opt/fhem/.ssh/id_dsa-cert type -1
debug1: identity file /opt/fhem/.ssh/id_ecdsa type -1
debug1: identity file /opt/fhem/.ssh/id_ecdsa-cert type -1
debug1: identity file /opt/fhem/.ssh/id_ecdsa_sk type -1
debug1: identity file /opt/fhem/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /opt/fhem/.ssh/id_ed25519 type -1
debug1: identity file /opt/fhem/.ssh/id_ed25519-cert type -1
debug1: identity file /opt/fhem/.ssh/id_ed25519_sk type -1
debug1: identity file /opt/fhem/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /opt/fhem/.ssh/id_xmss type -1
debug1: identity file /opt/fhem/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5
kex_exchange_identification: Connection closed by remote host
Connection closed by 127.0.0.1 port 58824

[fhem@supergut]

okay, weiter:

Code: [Auswählen]

Status Report</p><p><b>Message</b> Invalid URI
als Antwort. und ich glaube, auf

https://github.com/gvzdus/sshd-oauthmux/tree/master/src/main/webapp/register

fehlt das Verzeichnis "api".

root@saturn:/var/lib/tomcat9/webapps/register# cat check.html | grep api
                  //btn['onclick'] = 'document.location.href="/register/api/passcode";return false;';
      req.open("GET", "/register/api/checknodejs", true);
  <button id='activate' class="btn btn-lg btn-secondary disabled" type="cancel" disabled onclick='document.location.href="/register/api/passcode";return false;'>Activate Skill</button>

Code: [Auswählen]

root@fhem-pi4:/opt.tmpfs/fhem# sudo -u fhem ssh -vA -p 58824 10.252.252.4 status
OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
...
debug1: identity file /opt/fhem/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1
debug1: ssh_exchange_identification: <!doctype html><html lang="en"><head><title>HTTP Status 400 \342\200\223 Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-
debug1: ssh_exchange_identification: size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 \342\200\223 Bad Request</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> Invalid URI</p><p><b
debug1: ssh_exchange_identification: >Description</b> The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).</p><hr class="line" /><h3>Apache To
ssh_exchange_identification: Connection closed by remote host

[fhem@supergut]

Moin.

Ich finde fhem super und danke allen Entwicklern für ihre Arbeit.

Aber Schade ist es doch: Ich dachte, ein Top Open Source Project wie fhem gäbe der Community alle Daten und Möglichkeiten zur Umsetzung. Leider besteht hier wohl kein Interesse, das Nutzer eigenständig einen Server zur Alexaanbindung betreiben. Unter https://github.com/gvzdus/sshd-oauthmux fehlt einiges an Dateien zur Umsetzung eines solchen Servers.

Daher mal direkt gefragt: Kann ich hier mit Unterstützung der Entwickler rechnen oder nicht? Danke. Und gesund bleiben!

[gvzdus]

Hi, um es kurz zu halten: Nein.

justme hat schon geschrieben: Für die Einzelanbindung gibt es immer noch den alten Weg ohne "sshdoauthmux" aka Vereinsproxy. Ich habe das damals auf github veröffentlicht, damit der Code Open-Source ist und auf Security-Bugs hin untersucht werden kann, aber nicht im Sinne eines "oder zieht massenhaft weitere Server hoch".

Ein paar der Fragen könntest Du Dir z.B. beantworten, wenn Du versuchst, Apache MINA SSHD ganz normal "hochzuziehen". Andere Dinge, z.B. Settings, sind nicht auf Github, weil da Secrets drin sind (z.B. der private Hostkey).

Es erscheint mir hilfreicher für die Allgemeinheit, mir eher z.B. den ECC-Support auf die Todo-Liste zu schreiben, als ein Einsteigerdoku für einen eigenen Proxy zu erstellen.