Per LBS Skript auf einem anderen Linux Rechner starten

[murelli146]

Hab es über Edomi UDP Befehl senden und Script gelöst.

Leider scheinen neuere Raspi Images nicht mit dem LBS zu funktionieren. (bzw. SSH2 Versionen)

Bildschirmfoto 2017-10-07 um 20.05.02.png

/home/pi/.local/bin/udp.py anlegen

#!/usr/bin/python3 -u
import socket
import os

UDP_IP = "192.168.1.110"
UDP_PORT = 33333

sock = socket.socket(socket.AF_INET, # Internet
                    socket.SOCK_DGRAM) # UDP
sock.bind((UDP_IP, UDP_PORT))

while True:
    data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes
    if 'OFF' in data:
        os.system('xset -display :0 dpms force off')
    elif 'ON' in data:
        os.system('xset -display :0 dpms force on -dpms s off s noblank')

"chmod a+x /home/pi/.local/bin/udp.py"

Eleganter wäre es mit LBS.

Schöne Grüße
Gernot

[jonofe]

Habe mit das mit dem ssh2 LBS noch mal angeschaut. Es liegt wohl an der eingeschränkten Unterstüzung von key exchange Algorithmen der php ssh2 Library.

Wenn man auf dem Zielserver die /etc/ssh/sshd_config öffnet

sudo nano /etc/init.d/sshd_config

und folgendes am Ende einfügt:

KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr

und dann speichert und den sshd neu startet (auf dem RPI wie folgt):

sudo /etc/init.d/ssh restart

Dann sollte SSH2 auch mit dem LBS funktionieren.

[murelli146]

Danke für die Info dann werde ich mich bei Gelegenheit doch noch über den LBS hermachen. Würde eine menge externe Scripte sparen.

[saegefisch]

Hallo André,
der LBS funktioniert prima, danke.
Auch bei mir klappte der ssh-Zugriff auf der Konsole direkt, aber für den LBS musste ich die /etc/ssh/sshd_config (Ubuntu) anpassen und ergänzen um Ciphers und KEX. Zunächst versuchte ich es aber ohne "diffie-hellman-group1-sha1" - denn das ist eigentlich weder zeitgemäß noch empfehlenswert. Allerdings war ich am Ende nur erfolgreich genau damit und hab' es letztlich doch aufgenommen. Das liegt wohl daran, dass libssh2 in Version 1.4.2 installiert wird. Gibt es eine höherwertigere Methode für den Schlüssel-Austausch, die ich nur nicht gefunden habe oder hängen wir da am betagten CentOS?

Zwei eher unwichtige Kleinigkeiten:
* Anmerkung im Hilfetext wäre hilfreich, dass der Trigger des Sendens auf E6 ist
* Müsste es bei den KEX-Methoden im Coding bei der 3. Option nicht "diffie-hellman-group-exchange-sha256" statt "diffie-hellman-group-exchange-sha1" heißen?

Schlüsselwörter für Forensuche: TVH, systemctl restart tvheadend.service, status, Dienst

Ergänzung Anmerkung für andere mit ähnlichen Zielen: Auf dem remote-System sollte man für den remote-Zugang einen eigenen User anlegen. Dem kann man auch sudo zuordnen, aber dann in /etc/sudoers per visudo so beschränken, dass es nur explizite Dinge ohne weitere Passwörter ausführen darf. Es gäbe sicher auch andere Lösungen, aber ich würde keine nutzen wollen, die per root funktioniert.

[wintermute]

hängen wir da am betagten CentOS?

Probier doch einfach gemaess Anleitung hier irgendwo im Forum ein "yum update" um das gesamte BAsis-System anzuheben, das sollte (eigentlich) helfen.

[saegefisch]

Danke Michael, da hatte ich auch schon dran gedacht. Aber es dann verworfen - eigentlich mag ich das nicht machen - keep ist stupid simple. Nah am Entwickler des Kernsystems zu belieben schient mir eine gute Idee. Dafür nehme ich auch die schlechter/nicht mehr gänzlich sichere Methode des Schlüsselaustauschs in Kauf. Auf dem remot liegen keine kritischen Daten. Die liegen im anderen VLAN auf NAS mit enger Berechtigung.

Ich hatte viel mehr gehofft, dass ich eine bessere Methode übersehen habe, die in 1.4.2 von libssh2 schon geht - das changelog ist spricht wenig dazu. Oder ich bin zu blöd dafür - darauf hoffte ich mit meiner Frage zu stoßen...

[givemeone]

Hallo, ist das eigentlich der offizielle Thread zum SSH-Baustein??? ;-)

Habe keinen besseren gefunden!

Ich habe das Problem, dass ein Sat-Reciver nur Passwort-Autentifizierung erlaubt (und das sogar nur ohne Passwort).
Ist halt so.
Könnte man den Baustein noch ergänzen um eine Passwertabfrage?

Ich habe ihn im Moment so gepatcht, dass bei leerem Key-File (E4)
einfach auf

$auth = ssh2_auth_password ($connection, $user,'' );

umgeschalten wird.
Klappt, aber da es a nicht mein Baustein ist....?!?

sG
Joe

[jonofe]

Könnte man den Baustein noch ergänzen um eine Passwertabfrage?

Die Version 0.5 kann das jetzt. Default ist PublicKey-Authentication. Wenn diese nicht erfolgreich ist oder die Keys nicht existieren (E5/E6 sind leer), wird Password Authentication durchgeführt.

[givemeone]

Die Version 0.5 kann das jetzt. Default ist PublicKey-Authentication. Wenn diese nicht erfolgreich ist oder die Keys nicht existieren (E5/E6 sind leer), wird Password Authentication durchgeführt.

Top, vielen Dank! Gerade getestet, klappt perfekt!!