FHEM Forum

Hallo,
ich habe ein Problem mit meiner sudoers.

Die Datei sieht so aus:
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL
nuc     ALL=(ALL) NOPASSWD: ALL
fhem    ALL=(ALL) NOPASSWD: ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Fhem läuft unter unter dem user "fhem".

Wenn ich allerdings versuche shell Kommanos, oder Script aus Fhem heraus auszuführen, kommt im Log:
Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die
Regeln erklärt hat.  Normalerweise läuft es auf drei Regeln hinaus:

    #1) Respektieren Sie die Privatsphäre anderer.
    #2) Denken Sie nach, bevor Sie tippen.
    #3) Mit großer Macht kommt große Verantwortung.

sudo: Kein TTY vorhanden und kein »askpass«-Programm angegeben

und der Befehl schlägt fehl.

Worin liegt mein Problem?

Hi,

zum Einen wäre lesen nicht schlecht:

Zitat# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.

Zum Zweiten empfehle ich mehr Selektivität  :o -> fhem    ALL=(ALL) NOPASSWD: ALL
Und zum Schluss: In Abhängigkeit vom System, muss man einmal das Passwort angeben und diesen Meldungstext/Hinweis quittieren. Ich weiß leider nicht, wo man das ausschalten kann.

Gruß Otto

Hallo Otto, zunächst Danke für die Hinweise.

Meine sudoers habe ich nur der Einfachheit halber direkt (mit visudo) editiert. Ein separates file in sudoers.d hatte ich vorher schon getestet, leider auch ohne Erfolg. Ebenso wollte ich mit ALL=(ALL) anfangen, um überhaupt erstmal ein positives Ergebnis zu haben. Danach wäre dann verfeinern dran gewesen.
Aber wie gesagt, soweit komme ich nicht. Der sture Bock will einfach ein sodu Passwort haben, egal was ich in die sudoers schreibe...

wie gesagt, sudoers einrichten, einmal anmelden, sudo ausführen, Passwort eingeben und den Hinweis bestätigen.
Danach sollte es ohne Passwort Abfrage gehen.
Kannst ja das Ganze erstmal mit einem anderen Konto (nuc) probieren.

Übrigens: Der Einfachheit halber werden 90% der Systeme entsichert und nie wieder gesichert - man ist ja froh das es geht  ::)

So, das Thema ist gelöst!

Es lag einfach nur daran, das der User "fhem" noch überhaupt keine passwort gesetzt hatte.

Braucht er aber auch nicht dauerhaft :)
Ach ja, ich hatte das schon mal aufgeschrieben  (https://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html):)

Gruß Otto

Hallo zusammen,

ich habe genau das gleiche Problem, habe nach Ottos Anleitung für den User fhem ein Passwort vergeben. Ein su fhem macht genau gar nichts, der prompt bleibt beim User, der angemeldet ist. Ein Userwechsel über das System ging, ebenso das anmelden des Users fhem mit dem vergebenen Passwort. Einmal rebootet. Trotzdem die Fehlermeldung


Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die Regeln erklärt hat. Normalerweise läuft es auf drei Regeln hinaus: #1) Respektieren Sie die Privatsphäre anderer. #2) Denken Sie nach, bevor Sie tippen. #3) Mit großer Macht kommt große Verantwortung. sudo: Zum Lesen des Passworts ist ein Terminal erforderlich; verwenden Sie entweder die Option -S, um aus der Standardeingabe zu lesen oder richten Sie das Askpass-Hilfsprogramm ein sudo: Ein Passwort ist notwendig
System ist Debian 11 Bullseye

Was kann man da noch machen ?

Grüße

Chrsitian

sudo <> su ....

Hi,

Zitat von: cs-online am 28 November 2025, 20:56:22ich habe genau das gleiche Problem,

Du meinst Du willst aus fhem heraus Befehle auf der gleichen Maschine mit sudo ausführen? Das hatte ich hier  (https://heinz-otto.blogspot.com/2017/08/raspberry-ausschalten-mit-fhem.html)mal aufgeschrieben.

Zitat von: cs-online am 28 November 2025, 20:56:22Ein su fhem macht genau gar nichts, der prompt bleibt beim User, der angemeldet ist. Ein Userwechsel über das System ging, ebenso das anmelden des Users fhem mit dem vergebenen Passwort.

Das verstehe ich nicht, klingt irgendwie verwirrend. Bei su fhem sollte er nach dem Passwort fragen.

Allerdings kann man auch ohne fhem ein Passwort zu geben als user fhem arbeiten:
sudo -su fhem
Gruß Otto

Hallo Otto,

ich habe Probleme mit dem Start meiner beiden EBUSD-Services. Das war schon auf dem RPI so und das ist leider nun auch unter Proxmox, FHEM auf einer VM mit DebianEDU 11, alles auf einem Dell Thinclient so. Irgendwas beisst sich hier halt. Von Hand einmal den Service neu angestartet mit "systemctl start ebusd", dann fängt sich das meist. Ich hatte auf dem RPI zwei SERVICED-Devices, eines für jede Ebusd Instanz. Konnte ich da so anstarten. Nun auf dem TC kommt immer der Fehler:

Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die Regeln erklärt hat. Normalerweise läuft es auf drei Regeln hinaus: #1) Respektieren Sie die Privatsphäre anderer. #2) Denken Sie nach, bevor Sie tippen. #3) Mit großer Macht kommt große Verantwortung. sudo: Zum Lesen des Passworts ist ein Terminal erforderlich; verwenden Sie entweder die Option -S, um aus der Standardeingabe zu lesen oder richten Sie das Askpass-Hilfsprogramm ein sudo: Ein Passwort ist notwendig
Ich habe mittels "visudo /etc/sudoers" ergänzt:

fhem ALL=(ALL) NOPASSWD: /usr/bin/systemctl
ein "which systemctl" hat den Pfad ausgegeben.

Ich habe ohne PW vorher probiert, ich habe, wie mein Vorredner, auch ein PW vergeben, ich habe x-mal neu gestartet...

Terminal startet mit "root@fhem", wenn ich "su fhem" eingebe, passiert nichts, es kommt wieder "root@fhem". Ein "sudo -su fhem" gibt dann ein "fhem@fhem:/root$". Eine PW-Abfrage kommt in keinem der Fälle...

Ich kenne mich nur knapp oberflächlich mit Linux aus, ich blicke hier nicht mehr durch... Bin für jede Hilfe dankbar !

Grüße

Christian

Hallo Christian,

ich zitiere mal explizit meinen Text

Zitat/usr/sbin -> für alles im Verzeichnis
/usr/sbin/service * -> für alle Parameter
/usr/sbin/service apache2 * -> für alle weiteren Parameter
/usr/sbin/service apache2 reload -> genau nur hierfür

Wirklich so schwierig? Ich würde es so versuchen:
fhem ALL=(ALL) NOPASSWD: /usr/bin/systemctl *

Übrigens:

ZitatIch habe mittels "visudo /etc/sudoers" ergänzt:

macht "man" nicht ;) - aber egal.

Hallo Otto,

ja, ist leider wirklich schwierig, wenn man eben wenig mit Linux zu tun hat und da nicht durchblickt, was da was ist. Dazu benutze ich das leider auch zu selten, um das wirklich zu verinnerlichen. Muss ich schon mal hinbekommen haben, auf dem alten RPI ging es ja...

fhem ALL=(ALL) NOPASSWD: /usr/bin/systemctl *
Habe ich probiert, bringt aber leider keine Änderung :-(

Grüße

Christian

ist denn der User fhem überhaupt in der Gruppe sudo?
Für die FHEM Kommandozeile
{qx(groups)}Läuft FHEM überhaupt mit User fhem?
{qx(whoami)}

{qx(groups)} gibt

dialout sudo

{qx(whoami)} gibt "fhem"

...was kann ich noch testen ?

Was habe ich jetzt im Terminal auf einem Pi mit Debian 11 getestet:
sudo nano /etc/sudoers.d/011_fhem-nopasswd # hier die Zeile eingefügt: fhem ALL=(ALL) NOPASSWD: /usr/bin/systemctl *
sudo adduser fhem sudo
sudo -su fhem
sudo systemctl restart systemd-timesyncd.service
Funktioniert wie erwartet :)

Copilot meint, dass es keine Unterschiede in der Behandlung von sudo bei der DebianEDU 11 Version gibt.  ::)

Zeig mal den Inhalt Deiner sudoers:
sudo cat /etc/sudoers
Der sollte so aussehen und mMn auch so bleiben!

Zitat# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d

hier meine sudoers:

root@fhem:~# sudo cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL
fhem    ALL=(ALL) NOPASSWD: ALL
fhem    ALL=(ALL) NOPASSWD: /usr/bin/systemctl *



# Allow members of group sudo to execute any command
%sudo    ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d
root@fhem:~#

Sollte ich mal die fhem-Teile dort wieder raus nehmen und so probieren, wie in deinem Fenster ?

Naja ich kann sagen, was ich da gemacht habe funktioniert. Ich sehe bei Dir nicht auf Anhieb einen Fehler, das sagt aber nichts ;)

Versuch es doch.

Irgendwie scheint es ja, als ob Deine Einträge in der sudoers Datei nicht wirken. Wobei Du gesagt hast, du hast visudo zum Bearbeiten verwendet. Diese Tool prüft den Syntax der Datei und setzt die Berechtigungen richtig.

Ich verstehe nicht warum das nicht funktionieren soll. Das System debianEDU hat laut Auskunft im Internet auch keine Besonderheiten.

Zitat von: Otto123 am 03 Dezember 2025, 09:53:21Was habe ich jetzt im Terminal auf einem Pi mit Debian 11 getestet:

Code Auswählen Erweitern

sudo nano /etc/sudoers.d/011_fhem-nopasswd # hier die Zeile eingefügt: fhem ALL=(ALL) NOPASSWD: /usr/bin/systemctl *
sudo adduser fhem sudo
sudo -su fhem
sudo systemctl restart systemd-timesyncd.service

Hallo Otto,

ich habe jetzt alles aus der sudoers rausgenommen, was mit FHEM zu tun hatte und dann mit dem oben von dir probiert und voila, jetzt scheint es zu funktionieren :-)

Super vielen Dank für deine Unterstützung, das hätte ich allein nie hinbekommen und ich hoffe, ich kann mir das für das nächste Mal merken ;-)

Liebe Grüße

Christian

Also folgende Zeile:
sudo adduser fhem sudoMacht eigentlich keinen Sinn, da Du schon davor dem User fhem alle Rechte gegeben hast. Probiere es einfach, in dem Du die Gruppe mal wieder rausnimmst.
%sudo    ALL=(ALL:ALL) ALLGenau für diese Zeile ist die Gruppe sudo da.

Hallo Wernieman,

ja, an der Stelle kam auch die Meldung, daß fhem schon Mitglied in sudo ist.

Grüße Christian

Der Werner meint was anderes und da lag ich auch bisher immer falsch. Wenn man einem User (oder Gruppe) explizit bestimmte Rechte in einer Datei in sudoers.d/ gibt, muss man den Benutzer nicht extra noch in die Gruppe sudo stecken.

Die Gruppe sudo ist der vorgegebene Fall und als Gruppenmitglied kann man zwar alles machen, aber das Passwort wird gefragt.

Danke Werner für den Hinweis, hoffentlich verschwindet das nicht wieder aus meinem Kopf. :)