Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Pandia]

Hallo zusammen,

ich habe ioBroker neu aufgesetzt. Basis OS ist Raspbian-Buster-Desktop. Über ioBroker/Java-Script sollen Befehle an QNAP NAS (pegasus)geschickt.

Die Authentifizierung (pi->NAS) erfolgt über Public Key. Das folgende Kommando auf der Konsole wird ordnungsgemäß ausgeführt:

pi@ioBroker1:~ $ ssh pegasus l- admin sudo /etc/init.d/container-station.sh start

Die Kommandos sollten jedoch aus einem ioBroker Java-Script gestartet werden. Erlaube das Kommando „exec“ im Java-Adapter ist aktiviert. Das Script korrekt ausgeführt.

Log Protokoll:

javascript.0 2019-11-09 12:13:47.235 info script.js.common.programs.QnapServices: exec: ssh pegasus -l admin sudo /etc/init.d/container-station.sh start

Der Befehl kommt jedoch nicht auf dem NAS an. Auf meiner früheren Installation hat es bereits funktioniert.

Worin unterscheidet sich die Ausführung des Kommandos auf der Konsole zum Java-Script-Exec? Habe ich etwas vergessen? Vielen Dank im Voraus.

[Glasfaser]

@Pandia

Kannst du das nicht mit diesem CodeSnipsel ausführen

PI3 durch ioBroker herunterfahren

[Marty56]

@Pandia Hast Du vielleicht die Rechte mit dem Fix Tool geändert. Danach funktionieren alle ssh Befehle natürlich nicht mehr. Man kann das ändern, in dem man das sudoers File nach dem Fix Tool Durchlauf ändert.

[Pandia]

Kurzer Zwischenstand: Ich konnte den Fehler soweit eingrenzen und eine Umgehungslösung schaffen. Hintergrund: Die ssh-Befehle werden vom User iobroker ausgeführt. Dieser verfügt bei neuen Installationen nicht mehr über die entsprechenden Rechte. Gleiches gilt auch, wenn das Fixer-Skript ausgeführt wurde.
Als Umgehungslösungen habe ich jetzt in der /etc/suders.d den Schutz des Users iobroker vollständig aufgehoben (iobroker ALL=(ALL:ALL) NOPASSWD: ALL), was dem eigentlichen Anliegen widerspricht.
Besser wäre, dem iobroker nur die Ausführung der ssh-Befehle zu erlauben. Leider waren alle Versuche bisher erfolglos.

Welches iobroker-Modul ist für die Ausführung verantwortlich?

[OliverIO]

@Pandia
zum besseren testen, ob die Befehle mit den Berechtigungen funktionieren,
kannst du die auf der Kommandozeile auch als iobroker ausführen

Mit dem folgenden Befehl startest du ein neues bash mit iobroker als user

sudo -u iobroker /bin/bash

unter welchem user liegen den deine ssh-keys auf deinem iobroker-rechner?
du musst ssh genau mit dem user ausführen, sonst findet er die keys nicht.
deinem post nach bist du der user pi

demnach müsste in sudoers so etwas drin stehen

iobroker  ALL = (pi) NOPASSWD: hier der ssh befehl

und ausführen dann mit

sudo -u pi hier dein ssh befehl

[Pandia]

@OliverIO

Auf dem iobroker-Rechner stehen für die User pi und iobroker ssh-keys zur Verfügung.

Folgendes ssh-Kommando soll auf dem Client ausgeführt werden: ssh pegasus -l admin sudo /etc/init.d/CloudLink.sh start

Habe unter /etc/suders.d/ die Datei iobroker_cumstom mit folgendem Inhalt angelegt:

iobroker ALL = (pi) NOPASSWD: ssh pegasus -l admin sudo /etc/init.d/CloudLink.sh start

Anschließend auf der Konsole versucht bash mit use iobroker zu starten:

pi@ioBroker0:~ $ sudo -u iobroker /bin/bash

/etc/sudoers.d/iobroker_custom: Syntax-Fehler near line 1 <<<
sudo: Syntax-Fehler in /etc/sudoers.d/iobroker_custom bei der Zeile 1
sudo: Keine gültige sudoers-Quelle gefunden, Programmende
sudo: Regelwerks-Plugin konnte nicht initialisiert werden
pi@ioBroker0:~ $

Hast du noch eine Idee?

[OliverIO]

@Pandia

und was ist das Ergebnis deines Versuchs?

1. kommst du auf die shell als user iobroker? Dann müsste im prompt iobroker@ioBroker1 stehen
2. wenn du auf der shell mit dem user iobroker angekommen bist, was ist das Ergebnis/Fehlermeldung deines ssh befehls?
   Also ssh pegasus -l admin sudo /etc/init.d/CloudLink.sh start

[Pandia]

@OliverIO

Ich komme nicht auf die shell als iobroker. Syntax-Fehler:

/etc/sudoers.d/iobroker_custom: Syntax-Fehler near line 1 <<<
sudo: Syntax-Fehler in /etc/sudoers.d/iobroker_custom bei der Zeile 1
sudo: Keine gültige sudoers-Quelle gefunden, Programmende
sudo: Regelwerks-Plugin konnte nicht initialisiert werden
pi@ioBroker0:~ $

[Pandia]

@OliverIO

Habe den fehlerhaften Eintrag in der /etc/sudoers.d/iobroker_custom gelöscht. Shell wurde initialisiert. Die ssh-Kommandos werden korrekt auf dem Client ausgeführt.

Die Ausführung durch das Java-Skript geht nicht durch.

Hier der Auszug aus dem iobroker-Log:

[AlCalzone]

@Pandia Hast du nach dem Löschen den Skript-Adapter oder gar den Host mal neu gestartet?

[OliverIO]

@Pandia

bose böse, diese datei mit einem normalen editor zu bearbeiten
https://wiki.ubuntuusers.de/sudo/Konfiguration/
lese insbesondere den roten kasten
da steht dann auch genau drin wie die datei sudoers aufgebaut ist.
ich habe das oben auch nur adaptiert, evtl. ist mir auch ein fehler passiert, wegen was der syntax fehler kommt

[OliverIO]

@Pandia
dann musst du um diese uhrzeit mal in der syslog nachschauen, ob da Fehler auftauchen
oder es scheint noch einen unterschied zu geben, wie iobroker shell komandos ausführt.

[OliverIO]

@Pandia
noch eine frage, da du ja sudo auf dem anderen rechner ausführst.
da wird kein passwort benötigt?
Ich weiß im LAN ist das mit der Sicherheit nicht ganz so dramatisch.
ideal wäre, wenn auf dem anderer Rechner ein eigener (technischer) user existiert,
der genau die Kommandos ausführen darf die du möchtest und das ohne passwort.
also auf dem anderen Rechner ebenfalls die sudoers pflegen
mit ssh meldest du dich dann direkt als dieser user an.

in deinem beispiel meldest du dich als user admin auf dem anderen rechner an und machst sudo um höhere rechte zu bekommen. ist das notwendig?

[Pandia]

@AlCalzone

Habe nach dem Löschen den Skript-Adapter und Host neu gestartet. Befehle gehen nicht durch.

[Pandia]

@OliverIO
Das Syslog des Host enthält zum Zeitpunkt der Ausführung keine Fehlermeldung. Was mich wundert. Es wird überhaupt nichts aufgezeichnet. Der Prozess muss schon vorher abbrechen.

[Pandia]

@OliverIO
Das sudo auf dem Host ist nicht zwingend notwendig, da der User admin über die entsprechenden Rechte verfügt. Der Prozess lässt sich im Nachgang noch sicherer gestalten. Der Aufruf vom Host muss erst mal richtig ankommen.