Vereinsserver Unterstützung von rsa-sha2-256

[Sidey]

Halöchen,

ich bin derzeit dabei, das Docker Image für alexa-fhem auf Bookworm zu aktualisieren.
Damit einher kommt auch eine neue openssl Version, die den schon seit längerem SHA-1 hash Algorithmus deaktiviert.

Mir sind natürlich Möglichkeiten bekannt weiterhin SHA1 für OpenSSL zu aktivieren, allerdings hat das deaktivieren ja seinen Grund.

Die erzeugten RSA Keys, sollten meiner Meinung nach auch weiterhin mit SHA2 256 funktionieren.

Nach meinem derzeitigen Kenntnisstand unterstützt der Vereinsserver allerdings derzeit kein SHA2-256 oder SHA2-512.
Die Unterstützung dieser Algorithmen wäre wünschenswert.
Was wäre dafür denn zu tun?


Viele Grüße
Sidey

[Otto123]

Hi Sidey,

der Vereinsserver verwendet im System
OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022

Ich verstehe die Frage nicht komplett, liegt aber an meinem geringen Verständnis für das gesamte Thema. Ich brauche keine Erklärung.

Ich will aber die Diskussion mitlesen

Gruß Otto

[rudolfkoenig]

Ich vermute, es geht hier um das Programm, was auf dem VA-Server des Vereins laeuft, und die Verbindung zwischen Amazon und den Benutzern herstellt.
Die Benutzer verbinden sich per SSH mit diesem Programm @fhem-va.fhem.de, was wiederum von Amazon kontaktiert wird.
Es existiert eine neuere Version der vom Programm verwendeten SSHD Bibliothek, was eventuell das o.g. Problem loesen koennte.

Keine Ahnung, wieviel Aufwand der Austausch bedeutet, das muesste der Autor sagen.

[Sidey]

Ich denke, auf dem Vereinsserver läuft ein Apache Mina:

https://github.com/gvzdus/sshd-oauthmux/blob/b2571b006227166760192d4e8b7aa0495b31260b/pom.xml#L33

In Version 2.2.0 wird nur SHA1 unterstützt.

Ab Version 2.3.0 kann Apache Mina auch SHA2 256/512:
https://github.com/apache/mina-sshd/blob/master/docs/changes/2.3.0.md#behavioral-changes-and-enhancements

Auf der Clientseite (die für uns nicht relevant ist) muss seit dem ssh-rsa explizit aktiviert werden.


Einige Versionen größer 2.3.0 beinhalten Bugfixes und Anpassungen.


Aktuell ist Version 2.14.0

Diese soll für den Server noch ssh-rsa unterstützen:

https://github.com/apache/mina-sshd/blob/1cc0c0c98e6489449dccff65dd6dc81e74d947c3/docs/standards.md?plain=1#L145



Ich denke, um die bestehenden Installation weiterhin zu unterstützen muss auch erst mal ssh-rsa weiterhin im Server unterstützt werden, aber zusätzlich braucht es weitere Optionen wie SHA2 oder auch ed25519.

Grüße Sidey

[gvzdus]

Ich habe mich gestern etliche Stunden "rumgeärgert".
Die Migration auf 2.3.0 ist noch relativ problemlos: Dann wird "rsa-sha2-512" angeboten und unterstützt. Zwar benötigt der sonstige Code Änderungen, die erscheinen mir aber noch harmlos.
2.14.0 ist eine gewisse Hölle:

• Sehr viele, tiefe Änderungen, insbesondere auch im PortForwarder-Code (also beim "Trick", auf Serverseite nicht real einen Port zu öffnen, sondern nur virtuell die einkommenden AWS-Requests in den Channel zum Client zu schicken)
• Support von RSA raus
• RSA-Hostkey wird nicht mehr geladen, stattdessen ein neuer erzeugt

Vor allem aber: Sobald der Vereinsserver etwas Moderneres als RSA anbieten würde, der Nutzer also z.B. mit ed25519 ankommt, fehlt der alte SSH-Key, der den Nutzer identifiziert.
Meine (schon sehr alten) Überlegungen gingen dahin, auf 2 Ports zu lauschen: "Legacy RSA Only" und "modern", und weitere "Befehle" zu implementieren, die eine automatische Migration "RSA auf ..." unterstützen. Das erfordert natürlich auch Änderungen an alexa-fhem - aber das ist noch "milde".

Vorschlag:
- Auf 2.3.0 kann ich wohl problemlos gehen und ggf. zurückfallen: Wenn Dir das was bringt.
- Für einen Support aktueller Verfahren erscheint es mir schwierig, eine MINA-Version zu finden, in der noch beides möglich ist. Die Dokumentation von MINA ist übersichtlich...

Wenn die Migration auf 2.3.0 bereits hilft, kann ich das umgehend probieren.

[Sidey]

Hallo gvzdus,

ich denke die Migration auf 2.3.0 hilft schon mal.
Das ein Upgrade von 2.3.0 auf 2.14 kein einfaches Unterfangen wird habe ich mir schon vorstellen können, aber so ganz schlau würde ich aus dem Changelog auch nicht.


Der alte RSA Key sollte mit sha2-256 bereits funktionieren, das wäre ja schon ein Schritt.

PS: einen Testserver gibt es nicht oder?

Grüße Sidey

[gvzdus]

Wenn Du magst: Auf 3.255.239.36:22022 teste ich gerade mit 2.3.0. Hier kannst Du die Befehle wie "status", "register" etc. probieren und den Algorithmus sehen.

[gvzdus]

Ich habe soeben den Vereinsserver auf Mina 2.3.0 aktualisiert. Das scheinen alle Clients "überlebt" zu haben, die Verbindungen der Nutzer wurden wieder aufgebaut.
Update: Auch einmal den Flow des Trennens des Skills sowie des Wiederverbindens getestet.

[Sidey]

Hi gvzdus,

Wenn Du magst: Auf 3.255.239.36:22022 teste ich gerade mit 2.3.0. Hier kannst Du die Befehle wie "status", "register" etc. probieren und den Algorithmus sehen.

Ich habe getestet, aber mir scheint, dass SHA2-256 oder SHA2-512 derzeit nicht akzeptiert wird:

Code Auswählen Erweitern

debug1: Offering public key: /alexa-fhem/.ssh/id_rsa RSA SHA256:ZT9YvC8kNL9xK0WwvyZ+Udj1nd3nZzN7+nnUyf8YjPc explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: keyboard-interactive,publickey
debug1: No more authentication methods to try.
alexa-fhem@3.255.239.36: Permission denied (keyboard-interactive,publickey).

Hast Du es mit SHA2 oder nur mit SHA1 probiert?


Viele Grüße
Sidey

[gvzdus]

Kann es sein, dass Du Port 22022 vergesssen hast, und mit dem hochoffizielle SSH-Demon der Amazon Linux Distribution sprichst?

[Otto123]

Ich habe soeben den Vereinsserver auf Mina 2.3.0 aktualisiert.

Ich habe da ne Zwischenfrage: Wer lauscht jetzt eigentlich auf va.fhem.de auf Port 58823? Dort werden mir zwei Verbindungen angezeigt, aber mit Telnet bekomme ich keinen Banner. Ich meine früher war das anders.

Auf Port 58824 meldet sich jetzt
SSH-2.0-APACHE-SSHD-2.3.0
Steht die 2.3.0 für die erwähnte Mina Version?

[gvzdus]

Moin, 58823 ist der HTTP-Listener von Tomcat. Du erreichst ihn von außen unter https://va.fhem.de/.
Hier kommen zumindest die HTTP(s)-Requests beim Aktivieren des Skills zum Tomcat an.

Ja, SSH-2.0-APACHE-SSHD-2.3.0 bedeutet, dass die neue(re) MINA-Version aktiv ist.

[Sidey]

Kann es sein, dass Du Port 22022 vergesssen hast, und mit dem hochoffizielle SSH-Demon der Amazon Linux Distribution sprichst?

Leider war es das nicht

Ich habe es so verbunden:

Code Auswählen Erweitern

ssh -v -F .ssh/config -p 22022 3.255.239.366

Viele Grüße

[Otto123]

Sorry das war ein Eigentor, der Befehl fragt nur den Client
Ich habe davon ja nicht viel Ahnung, aber Unterstützt unser va.fhem.de nicht jetzt sha2 ?

Code Auswählen Erweitern

ssh -Q sig va.fhem.de -p 58824
ssh-ed25519
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521Ich meine, das war vor der Änderung von Georg anders.

Bin ich damit auf der richtigen Spur? Aktualisierter va Server

Code Auswählen Erweitern

ssh -vvv va.fhem.de -p 58824

debug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group18-sha512,diffie-hellman-group17-sha512,diffie-hellman-group16-sha512,diffie-hellman-group15-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96

Zumindest ein ältere ssh Server in meiner Umgebung liefert da keinerlei sha2 Einträge

debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,kexguess2@matt.ucc.asn.au
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc
debug2: ciphers stoc: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc
debug2: MACs ctos: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha1-96,hmac-sha1,hmac-md5

[Sidey]

Zwischenzeitlich kann ich berichten, dass die Verbindung mit dem Testserver und SHA2-256 jetzt klappt.

Aufgefallen ist mir aber, dass sich der Fingerprint vom Server geändert hat.

Zu va.fhem.de klappt es hingegen nicht.

Grüße Sidey

[Otto123]

ich weiß nicht ob Du da fhem-va.fhem.de nehmen musst. Die hinterlegten IP sind aber identisch.

[gvzdus]

Auf "meinem" Testserver (meine Spiel-Instanz bei AWS, die hoch- und runterfährt) ist eh' buntes Chaos.
Du musst ja die zig Level unterscheiden:
 - Hostkey-Format
 - KeyExchange
 - Signatur
 - Verschlüsselung
etc.

Zu dem Elend von Apache MINA gehört eine völlig unbefriedigende Hostkey-Verwaltung. Das scheint nie produktiv mit mehreren Verfahren parallel gelaufen zu sein, sondern immer nur mit einem Verfahren. Zu den Tücken gehört auch, MINA dazu zu bewegen, auch nur einen selbst generierten Key zu persistieren.
Ich werde da kurzfristig nicht weiterkommen, einen Migrationspfad auf ED25519 / ECDSA im Parallelbetrieb zu RSA anzubieten.
Selbst auf 2 getrennten Ports "zickt" MINA.

[Sidey]

Hi gvzdus,

Ja ist für mich leider auch etwas kryptisch. Ich werde das die Tage noch genauer vergleichen.

Ggf. weichen wir etwas vom Thema ab, aber was spricht eigentlich dagegen ein opensshd zu verwenden?
Darüber kann man doch einen ssh Tunnel aufbauen um darüber wäre es doch grundsätzlich möglich die Kommunikation zu dem Webserver zu etablieren.


Grüße Sidey

[gvzdus]

Weil ja zwar der Befehl "Öffne einen Listener-Port auf dem Zielserver und verbinde ihn mit meinem lokalen nodejs" (ssh -R) verwendet wird, aber der Zielserver keine realen TCPIP-Ports öffnet, sondern sie nur virtuell mit einkommenden HTTP-Requests von Amazon beschickt.
Ich denke mal, Rudi hat kein Problem mit der Veröffentlichung: Es sind aktuell 2671 Nutzer verbunden, es werden also 2671 TCP-Verbindungen "gehalten".
Da hätte man eher vor 5 Jahren auf Websockets setzen sollen - war dem Andre sein Reden, aber ich wollte SSH

[gvzdus]

Die "Magie" der Software ist ja: "Egal, wie Dein SSH-Key ist: Annehmen tue ich Dich. Beweise im folgenden, dass ich legitim Dir die für Dich bestimmten Amazon-Requests weiterleiten darf - danach ist Dein Secret bei Amazon mit Deinem SSH-Key verknüpft".

[Sidey]

Ho gvzdus,

Die Verbindung zum Testserver lässt sich leider nicht mehr aufbauen um die Unterschiede analysieren zu können.

Da der Server grundsätzlich rsa-sha2-256 und 512 anbietet vermute ich hier einen der in 2.3.0 noch vorhandenen Bugs.

Aktuell weiss ich nicht, was ich effektiv machen kann um zu helfen.

Grüße Sidey

[mkraus81]

ich bin heute auch auf bookworm gegangen (raspi) und tja... problem

Code Auswählen Erweitern

alexaFHEM.ProxyConnection
error; Reverse Proxy replied with neither registered nor unregistered status: out:  err:fhem@fhem-va.fhem.de: Permission denied (keyboard-interactive,publickey).
wie kann ich SHA1 bei bookworm aktivieren, damit alles wieder läuft?

[Sidey]

ich bin heute auch auf bookworm gegangen (raspi) und tja... problem

Code Auswählen Erweitern

alexaFHEM.ProxyConnection
error; Reverse Proxy replied with neither registered nor unregistered status: out:  err:fhem@fhem-va.fhem.de: Permission denied (keyboard-interactive,publickey).
wie kann ich SHA1 bei bookworm aktivieren, damit alles wieder läuft?

Wie das geht, habe ich dir gerade per pm schon geschrieben.

Grüße Sidey

[mkraus81]

@Sidey DANKE für die Hilfe... kann man die Lösung nicht hier posten, falls andere auch das Problem haben?

[Sidey]

@Sidey DANKE für die Hilfe... kann man die Lösung nicht hier posten, falls andere auch das Problem haben?

Die Lösung ist eigentlich nicht mehr diese SHA Methode zu verwenden und stattdessen eine die als sicher eingestuft wird. Daher werde ich es hier nicht Posten.
Es gibt dazu auch schon Posts im Forum, die meinen Verdacht bestätigen, dass hier einfach ohne Wissen Dinge angewendet werden, weil es halt geht.

Ob sich aus dem Workaround ein reales Sicherheitsrisiko ergibt vermag ich nicht zu bewerten, aber empfehlen werde ich diese Vorgehensweise nicht die ich dir geschrieben habe.

Über das Docker Image habe ich ja wenigstens die Chance den Workaround wieder zu entfernen.

Grüße Sidey

[mkraus81]

ich kenn mich mit dem SHA Methode so auch nicht aus...
aber klar, wenn das eine Sicherheitslücke ist, sollte man das beim "Server" anpassen...
aber wenn ich das hier richtig lese scheint dies nicht ganz so einfach zu sein

[PNinBB]

Es herrscht zwar schon ein gutes Jahr Ruhe hier, aber ich versuche es einmal. Meine Probleme scheinen hier her zu gehören. Ich habe mehrere Jahre alexa-fhem genutzt (Skill "FHEM Connector"). Das alles lief geräuschlos noch auf 'buster'. Nun habe ich alles neu aufgesetzt mit 'trixie'. Seit gut 3 Wochen "kämpfe" ich um die Wiederherstellung des "alten Zustandes" ! Vieles geht bereits wieder; das Problem ist oft, dass trixie sehr streng mit Sicherheitsfragen ist und oft alles, was nicht "sauber" ist, abschmettert. Momentan scheitere ich an der Verbindung mit dem Vereinsserver.
Kommandline stirbt ab:

Code Auswählen Erweitern

root@PNinBBServer4 30.01.2026;14:10:41 ~ 1>sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
ssh: connect to host fhem-va.fhem.de port 58824: Connection timed out
und im Web sieht es wie folgt aus:

READINGS:
     2023-10-17 20:10:14   .eventToken     {"access_token":"Atza|IwEBIBoGgWvD-shzIbkJ........................Qan361jcDV6b4ZeI75Q5tr","token_type":"bearer","expires_in":3600}
     2026-01-29 19:54:34   alexaFHEM       running /usr/bin/alexa-fhem
     2026-01-29 19:56:51   alexaFHEM.ProxyConnection error; Reverse Proxy replied with neither registered nor unregistered status: out:  err:ssh: connect to host fhem-va.fhem.de port 58824: Connection timed out

     2023-10-16 16:59:11   alexaFHEM.bearerToken crypt:730xxxxxxxxxxxxxxxxxxxx
     2023-10-16 16:59:11   alexaFHEM.skillRegKey crypt:07065xxxxxxxxxxxxxxxxxxxxxxxxxxxxx0d0b

Ich habe schon verschiedenes probiert, auch die diversen Einträge von

Code Auswählen Erweitern

Host fhem-va.fhem.de
  HostkeyAlgorithms +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa helfen nicht !!
Bin nur ich damit konfrontiert, weil ich etwas ganz simples falsch mache, oder gibt es ein paar Hinweise ??
Besten Dank im Voraus.
Peter

[gvzdus]

Das ist definitiv ein reines Connectivity / Firewall-Problem bei Dir!
Das "+ssh-rsa" ist gut, aber Du hast schon Probleme beim reinen Verbindungsaufbau. Vermutlich hast Du im Router Firewall-Regeln, oder aber Deine Raspi / etc. hat überhaupt keine Internet-Verbindung.
So ist "Soll":

Code Auswählen Erweitern

ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2025-01-03T22:56:26Z as C51646C5.


[Otto123]

Hallo Peter,

ich meine, da stimmt was im Netzwerk nicht. Geht denn ein

Code Auswählen Erweitern

ping fhem-va.fhem.devon dieser Maschine?
Bzw. etwas definierter:

Code Auswählen Erweitern

ping -4 fhem-va.fhem.de

Code Auswählen Erweitern

ping -6 fhem-va.fhem.de
Falls der Ping geht, geht denn der Port?

Code Auswählen Erweitern

nc fhem-va.fhem.de 58824
Gruß Otto

[passibe]

Zeig uns evtl. auch mal die Verbose-Ausgabe des SSH-Befehls, also mit -vv nach ssh:

Code Auswählen Erweitern

sudo -u fhem ssh -v -p 58824 fhem-va.fhem.de status

auch die diversen Einträge von

Code Auswählen Erweitern

Host fhem-va.fhem.de
  HostkeyAlgorithms +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa

In welche Datei hast du das gelegt?
Das muss in

Code Auswählen Erweitern

/opt/fhem/.ssh/configund wenn es da steht (idealerweise) nirgends sonst.

[Sidey]

Warum nutzt ihr nicht einfach den Docket container? Mit dem läuft es doch.

Grüße Sidey

[PNinBB]

Zunächst herzlichen Dank für die schnelle Reaktion: Ich bin  ein ganzes Stück weiter, aber eben noch nicht dort, wo ich voher war.
1. ich bin in der "komfortablen" Lage, mehrere Server im Heimnetz zu haben, davon einen (Server4, noch mit Buster) auf Raspberry 4B für mein FHEM (um die 50 ZWAVE Geräte) und einen (Server5) auf ODROID XU4 auch mit FHEM, aber ohne Geräte, hauptsächlich für Informationsbeschaffung (Wetter, Treibstoffpreise, Aktien etc.); beides lief schon mehrere Jahre. Beide habe ich in den ersten Januartagen mit trixie neu aufgesetzt. Somit kann ich auch bequem und schnell nachschauen, wie es auf dem anderen läuft.
2. Ja, ich habe (und hatte) Internetverbindung, aber die 'pings' (danke Otto123) gingen auf Server5, aber nicht auf Server4. Der Teufel steckte in der Namensauflösung und zwar im Detail in der Präferenz von Trixie, ipv6 zu bevorzugen. Ich habe vor längerer Zeit in meiner FritzBox 7490 ipv6 nicht zugelassen (da hatte ich Probleme, an die ich mich nicht mehr erinnern kann!). Nun kommen noch (wahrscheinlich !) Besonderheiten der Netzwerktreiber, die natürlich die konkrete Hardware berücksichtigen, dazu. Server5 testet (wie es scheint!) erst einmal, ob ipv6 überhaupt geht --> wenn nicht ipv4. Server4 ist rigeroser: er wartet bis ipv6 geht --> wenn nicht: time out!! Nun kann man mittels der Datei '/etc/gai.conf' diese Strategie beeinflussen:

#    For sites which prefer IPv4 connections change the last line to
#
# 31.01.2026. auskommentiert wegen alexa-fhem
#precedence ::ffff:0:0/96  100
precedence ::ffff:0:0/96  100

Ich habe allerdings in dieser Zeitspanne so vieles probiert, dass ich etwas die Übersicht verloren habe. Auf jeden Fall: nach dem Auskommentieren gingen alle 'pings' und der Vereinsserver lieferte

root@PNinBBServer4 01.02.2026;10:42:12 / 32>sudosudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2026-01-31T14:48:27Z as xxxxxxxx.
root@PNinBBServer4 01.02.2026;10:42:35 / 33>

Ich habe in der Datei wieder auskommentiert und es geht noch immer, was mir eigentlich unklar ist. Aber vielleicht ist in den Tiefen des Treibers diese Situation vermerkt !!!??.
Nun kann ich im alexa.log vieles erfreuliches sehen, u.a.

. . .
[1.2.2026, 10:38:09] sshautoconf: SSH key seems to exist
[1.2.2026, 10:38:10] sshautoconf: Our SSH key is known at the reverse proxy, good!
[1.2.2026, 10:38:10] [FHEM]   executing: http://192.168.2.244:8083/fhem?cmd=%xxxxxxxxxxxxxd>
*** FHEM: connected
[1.2.2026, 10:38:10] [FHEM] got: 47 results
[1.2.2026, 10:38:10] [FHEM] AA_TA_GW is thermometer
. . .

Was mich noch irritiert, sind die readings von alexa:

READINGS:
     2026-02-01 10:38:00   alexaFHEM       running /usr/bin/alexa-fhem
     2026-02-01 10:38:11   alexaFHEM.ProxyConnection running; SSH connected
     2026-02-01 10:35:17   alexaFHEM.bearerToken crypt:0a5a0b56
     2026-02-01 10:35:17   alexaFHEM.skillRegKey crypt:0a5a0b56

In der früheren Version waren die Werte für bearerToken und skillRegKey "lange Würmer". Schauen diese Werte normal aus ??
Woran ich noch scheitere, um zu erreichen, dass "es so ist wie früher", ist das Aktivierung des Skills "FHEM Connector". Welchen 'key' soll man denn dort eingeben ?? Im Wiki steht ja eigentlich zweifelsfrei:

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein, den du mittels "get alexa proxyKey" erhalten hast,...

. Auf der Startseite des Webportals heisst es:

You should find it in FHEM in the Alexa-device, type e.g. "get alexa proxyKey"

.
Aber, wenn ich das benutze, was ich mit 'get alexa proxyKey' erhalte, so wird das abgeschmettert. Während des Einrichtens des Gerätes ist mir nichts unter die Augen gekommen, was danach aussah ! Und ich dachte, ich habe mal gelesen, dass beim erstmaligen Anmelden am Vereinsserver, ein Schlüssel automatisch erzeugt wird, den man dann im Log finden kann.
Fazit: an der Stelle tappe ich noch im Dunkeln. Für ein wennig "Erleuchtung" wäre ich sehr dankbar!
Schönen Sonntag noch.
Peter

[Otto123]

• zur Aktivierung des Keys kann ich nichts sagen, ich bin immer froh wenn mein Testgerät läuft und ich weiß der Vereinsserver macht was er soll
• bearerToken und skillRegKey sehen mMn nicht gut aus.
• IPv6 ist mittlerweile bei allen neueren Systemen die Standardvariante, sich dagegen dauerhaft zur Wehr setzen wird irgendwann ins Abseits laufen.

Wenn es der Router nicht liefert, ist es mMn nach am Besten man schaltet es auch auf seinen Devices ab.
Zum Testen kann man es relativ einfach abschalten:
Windows:

Code Auswählen Erweitern

Get-NetAdapterBinding -ComponentID "ms_tcpip6" | where Enabled -eq $true | Disable-NetAdapterBinding -ComponentID "ms_tcpip6"Linux

Code Auswählen Erweitern

sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1Besser ist es aber IPv6 sauber auch im Router laufen zu haben! Mittlerweile läuft dies mit modernen Systemen, aktueller Software und den default Einstellungen eigentlich stressfrei.