HomeMatic-Forum / FHZ-Forum

]Hallo zusammen,
Momentan baue ich mir eine Testumgebung im Docker mit RaspberryMatic auf einem Rpi4b mit 4GB, SSD Sabrent. Die Installation der RaspberryMatic habe ich mit dem deploy.sh gemacht. Dockerumgebung und R-Matic (3.57.5) läuft, Zugriff über ip:8080 ist möglich und ssh habe zugelassen im Systemsteuerung/Sicherheitsmenu.
Leider kann ich per ssh (WinSCP und Putty) nicht auf die Konsole zugreifen, sondern es erfolgt sofort ein Abbruch, die user bzw. Passwort Abfrage erfolgt nicht, auch ein ssh key wird nicht angezeigt. Im WinSCP und Putty habe ich nur IP - Adresse und Userid geändert, ansonsten ist alles Standard.
Was ich bisher gemacht habe:
1. Zugriff per telnet ip 22222 : es kommt Antwort : ssh-2.0-OpenSSH_8.4
2. mit docker exec ccu -it /bin/sh : nochmals das Password gesetzt:
passwd: Antwort : no record of root in /etc/shadow, using /etc/passwd
passwort neu gesetzt, scheint trotzdem die Änderung ok zu sein. Aber kein Erfolg mit gleichem Abbruch.
3. im Docker nach usr/local/etc/password gesucht: Die Berechtigungen für root schein ok zu sein, das Verzeichnis passwd existiert, hat aber drwx--------
4. Logfile von WinSCP: Leider finde ich den Fehler nicht, der zum vorzeitigem Abbruch führt. Kann mir jemand helfen?

Update: Den Rpi4 habe ich neu installiert, nur Docker läuft, keine weiteren Container installiert. Dann mit deploy.sh wieder die RaspberryMatic installiert (bei ausgebautem RPI-RF-MOD). Zugriff auf ccu WebUi geht.
Leider habe ich nach wie vor keinen Zugriff auf ccu per ssh.
Hier nun die LogFiles
Client Putty :
ccu Messages Log (Debug3):
Im Message Log ist leider keinerlei ssh - Fehler / Typ etc. zu erkennen ( was eigentlich nicht vorkommen darf!).
Deshalb ist meine Vermutung, dass es ein Problem mit IPV4 / IPV6 gibt, z.B. MTU Size 1500 gibt.
Wahrscheinlicher ist aber ein Abbruch durch die Firewall, da auch ein weiterer Port (2110 für HPCL) nicht funktioniert.
Hat da jemand gleiche Erfahrungen gemacht?
Wo finde ich die Specs der Firewall?
Mithilfe bei der Ursachenforschung gerne erwünscht!

Update
Im Kernel - log wird nur bei einem reboot ein Fehler des sshd eingetragen: Dies deutet auf einen Fehler des sshd ( GNU C Library glibc-2.30.9000-31.fc32.armv71 - Betrifft auch arch - Systeme)
Das Problem ist beschrieben:
https://bugzilla.redhat.com/show_bug.cgi?id=1796267
Ein Lösungsansatz findet man auch beim Problem:
https://unix.stackexchange.com/question ... wn-syscall

Es stellt sich die Frage : Ist die GNU C Library auf neuestem Stand?

Auweia hat geschrieben: ↑

18.04.2021, 10:37

Es stellt sich die Frage : Ist die GNU C Library auf neuestem Stand?

Da RaspberryMatic immer auf recht aktuelle Buildroot versionen setzt (aktuell 2021.02, nächster release 2021.02.1) ist auch immer die damit mitgelieferte, jeweils aktuelle glibc dabei.

Offensichtlich ist aktuell in der glibc 2.32 , openssh 8.4p1 der Fehler enthalten.
Es wird ein downgrade to 2.30 empfohlen, was ja nicht sonderlich sinnvoll ist.

Verstehe ich das richtig das das ohnehin nur in der docker-umgebung passiert? Weil auf einem RaspberryPi mit direkt installiertem RaspberryMatic sind mir bis dato solche Probleme nicht bekannt und SSH funktioniert da tadellos.

korrekt

Um eine Shell für einen Container zu bekommen ist ssh nicht der richtige Weg.

Schau mal hier https://www.baeldung.com/ops/docker-container-shell

cloudman88 hat geschrieben: ↑

19.04.2021, 08:25

Um eine Shell für einen Container zu bekommen ist ssh nicht der richtige Weg.

"richtig" ist relativ. Natürlich ist es besser sich via passendem "docker exec" befehl eine shell innerhalb der jeweiligen Docker Umgebung zu besorgen wenn man was darunter machen muss. Trotzdem ist es vollkommen valide auch innerhalb eines docker einen SSH Daemon zu starten um ein remote-login service zur verfügung zu stellen. Und natürlich muss dieser genauso gut/schlecht funktionieren wie unter einer realen Hardwareumgebung.

Stimmt "nicht richtig" war falsch
Es ist nur etwas ungewöhnlich und docker exec -it ist deutlich einfacher.
Die Frage ist auch warum per SSH auf den Container? Um logs zu überprüfen ?
Verändern sollte man in einem Container meiner Meinung nach eh nichts (außer zum Testen) und stattdessen den Container so bauen, dass alles von Anfang an passt