Per LBS Skript auf einem anderen Linux Rechner starten

[Brick]

Micha.. das wars:
dieser Tipp in deinem Link hat geholfen:
"There I discovered that it was an folder rights issue, to my suprise actually. But after an offensive testing I discovered it was on the users home folder itself. Not on the .ssh or authorized_keys.
The users home folder ~/ is not allowed to be writable to group and other, "chmod 755 /volume1/homes/user: should do the trick."

jetzt bau ich mal das wieder mit dem LBS nach.. also das Pub File.. usw.. mal schaun, ob das geht...

EDIT: GEHT !!! super.. vielen Dank für die Tipps !!

Jetzt noch schauen ob mein Skript läuft.. dann bin ich zufrieden

[jonofe]

Mit putty hatte ich auch nur Probleme, da es unterschiedliche Arten von Keys gibt.

Am besten mal Keys direkt auf dem EDOMI Server erstellen auf der Konsole

ssh-keygen -t rsa -b 4096

An E4 und E5 des LBS musst du den kompletten Pfad zu den public und private Key Files angeben, nicht die Keys selbst. /root/.ssh/id_rsa.pub|key

Und natürlich das pub File auf die Synology kopieren. und mit

cat id_rsa.pub >> ~/.ssh/authorized_keys

[Brick]

Leute, es funktioniert !!

PERFEKT !!

[jonofe]

Super!

[murelli146]

jonofe bräuchte auch noch etwas Hilfe mit deinem ssh2 LBS.

Hab alles lt Anleitung installiert.

Ich möchte den Touchscreen am Raspi über ssh LBS ein und ausschalten.

Über die Konsole funktioniert es:

[root@edomi ~]# ssh 'root@192.168.179.110'

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Mar 23 21:18:27 2017 from edomi.fritz.box
root@raspberrypi:~# xset -display :0 dpms force off
root@raspberrypi:~# xset -display :0 dpms force on
root@raspberrypi:~#

Aber über den LBS setze ich die Befehle nicht ab.

ssh2.PNG

ssh2 log.PNG

Irgendwas übersehe ich.?

[jonofe]

Vorausgesetzt, dass die Public/Private-Keyfiles an der richtigen Stelle liegen und das Public-Key-File auch auf dem Zielserver an das ~/.ssh/authorized_keys File angehängt wurde, dann scheint irgendetwas mit der Verschlüsselung oder Kompression nicht zusammen zu passen.

Kannst mal ein "ssh -Cv root@<raspi-IP>" auf deinem EDOMI Server machen und die Ausgabe hier posten.

Welches OS-Distribution läuft dem RPi?

[murelli146]

[root@edomi ~]# ssh -Cv root@192.168.179.110
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.179.110 [192.168.179.110] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-sha1 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.179.110' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 533
debug1: read PEM private key done: type RSA
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Mar 23 22:00:05 2017 from edomi.fritz.box
root@raspberrypi:~#

Ich verwende 2017-03-02-raspbian-jessie-lite Image auf dem Raspi.

Beim erstellen der Keys habe ich alles mit Enter bestätigt, also keine " passphrase".

Den Key habe ich mit dem Befehl "ssh-copy-id -i .ssh/id_rsa.pub root@raspi_ip" auf dem Raspi aktiviert.

[murelli146]

ssh2_Errlog.PNG
Das spukt der Errorlog noch aus

[jonofe]

Ich denke die key-exchange Algorithmen passen nicht zusammen.
Versuch mal Zeile 121 im LBS wie folgt zu ändern:

'kex' => 'diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1', 

[murelli146]

Leider selbes Ergebnis mit den Errors wie oben.

[Toni380]

Hallo leider habe ich den gleichen Error Murelli146 nun mittlerweile
gibt es da schon irgend wie eine Lösung für ?

[ChrisP]

ich habe meinen Beitrag mal etwas erweitert... Ist eine ganz simple Lösung welches mit UDP Messages arbeitet welche ja von Edomi unterstützt werden.
https://knx-user-forum.de/forum/proj...f%C3%BCr-linux

[Toni380]

eigentlich schade lief die ganze zeit bei mir zuverlässig bis ich meinen server ein update gegönt habe.

[murelli146]

Mein Projekt mit dem Display steht auch noch. Vielleicht gibt es doch noch einen Lösungsweg?

[Glotzkowski]

murelli146 ist das "Projekt" nach einem halben Jahr noch aktuell?

Ich nutze auch einen Touchscreen am RPi und habe es soeben mit der Funktion SHELL-Befehl gelöst.
Den Baustein habe ich noch nicht getestet, weil ich in diesem Fall keinen Mehrwehr darin sehe einen LBS zu nutzen, für andere Fälle mag dieser prima sein, da bin ich aber noch nicht angekommen.

Klappt es denn bei Dir, wenn Du von EDOMI ausgehend per SSH direkt das xset ausführst?

Für den SHELL-Befehl habe ich in EDOMI lediglich folgendes eingetragen (natürlich vorher RSA-Keys auf EDOMI erstellt und den public key als authorized key auf dem RPi für den Benutzer touchscreen definiert):
ssh touchscreen@touchscreen-desktop xset -display :0.0 dpms force on