Linux Bookworm - kein Remote ssh Zugriff mit Linux-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