[Gelöst] Logeinträge: 42_SYSMON.pm Permission denied, please try again.

Begonnen von Hackstall, 13 August 2020, 21:09:35

Vorheriges Thema - Nächstes Thema

kadettilac89

#15
dann war der Link zum Windows ssh Einrichten irreführend.

Das ist der richtige:


http://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html


Wenn die Anleitung abgearbeitet wurde sollte der Login zum PI funktionieren.

Der "lokale host" ist dein Docker-Container nicht der Nuc-Host. Auszuführen als root da du FHEM als root laufen lässt. Warum eigentlich? Wenn du den User fhem im Docker verwenden würdest, müsstest nur eine einzelne Datei kopieren und leicht anpassen.

Nachtrag: da du fhem als root laufen lässt wäre es sinnvoll den Odner /root/.ssh als volume zu definieren damit die ssh-Keys auf dem Docker-Host liegen. Ansonsten musst du die Konfiguration bei jedem Fhem-Docker-Update erneut machen.

Hackstall

Danke,

bei Deinem Link ist auch wieder die sed Frage. Was bedeutet die Anweisung?
Otto geht vun user fhem aus. Was muss ich aendern wenn ich root als fhem user habe?

Welche Datei muesste ich denn wie aendern um als Fhem unterwegs zu sein?

was meinst Du mit /root/.ssh als volume?

Danke Andreas

Sorry bin Laie aber lernfaehig

amenomade

Der sed Befehl macht Änderungen in deiner /etc/passwd Datei indem er ein Home, und ein shell dem User fhem zuweist, wie kadettilac89 es schon geschrieben hat. Sowas kann man aber ruhig mit usermod Befehle auch machen, und zwar für den User, den man will. https://linux.die.net/man/8/usermod

ZitatDie Fehlermeldung meines og Problems hatte aber nichts mit den Einstellungen zu tun.
Aber doch. Dein SYSMON wird erst wieder funktionieren, wenn der ssh Zugang zum entspr. Rechner wieder in Ordnung ist.

Du hast vermutlich bei der 2. Einrichtung etwas überschrieben. Z.B.: hast Du neue ssh keys  generiert? Dann musst Du diese neue Schlüssel auch dem Rechner vom SYSMON (192.168.0.33) bekannt geben.



Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

kadettilac89

@Hackstall, deine Informationen sind sehr spärlich. Du nutzt Docker, dein FHEM läuft als root? Wie hast du Docker konfiguriert, Docker-Compose oder was nutzt du?

Wie hast du das konfiguriert, es sind die Parameter an denen du scheinbar auf 0 (Root) gesetzt.

Change FHEM system user ID: To set a different UID for the user fhem (default is 6061):

-e FHEM_UID=6061
Change FHEM group ID: To set a different GID for the group fhem (default is 6061):

-e FHEM_GID=6061


Zeige mal die Ausgabe von ps  IM CONTAINER ... mich wundert das etwas. In Docker ist standardmäßig der User fhem. Docker läuft als root aber im Container gehe ich trotzdem von User fhem aus.


ps -ef | grep -i fhem


Erstmal das ... dann schaun wir die Config von ssh an.

kadettilac89

Zitat von: amenomade am 14 August 2020, 18:27:26
Du hast vermutlich bei der 2. Einrichtung etwas überschrieben. Z.B.: hast Du neue ssh keys  generiert? Dann musst Du diese neue Schlüssel auch dem Rechner vom SYSMON (192.168.0.33) bekannt geben.

Richtig, ich zweifle dran, dass FHEM als root läuft darum mein penetrantes Nachfragen. Es ist wichtig zu wissen für welchen User der "Trust" erstellt werden muss. Mit fhem-User braucht er nur die authorized_hosts neu erstellen.

Hackstall

Hallo vielen Dank für Euren Support

Also ein ps -ef im Docker Container (via portainer) bringt folgendes:


root@d46eeef5adc7:/opt/fhem# ps -ef | grep fhem
root         1     0  0 Aug13 ?        00:00:00 /bin/sh -c bash /opt/fhem/start.sh
root         7     1  0 Aug13 ?        00:00:00 bash /opt/fhem/start.sh
root         8     7  5 Aug13 ?        01:14:16 perl fhem.pl fhem.cfg
root        77     8  0 Aug13 ?        00:00:02 perl fhem.pl fhem.cfg
root     31686 31674  0 18:45 pts/1    00:00:00 grep fhem
root@d46eeef5adc7:/opt/fhem#

kadettilac89

#21
OK, welche Dateien liegen IM CONTAINER in

/opt/fhem/.ssh


ls -la /opt/fhem/.ssh


und welche AUF DEM RASPBERRY in

/home/pi/.ssh


ls -la /home/pi/.ssh


Teste mal folgendes:

1) IM DOCKER CONTAINER -- Kopiere alle Datei aus /opt/fhem/.ssh/ nach /root/.ssh/
2) Sichere die DAtei AUF DEM RASPBERRY /home/pi/.ssh/authorized_keys oder bennene diese um
3) Kopiere die Datei id_rsa_pub_id_rsa.pub AUS CONTAINER  nach RASPBERRY /home/pi/.ssh/ und bennene sie      authorized_keys

ssh zum Raspberry müsste jetzt schon funktionieren. Beim ersten ausführen wirst du gefragt ob du dem neuen / geänderten Key vertrauen willst. Mit J/Y .. je nach Sprache .. bestätigen


ssh pi@192.168.0.33


Wenn nicht - Fehlermeldungen posten. + Ausgaben der beiden ls -la Befehlen von oben hier posten

MadMax-FHEM

#22
Nur um sicher zu gehen, dass es auch tatsächlich vom richtigen User ausgeführt wird, wäre da nicht "sowas":

{qx(ls -la ~/.ssh)}

in der fhem-WEB Zeile "besser"!?

EDIT: weil /opt/fhem/.ssh ja nur gültet, wenn es sich um den User fhem handelt (und nicht doch root etc.)...

Oder auch:

{qx(whoami)}

Und ich würde auch eher die "Linux-Befehle" bzgl. User-/Gruppenänderungen als sed und so nehmen...

Ich mache auch nie sowas wie: echo "blablabla" > irgendwasLinuxSystemDatei

Weil da ist schnell mal ein Zeichen übersehen etc.
Und dann (noch dazu als root/sudo) ausgeführt naja...

EDIT: Ausnahme wäre ein Script was ich anlege um z.B. beim Einspielen eines Backup gewisse Dinge "autom." laufen/einstellen zu lassen... Aber das wird erst mal auf einem Testsystem getestet (da ist es "egal" wenn was schief läuft -> dann muss halt neu von vorne und dann "besser" ;)  )


Und um passwortlos auf einem anderen Rechner mit ssh landen zu können:

1. der Host muss in ~/.ssh/known_hosts stehen -> dazu einmal remote einloggen und mit J/Y beantworten (dazu braucht man bei User fhem eben das "sed" von Otto ODER: eben andere Wege einen Login für den User fhem zu bekommen, weil: der hat norm. KEINEN / was dazu bei DEINEM fhem-User [root?] notwendig ist: evtl. gar nichts, wenn du dich eh schon als root einloggen kannst)

2. der ~./ssh/id_rsa.pub "Schlüssel" auf dem remote Rechner in dem Home/.ssh des Users als der du dich REMOTE einloggen willst (pi!?) / dazu gibt es den Befehl: ssh-copy-id

Erst wenn das für die jeweils richtigen User passt wird das klappen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Hackstall

Hallo,

ich habe den pi mit 33er Adresse jetzt wieder.
Log-Messages werdem nicht mehr angelegt.
Somit habe ich den alten Zustand wieder.
Vielen Dank für Eure tolle Unterstützung.

Um nicht nochmal alles verkehrt zu machen, was muss ich denn jetzt bzgl ssh PC Anbindung 192.168.0.45
installieren?
a) ist das das gleiche key-file oder muss ich ein anderes erzeugen
b) openssh auf pc funktioniert, kann mich mit ssh user und passwort anmelden
c) ich moechte aber auch auf dem pc ohne passwort drauf.. Geht das zusaetzlich zu meinem 33er pi?

Danke Andreas

kadettilac89

Zitat von: Hackstall am 14 August 2020, 19:40:12
Hallo,

ich habe den pi mit 33er Adresse jetzt wieder.
Log-Messages werdem nicht mehr angelegt.
Somit habe ich den alten Zustand wieder.
Vielen Dank für Eure tolle Unterstützung.

Um nicht nochmal alles verkehrt zu machen, was muss ich denn jetzt bzgl ssh PC Anbindung 192.168.0.45
installieren?
a) ist das das gleiche key-file oder muss ich ein anderes erzeugen
b) openssh auf pc funktioniert, kann mich mit ssh user und passwort anmelden
c) ich moechte aber auch auf dem pc ohne passwort drauf.. Geht das zusaetzlich zu meinem 33er pi?

Danke Andreas

a) selbes File das jetzt in /root/.ssh liegt
c) ja, du kannst beliebige Rechner konfigurieren, ist nicht auf einen beschränkt

Bevor du aber mit dem PC weitermachst ... setze ein Volume in Docker auf /root/.ssh ansonsten sind die Dateien beim nächsten Docker-Upgrade weg. Volume wie du jetzt für /opt/fhem irgendwohin schreibst auch für /root/.ssh ... dann musst die Dateien nochmal kopieren, oder die Schritten nochmal ausführen.

Wenn das Volume existiert den Container neu erstellen. Dadurch werden die aktuellen in diesem Ordner gelöscht. Du kannst die Dateien aus /root/.ssh auch vor dem Erstellen wegsichern und dann wieder zurückschreiben.