Weihnachtsangebot 2025! 🎄

[mickym]

Ich bin leider zu blöde und deswegen brauche ich nach ewigen erfolglosen Suchen etwas Hilfe.

Ich habe nun beide Raspberries auf bookworm upgegraded. Auf meinem Gateway lief openvpn - das habe ich auch nicht upgegraded - da dann der Zugriff nicht mehr funktioniert. Ich hab das nun auf onhold gesetzt - wie in dem Artikel empfohlen :

https://www.rebelstreamers.com/2023/06/debian-12-bookworm-openvpn-hotfix-and.html

Allerdings bei dem Zugriff via SSH verwzeifle ich.

So produktiv bin ich nun wieder zurück auf bullseye. Eigentlich ist es schade, dass man immer neue Sicherheitfeatures in neue Releases einbaut aber keine anständige Migration oder zumindest Migrationsanleitung zur Verfügung stellt.

Eigentlich funktioniert alles noch auf Kommandozeile - aber auch zum Beispiel von fhem. Mit dem Linux Adapter aber nicht mehr.

2023-07-19 02:25:54.703 - info: linux-control.0 (68316) getting data from MWIPv6GW (192.168.178.200:22, Adapter start)
2023-07-19 02:25:54.704 - info: linux-control.0 (68316) getting data from MWHome (localhost:22, Adapter start)
2023-07-19 02:25:55.251 - error: linux-control.0 (68316) [getConnection] Could not establish a connection to 'MWIPv6GW' (192.168.178.200:22)!
2023-07-19 02:25:55.272 - error: linux-control.0 (68316) [getConnection] error: All configured authentication methods failed, stack: Error: All configured authentication methods failed
at doNextAuth (/opt/iobroker/node_modules/ssh2/lib/client.js:413:17)
at tryNextAuth (/opt/iobroker/node_modules/ssh2/lib/client.js:484:5)
at SSH2Stream.onUSERAUTH_FAILURE (/opt/iobroker/node_modules/ssh2/lib/client.js:597:5)
at SSH2Stream.emit (node:events:513:28)
at SSH2Stream.emit (node:domain:489:12)
at parsePacket (/opt/iobroker/node_modules/ssh2-streams/lib/ssh.js:3682:10)
at SSH2Stream._transform (/opt/iobroker/node_modules/ssh2-streams/lib/ssh.js:701:13)
at SSH2Stream.Transform._write (node:internal/streams/transform:175:8)
at writeOrBuffer (node:internal/streams/writable:392:12)
at _write (node:internal/streams/writable:333:10)
at SSH2Stream.Writable.write (node:internal/streams/writable:337:10)
at Socket.ondata (node:internal/streams/readable:766:22)
at Socket.emit (node:events:513:28)
at Socket.emit (node:domain:489:12)
at addChunk (node:internal/streams/readable:324:12)
at readableAddChunk (node:internal/streams/readable:297:9)
2023-07-19 02:26:05.811 - info: linux-control.0 (68316) successful received data from MWHome (localhost:22)

liegt eindeutig an Änderungen in Bookworm - was ich nicht verstehe, dass aber auf der Kommandozeile die Authentifizierung klappt.

Ansonsten muss ich halt wieder zurück gehen.

Die Konfig passt eigentlich:

[Thomas Braun]

@mickym

Funktioniert die Version aus proposed-updates nicht?

Ansonsten warte bis zum ersten PointRelease 12.1

[Ein ehemaliger Benutzer]

@mickym

hmm das hier installiert??

bei mir laufen alle Container inzwischen mit Bookworm unter Proxmox und dem Linux-Adapter..
sollte also kein generelles Problem sein..

[BananaJoe]

@mickym ich bin nicht ganz sicher ob ich deinen Fehler verstehe:
Du kannst dich per SSH nicht mehr Remote an einem entfernten System anmelden welches du ebenfalls geupgraded hast?

Wie sieht denn dein Public-Key aus den du auf dem anderem System in der .ssh/authorized_keys2 hinterlässt?
Zufällig steht da ganz vorne noch ssh-rsa?

Das mögen neuere Distributionen nicht mehr, mein RSA-Key aus 2016 funktioniert bei aktuellen Systemen nicht mehr.
ich habe mit puTTY-Gen mir einen ecdsa-sha2-nistp256 generiert, der geht.

[mickym]

@bananajoe sagte in Linux Bookworm - kein Remote ssh Zugriff mit Linux-Adapter:

Du kannst dich per SSH nicht mehr Remote an einem entfernten System anmelden welches du ebenfalls geupgraded hast?

Doch wenn ich mich per Kommandozeile via ssh auf das entfernte System schalte geht es - nur der Adapter will nicht mehr.

[Ein ehemaliger Benutzer]

@mickym sagte in Linux Bookworm - kein Remote ssh Zugriff mit Linux-Adapter:

• nur der Adapter will nicht mehr.

Moin,

ok, dann ist ja die zweite Frage von @BananaJoe noch offen, ist Dein Schlüssel, den Du als pi unter /opt/iobroker/.ssh/id_ras nutzt ok? Und wenn Du Dich von einem anderen Rechner auf die entfernte Kiste per ssh verbindest, wie sieht auf diesem der id_ras aus.
Im Zweifel mal einen neuen Key generieren und testen.

VG
Bernd

[mickym]

@dp20eic Das mit dem neuen Key habe ich auch schon probiert - das hat nichts gebracht. - Ich hab dann bissi gelesen und so eine config Datei angelegt.

Das hatte ich auch schon probiert: https://serverfault.com/questions/1106758/ssh2-fails-authentication-with-a-working-key-converted-with-puttygen-due-to-dep

PubkeyAcceptedKeyTypes=+ssh-rsa

Ein lokales config File habe ich auch schon versucht. Im Prinzip funktioniert die Authentifizierung ja auf der Kommandozeile - aber halt nicht mit dem Adapter.

Ich kanns aber im Moment leider nicht testen. Eine Neuerstellung der Schlüssel war auch nicht erfolgreich. Ich habs aber wieder zurückgedreht.

Ich probier nochmal die config.ssh auf der Client Seite zu ändern. Das hatte ich glaub noch nicht probiert.

[BananaJoe]

@mickym der Adapter läuft ja als Benutzer iobroker, hast du mal unter dem Benutzer auf der Shell/Bash getestet?
per

sudo -u iobroker /usr/bin/bash

bekomme ich zumindest bei mir ein Shell als dieser Benutzer

[mickym]

@bananajoe Ja das .ssh Verzeichnis mit den keys ist unter dem Homeverzeichnis des Benutzers iobrokers angelegt. Wie gesagt - das Teil funktioniert ja auch - erst nachdem ich das Zielsystem auf bookworm upgegraded habe, habe ich diese Probleme. Prinzipiell funktioniert unter bullseye - sowohl die Kommandozeile, also auch der Adapter problemlos.

Deswegen liegt es mE nicht an der Struktur - sondern das bookworm irgendeine Verschärfung der Sicherheitseinstellungen eingeführt hat.

Grundsätzlich kann ich zum Beispiel auch als User- Iobroker über die Kommandozeile update vom pihole machen - das funktioniert alles. Deswegen habe ich kein prinzipielles Problem - sondern ich sehe eh das Problem mit der id_rsa Datei und dem Adapter.

[BananaJoe]

@mickym sagte in Linux Bookworm - kein Remote ssh Zugriff mit Linux-Adapter:

Deswegen liegt es mE nicht an der Struktur - sondern das bookworm irgendeine Verschärfung der Sicherheitseinstellungen eingeführt hat.

Womit wir uns wieder im Kreis bewegen. Funktioniert es als Benutzer ioBroker in der Shell?
Wenn nein kann es doch der Typ der id sein, denn genau da gab es zum Beispiel Verschärfungen so das ältere, unsichere Schlüssel nicht mehr erlaubt sind. ok, es funktioniert

Alternativ musst du dir die /etc/ssh/sshd_config auf dem Zielsystem anschauen und vergleichen was da geändert wurde von vorher zu nachher bzw. ggf. welche anderen Default-Werte gelten. Man kann das ja auch wieder zurückschrauben.

[mickym]

@bananajoe Ich glaub ich habs. ;)

Ja es war auf dem Zielsystem und ist tatsächlich die sshd_config. :) Ich habe es allerdings auf beiden Systemen Quell- und Zielsystem hinzugefügt.

ich hab zum Schluss diese Zeile hinzugefügt:

PubkeyAcceptedKeyTypes=+ssh-rsa

Jetzt funktioniert es:

2023-07-19 23:11:16.152 - info: linux-control.0 (182801) getting data from MWIPv6GW (192.168.178.200:22, Adapter start)
2023-07-19 23:11:16.154 - info: linux-control.0 (182801) getting data from MWHome (localhost:22, Adapter start)
2023-07-19 23:11:34.570 - info: linux-control.0 (182801) successful received data from MWHome (localhost:22)
2023-07-19 23:11:37.148 - info: linux-control.0 (182801) successful received data from MWIPv6GW (192.168.178.200:22)

MWIPv6GW ist das entfernte System, das nicht funktioniert hatte:

2023-07-19 23:08:59.638 - info: linux-control.0 (182089) getting data from MWIPv6GW (192.168.178.200:22, Adapter start)
2023-07-19 23:08:59.640 - info: linux-control.0 (182089) getting data from MWHome (localhost:22, Adapter start)
2023-07-19 23:09:00.084 - error: linux-control.0 (182089) [getConnection] Could not establish a connection to 'MWIPv6GW' (192.168.178.200:22)!
2023-07-19 23:09:00.110 - error: linux-control.0 (182089) [getConnection] error: All configured authentication methods failed, stack: Error: All configured authentication methods failed
at doNextAuth (/opt/iobroker/node_modules/ssh2/lib/client.js:413:17)
at tryNextAuth (/opt/iobroker/node_modules/ssh2/lib/client.js:484:5)
at SSH2Stream.onUSERAUTH_FAILURE (/opt/iobroker/node_modules/ssh2/lib/client.js:597:5)
at SSH2Stream.emit (node:events:513:28)
at SSH2Stream.emit (node:domain:489:12)
at parsePacket (/opt/iobroker/node_modules/ssh2-streams/lib/ssh.js:3682:10)
at SSH2Stream._transform (/opt/iobroker/node_modules/ssh2-streams/lib/ssh.js:701:13)
at SSH2Stream.Transform._write (node:internal/streams/transform:175:8)
at writeOrBuffer (node:internal/streams/writable:392:12)
at _write (node:internal/streams/writable:333:10)
at SSH2Stream.Writable.write (node:internal/streams/writable:337:10)
at Socket.ondata (node:internal/streams/readable:766:22)
at Socket.emit (node:events:513:28)
at Socket.emit (node:domain:489:12)
at addChunk (node:internal/streams/readable:324:12)
at readableAddChunk (node:internal/streams/readable:297:9)

[mickym]

Jetzt ist nur noch das openvpn Problem offen. Aber das hat mit dem Tread nichts zu tun. :)

[BananaJoe]

@mickym sagte in Linux Bookworm - kein Remote ssh Zugriff mit Linux-Adapter:

ch hab zum Schluss diese Zeile hinzugefügt:
PubkeyAcceptedKeyTypes=+ssh-rsa

also war es doch ein veralteter Schlüssel / eine zu niedrige Verschlüsslungstiefe. Hätte man auch mit einem neuen RSA Key lösen können.

[mickym]

@bananajoe Das hatte ich aber schon versucht - da wurde aber in meinen Augen wieder der gleiche Schlüssel erzeugt. Und was ich nicht verstehe - ist dass es die Kommandozeile immer funktioniert hat.

Kannst Du mir erklären was der Unterschied zwischen ssh und sshd ist? Der Service und der Prozess ist der Gleiche.

[BananaJoe]

@mickym sagte in Linux Bookworm - kein Remote ssh Zugriff mit Linux-Adapter:

da wurde aber in meinen Augen wieder der gleiche Schlüssel erzeugt

das kann ja sein. Ich muss zugeben das ich das direkt auf der Shell auch noch nicht gemacht habe, ich hatte den Fall ja unter Windows das ich per puTTY nicht mehr drauf kam. In puTTYgen kann ich die Parameter ja in einer "Klicky-Bunti" Oberfläche wählen und hab die Verschlüsslungstiefe hochgesetzt.

Ich meine für die Erzeugung gibt es bestimmt auch irgendwo eine Default-Datei. Die könnte bei einem Inplace-Upgrade natürlich erhalten geblieben sein.

[mickym]

@bananajoe Ich hatte gestern extra unter bookworm auch die Schlüssel nach der Originalanleitung neu gemacht:

https://www.server-world.info/en/note?os=Debian_12&p=ssh&f=4
und hat auch nicht funktioniert.

Aber Hauptsache es geht jetzt. Diese Sicherheit ist in meinem privaten Heimnetz in meinen Augen nicht relevant. Ich arbeite ja auch mit http - da ich weiß (oder wissen sollte) was bei mir im privaten Netz vor sich geht. Deswegen finde ich solche Änderungen immer ein Problem. Sowas könnte man doch bei der Migration mitberücksichtigen zu dem man ja diesen Parameter eintragen kann.

Das mit dem OpenVPN ist ja auch so ein Ding. Ich meine wenn Du jetzt viele Zertifikate für Clients erstellt hast, dann ist das doch ein hoher Aufwand. Also im Moment bleibt auch auf der bookworm Maschine - das openvpn auf der alten Version.

openvpn:
  Installiert:           2.5.1-3
  Installationskandidat: 2.6.3-1
  Versionstabelle:
     2.6.3-1 500
        500 http://raspbian.raspberrypi.org/raspbian bookworm/main armhf Packages
 *** 2.5.1-3 100
        100 /var/lib/dpkg/status

Ansonsten muss man pihole nochmal rekonfigurieren lassen, nginx hat die Migration gut überstanden.

[fastfoot]

@mickym ich hab das mal probiert und es funktioniert definitiv!

• auf dem Zielrechner muss ein ssh server laufen, ich habe openssh-server installiert
• ohne weitere Konfiguration mit service ssh start starten
• dieser server erwartet den öffentlichen key(id_xxxx.pub) in /home/user/.ssh/authorized_keys
  • der hierhin kopierte key kann einfach umbenannt werden, evtl weitere keys mit cat neuer_key >> authorized_keys hinzufügen

auf dem Rechner mit linux-control

• den privaten key (id_xxxxx ohne .pub) an einen geigneten Ort ablegen, /opt/iobroker/.ssh scheint ok aber auch egal weil hier nicht der ssh client verwendet wird wenn ich das richtig sehe. Im test war er aber genau dort
• im setup bei passwort nicht das userpasswort eingeben sondern das Passwort mit dem der key beim Erstellen verschlüsselt wurde

Adapter starten und sich freuen. Beide Systeme haben bookworm und node20

[mickym]

@fastfoot Ja wie gesagt - das ist alles so und auf der Kommandozeile funktioniert e alles. Der Service funktionierte und auch was Du zu den authorized_keys sagst, das hat alles gepasst.

die Schlüssel wurden auch alle dahin kopiert:

Ich hab dieses scp Kommando verwendet und das hat alles funktioniert. Auch die user haben ihren privaten Schlüssel alle im .ssh Verzeichnis unter den Home-Verzeichnissen.

iobroker@mwhome:~/.ssh $ ls -la
insgesamt 60
drwxr-xr-x  2 iobroker iobroker  4096 19. Jul 02:39 .
drwxr-xr-x 12 iobroker iobroker  4096 19. Jul 01:53 ..
-rw-------  1 iobroker iobroker  3381  9. Aug 2022  id_rsa
-rw-r--r--  1 iobroker iobroker   741  9. Aug 2022  id_rsa.pub
-rw-r--r--  1 iobroker iobroker 38184 20. Jun 00:11 known_hosts
-rw-r--r--  1 iobroker iobroker   741 19. Jul 00:25 pi@mwipv6gw

Ich habe grundsätzlich kein Passwort bei den Keys verwendet. Wie gesagt - auf der Kommandozeile hatte der Zugriff funktioniert. Zur Generierung hatte ich einfach das

ssh-keygen

verwendet. - Na egal - mit der Modifikation in der sshd_config - geht es erst mal.

[fastfoot]

@mickym ich denke dann kommt das davon dass du ein 'altes' System auf Bookworm geupdatet hast und dann auch die config schon älter war. meine Systeme wurden schon mit Bookworm erstellt, ist ja im Container recht einfach. Aber Hauptsache es funktioniert jetzt