Wenn ich auf meinem Linux-PC ein Terminal habe, dann kann ich den Befehl
ssh root@192.168.178.47 shutdown -h now
ausführen.
Wenn ich das aus FHEM heraus machen möchte, dann schreibe ich in die Kommandozeile
{system ('ssh root@192.168.178.47 shutdown -h now')}
Der Rückgabewert ist -1 und im Logfile steht
Host key verification failed.
Worin besteht denn da der Unterschied und was muss ich tun, um es zum Erfolg zu führen? Eine Idee hätte ich: Aus dem Terminalfenster heraus bin ich ja als "pi" angemeldet, der user aus FHEM heraus ist aber ein anderer. Wenn es daran liegt: wie löse ich den Konflikt auf?
Vermutlich machst du ersteres mit dem User root und das zweite macht der User FHEM. Dieser ist aber auf dem entsprechenden Server nicht authorisiert. Du musst den entsprechenden Key mit dem user FHEM übertragen.
Falls es an den Grundlagen hapert, bitte etwas googlen. Zum ssh mit Keys und Schlüsselaustausch findest du im Netz gefühlt Millionen gute Tipps. Im Übrigen wurde das Thema auch hier im Forum schon mehrfach behandelt.
Ich mache ersteres mit dem user "pi" und das zweite macht der user "FHEM" - insofern war also meine Vermutung schon in die richtige Richtung. Wenn ich es mit dem user "FHEM" mache, dann muss ich mich als solcher anmelden, ich denke das bekomme ich hin.
Ich habe übrigens aufgrund der Beiträge hier im Forum, das mit dem ssh und Schlüsselaustausch bei mir nun angewandt - klar google ich bevor ich frage und habe mittlerweile auch einen deutlich höheren Erfolgsfaktor aufgrund "besserer" Suchanfragen. Aber manchmal hilft mir das halt leider auch nicht.
Die Aufgabenstellung und die Lösung mal hier kompakt:
FHEM soll einen Befehl im Betriebssystem ausführen:
{system['<Linuxbefehl>'}
Das ist an sich kein Problem, aber wenn der Befehl lautet, sich via ssh mit bekanntem Schlüsselaustausch in ein weiteres System einzuloggen, dann muss FHEM und damit der user "fhem" den Schlüsselaustausch machen!
Beim Raspberry geht das dann so, wobei vorausgesetzt ist, dass man schon eingeloggt ist, was normalerweise der user "pi" ist:
#zuerst sicherstellen, dass man sich als fhem problemlos einloggen kann:
sudo vi /etc/passwd
# dort zu der Zeile mit fhem gehen
# am Ende dieser Zeile /bin/false in /bin/bash ändern
# abspeichern und Editor (man kann auch einen anderen nehmen) verlassen
sudo su - fhem
# bitte alle Leerzeichen beachten!
# nun ist man als user fhem eingeloggt
ssh-keygen -t rsa
# danach 2x return eingeben
# der Schlüssel wird unter /opt/fhem/.ssh abgelegt
ssh-copy-id -i /opt/fhem/.ssh/id_rsa.pub <user>@<Zielrechner>
# kopiert den Schlüssel im Zielrechner an die richtige Stelle und man muss ein letztes Mal das Passwort für den Zielrechner eingeben
Zitat von: ujaudio am 11 September 2015, 11:40:04
#zuerst sicherstellen, dass man sich als fhem problemlos einloggen kann:
sudo vi /etc/passwd
# dort zu der Zeile mit fhem gehen
# am Ende dieser Zeile /bin/false in /bin/bash ändern
# abspeichern und Editor (man kann auch einen anderen nehmen) verlassen
sudo su - fhem
# bitte alle Leerzeichen beachten!
# nun ist man als user fhem eingeloggt
ssh-keygen -t rsa
# danach 2x return eingeben
# der Schlüssel wird unter /opt/fhem/.ssh abgelegt
ssh-copy-id -i /opt/fhem/.ssh/id_rsa.pub <user>@<Zielrechner>
# kopiert den Schlüssel im Zielrechner an die richtige Stelle und man muss ein letztes Mal das Passwort für den Zielrechner eingeben
Der User fhem braucht keine bash :o Du willst dich ja nicht als fhem einloggen...
Er braucht lediglich einen Key in seinem "Benutzerordner" und der kann auch deutich einfacher da erstellt/hinkopiert werden ;)
Zitat von: Virsacer am 11 September 2015, 13:33:47
Der User fhem braucht keine bash :o Du willst dich ja nicht als fhem einloggen...
Er braucht lediglich einen Key in seinem "Benutzerordner" und der kann auch deutich einfacher da erstellt/hinkopiert werden ;)
Dieser Eintrag ist nur notwendig, damit das Kommando
sudo su - fhemfunktioniert - das habe ich in einem anderen Thread hier in diesem Forum gefunden.
Warum ist eigentlich das fhem-Passwort nicht bekannt??!?
Wenn Du bis heute Abend warten kannst kann ich Dir was fertiges zeigen. Ich verwende ein FHEM at um mein Firewall Script entsprechend laufen zu lassen damit z.B. WhatsApp für meine Tochter nach 21 Uhr gesperrt wird.
Grüße
Hm, als Medienpädagoge runzele ich die Stirn.
Entweder ist die Tochter schon 16, dann sollte sie so vernünftig sein, das nach einem Gespräch zu lassen.
Oder sie ist noch keine 16, dann ist das ein Verstoß gegen die Nutzungsbedingungen von WhatsApp.
LG
pah
Sie ist 13, und glaube mir ohne WhatsApp bist Du in ner 7 Klasse abgeschirmt. Nutzungsbedingungen hin oder her. Bin auch nicht begeistert. Aber leider werden alle Infos über Klassenchats verteilt.
Grüße
Ich habe das ja nicht leichtfertig geschrieben: Gerade bei WhatsApp wird unter den Schülern extrem viel Missbrauch getrieben, auch deren Nutzungsbedingungen sind nicht leichtfertig so entstanden.
Dass Klasseninfos darüber verteilt werden, ist mit Sicherheit ein Verstoß gegen die Datenschutzbestimmungen des betreffenden Kultusministeriums.
LG
pah
Zitat von: CoolTux am 11 September 2015, 15:57:55
Wenn Du bis heute Abend warten kannst kann ich Dir was fertiges zeigen. Ich verwende ein FHEM at um mein Firewall Script entsprechend laufen zu lassen damit z.B. WhatsApp für meine Tochter nach 21 Uhr gesperrt wird.
Grüße
Na, das ist ein Angebot...
Zitat von: ujaudio am 11 September 2015, 15:43:54
Dieser Eintrag ist nur notwendig, damit das Kommando
sudo su - fhem
funktioniert - das habe ich in einem anderen Thread hier in diesem Forum gefunden.
Ja, aber der Befehl ist auch unnötig...
Du loggst dich ja unter Windows auch nicht als "TrustedInstaller" ein, wenn du ne Textdatei im Programme-Ordner erstellen willst ;)
Also
sudo ssh-keygen -f /opt/fhem/.ssh/id_rsa
sudo chown fhem /opt/fhem/.ssh -R
reicht aus ;)
Zitat von: ujaudio am 11 September 2015, 15:43:54
Warum ist eigentlich das fhem-Passwort nicht bekannt??!?
Weil es keins gibt...
So da wären wir.
Fangen wir an. Ich beschreibe Dir am besten wie ich es gemacht habe und Du entscheidest was Du übernimmst oder nicht.
Ich habe als erstes einen User auf dem remote system angelegt. Username cmdremote ohne passwort mit sh shell
useradd -s /bin/sh -d /home/cmdremote -m cmdremote
Im Homeverzeichnis von cmdremote kommt unter .ssh der private Schlüssel.
Danach habe ich dem User auf dem System entsprechend dem was er machen soll sudo Rechte gegeben.
meine /etc/sudoers
cmdremote ALL = NOPASSWD: /etc/iptables/rules.scripts/isabel_handy.sh, /etc/iptables/rules.scripts/ssh_inbound_inet.sh, /etc/iptables/rules.scripts/fhem_inbound_inet.sh
Hier trägst Du halt /sbin/shutdown oder so ein oder gibst ihm alle rechte der welt wenn es dir egal ist
Fertig,
Nun zum fhem System.
Lege unter /opt/fhem/ ein Verzeichnis .ssh an. Hier kommt der öffentliche Schlüssel rein. Ausserdem legst Du eine Datei an namens config in der Du folgendes einträgst
Host mirdochegal
Hostname ip zielrechner
User cmdremote
IdentityFile /opt/fhem/.ssh/id_rsa
Port 22
ServerAliveInterval 30
ServerAliveCountMax 120
danach einfach mal testen ob du überhaupt rauf kommst. also mittels
su -s /bin/bash -c 'ssh mirdochegal' fhem
Wenn Du nun in eine shell auf dem zielsystem landest hast du es geschaft.
In fhem selbst schreibst du einfach ein
{ system("ssh proxy01 'sudo /etc/iptables/rules.scripts/isabel_handy.sh allow'") }
Danke Virsacer und CoolTux.
Das mit dem sudoer muss ich in Ruhe auf meinem Testsystem ausprobieren, da habe ich mir schon mal massive Probleme eingehandelt, weil ich trotz größter (aber eben nicht ausreichender) Sorgfalt mir das System kaputt gemacht habe. Naja, ich konnte es wieder reparieren, aber das dauerte... Mittlerweile muss mein Livesystem einfach funktionieren, sonst bekomme ich Ärger mit meiner besseren Hälfte ;) Ist ja auch blöd, wenn Wecker, Rollladen, Dunstabzugshaube, Badezimmerlüfter, Lampen, Stereoanlage und einiges mehr nicht mehr funktioniert.
Zitat von: CoolTux am 11 September 2015, 21:45:10
Im Homeverzeichnis von cmdremote kommt unter .ssh der private Schlüssel.
Zitat von: CoolTux am 11 September 2015, 21:45:10
Lege unter /opt/fhem/ ein Verzeichnis .ssh an. Hier kommt der öffentliche Schlüssel rein.
Ich geh mal davon aus, dass du es richtig gemacht hast, aber fürs Protokoll:
Im Benutzerverzeichnis von fhem ist der private Schlüssel und auf dem Remotesystem der Öffentliche.
nicht ganz. Denn du verbindest dich ja vom fhem zum remote. du benutzt den user des remotesystems, also kommt der private auf dem remote und der öffentliche auf dem fhem.
du schickst ja deinem kumpel der remote auf dein system soll auch nicht deinen privaten.
gruß
Zitat von: CoolTux am 12 September 2015, 12:01:16
nicht ganz. Denn du verbindest dich ja vom fhem zum remote. du benutzt den user des remotesystems, also kommt der private auf dem remote und der öffentliche auf dem fhem.
du schickst ja deinem kumpel der remote auf dein system soll auch nicht deinen privaten.
fhem ist "derjenige", der sich einloggt und entsprechend autentifizieren muss - das tut er, indem er nachweist, dass er den privaten Schlüssel besitzt.
Richtig, wenn sich ein Kumpel bei dir einloggen will schickt er dir seinen öffentlichen Schlüssel ;)
Das ist nicht korrekt, Der Befel ssh wird nur als fhem User ausgeführt, ssh einloggen tut sich aber "cmdremote"
Host mirdochegal
Hostname ip zielrechner
User cmdremote
IdentityFile /opt/fhem/.ssh/id_rsa
Port 22
ServerAliveInterval 30
ServerAliveCountMax 120
Man beachte bitte die Zeile "User"
Das wäre das selbe als wenn ich schreiben würde ssh cmdremote@ip-tielrechner. Habe das nur durch die config mir erspart. Also meldet sich cmdremote am Zielsystem an.
Gruß
Marko
Ok, fhem loggt sich ALS cmdremote ein ::)
Aber cmdremote braucht trotzdem nur eine authorized_keys im Benutzerordner, in der der public Key von fhem (und allen weiteren Benutzern, die sich ALS cmdremote anmelden dürfen) drin steht...
Siehe: https://www.debian.org/devel/passwordlessssh
Ah ok dann hatte ich die files in der Bedeutung vertauscht. ;D
Grüße