Hallo
Ist es möglich ein Synology DS213j über FHEM zu steuern?
Einschalten, Ausschalten ev. Temperatur etc auslesen.
Oder gibt es ein anderes Strohmsparendes NAS das über FHEM steuerbar ist?
temperatur geht über das sysstat modul. mit dem WOL modul kannst du es aus dem standby holen. per ssh kannst du es aushalten.
per ssh ausgeschaltet kannst du es aber nicht mehr aufwecken. ich glaube es hat noch niemand rausgefunden wie man es per kommandozeile schlafen legt.
gruß
andre
Ausschalten geht über ssh, Benutzer root mit dem befehl "poweroff"
Über WOL aufwecken geht dann auch gleich wieder.
danke
Wie setz ich ein Befehl über ssh oder ev. telnet?
Gibt es da ein Modul?
wenn du etwas zum anklicken haben möchtest kannst du z.b. das PRESENCE modul verwenden und das powerCmd attribut setzen. oder du verwendest ein notify das du mit trigger aufrufst.
das ssh kommando selber kannst du z.b. so absetzen:{system("ssh 10.0.1.56 poweroff");}
gruss
andre
ZitatAusschalten geht über ssh, Benutzer root mit dem befehl "poweroff"
Über WOL aufwecken geht dann auch gleich wieder.
Unter Voraussetzung, das WOL aktiviert wurde. Bei meiner (ist aber eine andere Synology), war es im Standard deaktiviert
Und wegen ssh:
Du musst "nur" das einloggen per "key" konfigurieren
und wol geht nicht bei allen modellen.
gruss
andre
Zitat von: justme1968 am 12 Mai 2015, 08:06:45
...
das ssh kommando selber kannst du z.b. so absetzen:{system("ssh 10.0.1.56 poweroff");}
gruss
andre
wie muss das Kommando genau aussehen, den ich muss ja den Benutzer und das Passwort angeben. Benutzer weiß ich:
("ssh root@10.0.1.56 poweroff")aber dann kommt doch als nächstes die Eingabe des Passworts ..??!?
du musst ssh so konfigurieren das du kein password brauchst. also public key ohne password.
gruss
andre
Suche für Dich mal schnell per google:
Etwas komplizierter erklärt, siehe synology Wiki:
http://www.synology-wiki.de/index.php/Ssh_mit_Zertifikaten_absichern
Besser:
https://www.df.eu/de/service/df-faq/cloudserver/anleitungen/ssh-logins-auf-public-private-key-umstellen/
Edit:es ist genau das, was ich meinte mit:
ZitatUnd wegen ssh:
Du musst "nur" das einloggen per "key" konfigurieren
Danke für den Hinweis, da sowohl meine DS114 als auch meine DS410 WOL unterstützen bin ich wieder einen Schritt weiter und kann nicht benötigte Server ausschalten. Klasse!
Hallo
Geht das auch irgendwie mit Benutzer und Password?
Telnet oder SSH?
Wenn das mit einem APP geht sollte das doch auch mit FHEM möglich sein?
und was spricht deiner meinung nach gegen public key authentifizierung?
du weisst schon das fast immer das sehr viel sicherer als als user/password ist und eigentlich niemals weniger sicher...
Hab es noch nicht versucht.
Möchte es dann auch bei meinen zwei Ds207 machen.
Publik Key hat den Vorteil, das Du mit "Bordmitteln" den Zugriff realisierst. Bei User/Passwort müsstest Du diese in der Kommandozeile übergeben, was aber sehr unsicher ist, da im Script, oder im Prozessmonitor dieses zu "sehen" ist.
Kurzfassung:
Bei automatischen Zugriff ist PubKey der empfohlene (und eigentlich einzigste) Weg des Zugriffes
Ich habe mir die Anleitungen jetzt mehrfach durchgelesen und dann getan was ich verstanden habe ;):
- einen Benutzer fhem auf der Synology eingerichtet und im homeverzeichnis das Unterverzeichnis .ssh mit den Rechten wie beschrieben eingerichtet.
- auf meinem Raspberyy ein Schlüsselpaar erzeugt - da legen jetzt 3 Dateien im Verzeichnis .ssh
- den privaten Schlüssel lasse ich dort liegen
- den Inhalt des öffentlichen Schlüssels habe ich gemäß Anleitung in die Datei authorized_keys auf der Synology kopiert.
Brauche ich die Datei id_rsa.pub noch irgendwo?
Was passiert mit der Datei known_hosts?
Muss ich das Login per Passwort explizit noch deaktivieren? Das habe ich noch nicht getan.
DIe weiteren Angaben in den beiden Links helfen mir nicht weiter und was ich sonst noch gefunden habe auch nicht. Irgendetwas fehlt mir noch zum Verständnsi, wie ich es zum Laufen bringe.
Immerhin kann mein Raspberry die Synology schon aufwecken. Der Code aus fhem sollte dann wohl sein:
{system("etherwake -b <Macadresse>");}Probiere ich dann als nächstes...
du musst keine passwörter deaktivieren aber beim erzeugen des schlüsselpaares keines angeben.
was genau geht denn nicht?
kannst du dich von hand per ssh zur synology verbinden?
in known_hosts wird auf rapsberry seite bei diesem ersten einloggen von hand nach der bestätigung automatisch der system key der synology abgelegt.
sobald das geht musst du auf synology seite das power off kommando noch für den fhem user per sudo freigeben.
gruss
andre
Zitat von: justme1968 am 04 Juni 2015, 17:03:20
was genau geht denn nicht?
wenn ich auf dem Raspberry "ssh fhem@192.168.178.44" eingebe wird nach wie vor das Passwort abgefragt
Zitatkannst du dich von hand per ssh zur synology verbinden?
jetzt wo du es sagst, fällt es mir erst einmal wie Schuppen von den Augen: Ich kann mich als admin oder als root mit der Synology verbinden, aber nicht als neuer user fhem - auch nicht von meinem normalen PC aus! Also erst einmal diese Baustelle schließen!
Zitatsobald das geht musst du auf synology seite das power off kommando noch für den fhem user per sudo freigeben.
gruss
andre
ja und auch noch das etherwake für jedermann auf dem Raspberry erlauben - momentangeht das nur mit sudo - und damit von fhem nicht.
Danke für den Hinweis, mal sehen wie ich mich jetzt anstelle...
Nachtrag:
Die Datei etherwake steht in /usr/sbin und hat folgende Rechte:
-rwxr-xr-x 1 root root 11152 Apr 26 2012 etherwakeWarum geht das nur mit root-Rechten?
Der Eigentümer ist root, die Gruppe ist auch root. Aber es ist doch auch für alle anderen das execute-Bit gesetzt!!?! Das ist zwar keine fhem- sondern ein Linux-Frage, aber vielleicht darf ich sie hier trotzdem stellen.
Das jeder es ausführen kann, bedeutet aber nicht, das das Proggi dann auch alle "rechte" hat. Es hat nur die rechte des aufrufenden Usrds.
Kenne mich jetzt nicht soooo aus, aber sofern ich weiß braucht etherwake Rechte auf das "RAW" Device der Netzwerkschnistelle, da es ein spezielles "Magik-Packet" über diese raussendet, also nicht über den Normalen Netzwerkstack. Und diese Rechte hat (normalerweise) nur root ....
Edit:
Eine kleine google-Suche braucht u.A. folgendes:
http://security.stackexchange.com/questions/72737/what-are-the-risks-of-making-ether-wake-available-to-all-users (http://security.stackexchange.com/questions/72737/what-are-the-risks-of-making-ether-wake-available-to-all-users)
Uff - jetzt habe ich fast meine gesamte Heimautomatisierung zerschossen. Ich habe versucht mit
visudo -f /etc/sudoers.d/fhem
dem etherwake die Rechte zu geben - und dann ging gar nichts mehr, weil beim Abspeichern etwas schief ging. PANIK - jegliche Erinnerung verloren. Miich von meiner liebsten Ehefrau trösten lassen und dann die SD aus dem Raspberry geholt und mit Herzklopfen auf der SD die Datei gesucht und gelöscht (was gar nicht so trivial ist!). So nun läuft mein Raspberry wieder - aber das Ganze nochmals?
Wenn fhem das etherwake machen soll, dann ist zu dem Zeitpunkt doch der user = fhem. also muss doch in der Datei fhem im Verzeichnis sudoers.de folgendes stehen:
fhem ALL /usr/sbin/etherwake
So habe ich das aus den diversen Infos aus Google herausgelesen.
Hat denn jemand schon mal so was ähnliche gemacht?
Nicht gaaaans, lies Dir mal durch:
http://sleepyhead.de/howto/?href=sudo
Erst einmal DANKE!
Ganz habe ich es noch nicht verstanden:
Host_Alias RASPBERRY = 192.168.178.44 # die IP-Adresse der Hardware
User_Alias SMARTHOME = fhem # fhem ist der user der Automatisierung
Cmnd_Alias WOL = /usr/sbin/etherwake # das ist der erlaubte Befehl
SMARTHOME RASPBERRY = (ALL) NOPASSWD: WOL # fhem can wake up the music server
Der Host ist mir unklar. Der Befehl etherwake muss auf dem Host Raspberry ausgeführt werden. Der User fhem ist zufällig der lokale user.
Ich geb's zu: ich bin richtige feige und bevor ich nicht 150% sicher bin traue ich mich nicht, auf dem Musikserver irgendetwas zu tun. Den dort muss ich ja auch noch poweroff freigeben, damit das Kommando
{system("ssh 192.168.178.23 poweroff");}
funktioniert.
Das klappt bei mir nicht.
Im Putty erhalte ich immer die Meldung
Zitatnot a private key
Der Key ist generiert umbenannt im Benutzer Admin.
warum benennst du irgendetwas um?
vermutlich hast du irgendwo public und private key verwechselt.
gruß
andre
Hallo
Zitatwarum benennst du irgendetwas um?
In der Anleitung steht:
ZitatAnschließend müssen Sie in den Ordner ".ssh" wechseln und Ihren öffentlichen Schlüssel in der Datei "authorized_keys" ablegen. Sollten Sie aus dem vorherigen Abschnitt sich einen neuen Schlüssel angelegt haben, so wurde der ".ssh"-Ordner bereits für Sie erstellt und der öffentliche Schlüssel befindet sich in der Datei "id_rsa.pub". In diesem Fall ist nur noch eine Umbenennung notwendig:
# mv id_rsa.pub authorized_keys
Hab ich da was Falsch verstanden???
Ich habe gestern erfolgeich wie folgt meinen Raspberrry mit meiner Synology zusammengebracht, indem ich auf dem Raspberry folgendes getan habe:
ssh-keygen -t rsa
Das generiert das Schlüsselpaar, alle Eingaben sind einfach nur mit <Return> zu beantworten, damit kein Passphrase und Ablage im Standardverzeichnis.
ssh-copy-id -i ~/.ssh/id_rsa.pub root@<ip der Synology>
Da muss man noch ein letztes Mal das Adminpasswort der Synology eingeben. Man wird dann auch aufgefordert es gleich einmal zu probieren.
Hat auf Anhieb funktioniert.
Hallo!
Kann mir jemand erklären, wie ich die Temperatur auslese. Ich weiß, mit Sysstat, aber im WIKI steht leider nicht drin, wie ich die synology anspreche, bzw. habe ich es nicht verstanden.
Ich habe einen RPI mit FHEM und 3 Synology 1 BAY NAS! 2 schon sehr alte 107ner und 1x114!
Laut WIKI soll ich das eintragen:
define BBxM SYSSTAT 120 600
attr BBxM filesystems /dev/mmcblk0p2
attr BBxM room <Ihr Raum>
attr BBxM showpercent 1
Nur damit gebe ich ja nicht genau an, welche DS ich auslesen will!
Kann mir bitte jemand einen Tipp geben?
Die Datei mmcblk0p2 ist auch nicht in dem Verzeichnis DS107+DS114 :-(
Vielen Dank
greets
ICE#
du musst snmp und synologytemperature setzen. für snmp musst du das perl Net::SNMP installiert haben.
läuft fhem auf der synology? wenn nicht musst du im define noch die ip angeben und du solltest ssh konfigurieren.
gruss
andre
Nunja weder
attr Sysstat snmp 1 bekomme ich nur unknown attribute snmp
Manuell eingetragen bekomme ich die auch Fehlermeldung.
define Synology213j SYSSTAT 192.168.10.10
attr Synology213j group System
attr Synology213j synologytemperature 1
attr Synology213j room System
attr Synology213j showpercent 1
attr Synology213j snmp 1
attr Synology213j uptime 1
Vlt einer eine Idee?
Bekomme auch nur : Uptime. und die stimmt nicht einmal.
Update: Achja hab herausgefunden der geht auf localhost trotz eingabe der IP...... den der raspberry hat die 27 Tage...
Update 2: mal die Zeitabfragen hinzugefügt. Restart. nun ging es. Mehr wäre cool ;)
load 0.00 2015-07-26 03:26:46
state 0.00 0.22 0.29 2015-07-26 03:26:46
temperature 49 2015-07-26 03:26:46
uptime 18 days, 01:07:40.85 2015-07-26 03:26:46
Hallo
Wollte das mit der ssh Anmeldung auch mal versuchen.
Ich hab nun auf dem NUC ein Benutzer der über ssh Zugriff auf das Nas hat.
FHEM auf dem Nuc hat so aber kein Zugriff.
Wie übergib ich FHEM den Schlüssel auf dem Nuc?
Auf dem Rechner, wo FHEM läuft (bei mir Rapberry):
ssh-keygen -t rsa -b 4096
# erzeugt ein Schlüsselpaar und legt es im Verzeichnis /home/user/.ssh ab
# für unseren Zweck bitte kein Passphrase eingeben (= 2x nur Return-Taste drücken)
# auf dem Raspberry nur ,,ssh-keygen -t rsa"
ssh-copy-id -i /home/user/.ssh/id_rsa.pub pi@192.168.178.78
# kopiert den öffentlichen Schlüssel in den Rechner, in welchen man sich einloggen will
# und fordert einen gleich auf es auszuprobieren
# anstelle von pi@192... natürlich immer das entsprechende Ziel eingeben
So hab's ich gemacht und es hat funktioniert.
Kurzgefasst,
der User, der fhem auf dem NUC laufen hat, muß auf die NAS kommen können.
Zitatssh-keygen -t rsa -b 4096
# erzeugt ein Schlüsselpaar und legt es im Verzeichnis /home/user/.ssh ab
# für unseren Zweck bitte kein Passphrase eingeben (= 2x nur Return-Taste drücken)
# auf dem Raspberry nur ,,ssh-keygen -t rsa"
ssh-copy-id -i /home/user/.ssh/id_rsa.pub pi@192.168.178.78
# kopiert den öffentlichen Schlüssel in den Rechner, in welchen man sich einloggen will
# und fordert einen gleich auf es auszuprobieren
# anstelle von pi@192... natürlich immer das entsprechende Ziel eingeben
Hab ich, geht auch.
Zitatder User, der fhem auf dem NUC laufen hat, muß auf die NAS kommen können.
Der User kommt aufs NAS.
Aber FHEM bei mir nicht.
Hat aber FHEM Zugriff auf ssh und /home/user/.ssh?
Mein FHEM hat auch ein .ssh Ordner opt/hfem/.ssh?
Zitatssh root@192.168.178.9 poweroff
So schalte ich das NAS über den NUC aus.
Sollte in Fhem so aussehen
Zitat{ system("ssh 192.168.178.9 poweroff") }
geht aber nicht
Zitatssh: Could not resolve hostname root.168.178.9: Name or service not known
Host key verification failed
Mein Benutzer auf dem Nuc heist damu
Muss ich einen Benutzer damu auf dem Nas erstellen, dort den key eintragen......
Danach müsste
Zitatssh damu@192.168.178.9 poweroff
ssh 192.168.178.9 poweroff
Wenn funktioniert
Zitatssh root@192.168.178.9 poweroff
dann ist doch
Zitat{ system("ssh 192.168.178.9 poweroff") }
falsch oder?
muss doch heißen
{ system("ssh root@192.168.178.9 poweroff") }oder??!?
Geht leider nicht.
{ system("ssh root@192.168.178.9 poweroff") }
Zitatssh: Could not resolve hostname root.168.178.9: Name or service not known
Ist das @ erlaubt?
Jetzt habe ich bei mir nochmals in fhem.cfg nachgeschaut:
{system ('ssh root@192.168.178.47 poweroff')}
So steht es drin und es funktioniert.
Unterschied: ' versus "
Ob das entscheidend ist? Müsste mal wieder in die Tiefen der perl-Programmierung eintauchen.
Zitat{system ('ssh root@192.168.178.9 poweroff')}
Sieht besser aus, aber geht immer noch nicht.
ZitatHost key verification failed.
Also nach Deiner Ausage:
Du probierst es mit einem User: Funktioniert
Du probierst es mit FHEM: funktioniert Nicht.
Könnte es sein, das Du es auf der Konsole NICHT MIT DEM FHEM-User probierst?
Im Standard also testen mit:
(als root)
su - fhem
ssh root@192.168.178.9 poweroff
Danke für die Hilfe
Zitatdamu@fhem:~$ su - fhem
Passwort:
su: Legitimierungsfehler
Ich hab nie einen user Fhem erstellt, ist das Falsch?
Bitte als root probieren, nicht als User damu. Als user root brauchst Du kein Passwort ....
Bitte meinen text auch lesen ...
Wenn Du FHEM per Paket installiert hast, hast Du (im Standard) auch den user fhem erzeugt ....
Hallo
Ich habe Ubuntu Server auf den NUC.
Da ist das root Konto doch deaktiviert? (Steht auch so in der Wiki)
So sollte es aber gehen:
Zitatsudo -u fhem ssh root@192.168.178.9 poweroff
damu@fhem:~$ sudo -u fhem ssh root@192.168.178.9
The authenticity of host '192.168.178.9 (192.168.178.9)' can't be established.
RSA key fingerprint is a5:23:ce:36:9e:6d:8f:34:ee:4f:3d:f3:c5:44:4c:a4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.178.9' (RSA) to the list of known hosts.
root@192.168.178.9's password:
BusyBox v1.16.1 (2014-09-04 11:01:59 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Nas1> exit
Connection to 192.168.178.9 closed.
damu@fhem:~$
Habs zuerst ohne poweroff gemacht.
Beim zweiten mal kommt es aber zur Passwordabfrage:
damu@fhem:~$ sudo -u fhem ssh root@192.168.178.9
root@192.168.178.9's password:
Mit user damu geht es:
damu@fhem:~$ sudo -u damu ssh root@192.168.178.9
BusyBox v1.16.1 (2014-09-04 11:01:59 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Nas1> exit
Hallo
Habe nun einen neuen Ordner in opt/fhem mit dem Namen synossh gemacht.
In den Ordner opt/fhem/synoss habe ich die id_rsa Datei von Benutzer damu kopiert.
Die rechte der Datei habe ich auf cmod 0600 gesetzt.
Danach hab ich mit:
Zitatsudo chown -cR fhem /opt/fhem/synossh
den Ordner mit Datei dem Benutzer Fhem übergeben.
Jetzt sollte es gehen:
Zitatsudo -u fhem ssh root@192.168.178.9 -i /opt/fhem/synossh/id_rsa
damu@fhem:~$ sudo -u fhem ssh root@192.168.178.9 -i /opt/fhem/synossh/id_rsa
BusyBox v1.16.1 (2014-09-04 11:01:59 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Nas1>
Ist es auch möglich den Befehl im hintergrund abzusetzen.
Es scheint das Fhem dadurch ca 30-60 Sekunden stehen bleibt?
Zitat von: Damu am 04 Februar 2017, 16:19:24
Ist es auch möglich den Befehl im hintergrund abzusetzen.
Es scheint das Fhem dadurch ca 30-60 Sekunden stehen bleibt?
Das hängt eigentlich davon ab wie Du den Befehl absetzt. -> https://fhem.de/commandref_DE.html#command
Gruß Otto
Hallo Otto
ZitatDas hängt eigentlich davon ab wie Du den Befehl absetzt
Der Befehl sieht so aus:
Zitat{system ('ssh root@192.168.178.9 -i /opt/fhem/synossh/id_rsa poweroff')}
Ich weiss nicht ob vielleicht Fhem noch eine Zeitlang auf eine Antwort wartet?
Jedes Linux-System hat einen root-Akkount. Ohne diesen, würde ein System nicht starten.
Wenn Du ein "sudo" eingiebst, lässt Du ein Programm als root ausführen. Sorry aber Linux Basics.
ZitatJedes Linux-System hat einen root-Akkount. Ohne diesen, würde ein System nicht starten.
Ist für mich auch logisch.
ZitatWenn Du ein "sudo" eingibst, lässt Du ein Programm als root ausführen. Sorry aber Linux Basics.
Wie komm ich auf den FHEM User?
Zitatsu - fhem
Klappt nicht, das heisst das root Konto ist deaktiviert.
Muss ich noch einen Passwor erstellen?
Zitathttps://wiki.ubuntuusers.de/sudo/
So wie ich hier lese
http://www.forum-raspberrypi.de/Thread-raspbian-versteckter-benutzer-fhem (http://www.forum-raspberrypi.de/Thread-raspbian-versteckter-benutzer-fhem)
hat fhem kein Passwort.
Ist es wirklich sinnvol eines zu erstellen?
Werde ich Probleme mit meiner Lösung haben?
Vielen Dank für die Hilfe.
Hi Damu,
ich weiß nicht ob das hilft, aber ich habe die Problematik für mich mal etwas aufgearbeitet.
-> http://heinz-otto.blogspot.de/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html
Seit dem kann ich meine NAS von FHEM aus runterfahren.
Mein shutdown Kommando setze ich im WOL Device so ab "ssh otto@openmediavault 'sudo halt'"
Das blockiert nicht, so steht es auch in der commandref.
Gruß Otto
Hallo Otto
Ich sehe Du hast FHEM ein Password vergeben.
Ist das Sinvoll?
Was hast Du für ein Nas.
Hab es mal bei einem 207 umgestellt.
Bei einem Synology Nas mit neustem OS geht das auch?
Wird beim Befehl POWEROFF nicht nochmals nach dem Password gefragt.
Danke für den Tip mit "sudo halt"
Damu
Hi,
ich habe eine mit Openmediavault, ist ziemlich normales debian. 8)
Mit synology kenne ich mich nicht aus, aber Dein Problem ist allgemeiner. Deswegen habe ich mich rein gehangen.
Die Frage nach dem sinnvoll stellt sich nicht. Ja ich habe die ganzen Beiträge die ich dazu gelesen habe nicht mit verlinkt, sorry.
Du musst dich ein mal mit dem Benutzer fhem anmelden, sonst bekommst Du für ihn keinen Schlüssel. Ohne Passwort kannst Du Dich nicht anmelden.
Wie Du siehst ist das einmalig. Du machst das mit dem Passwort und der Möglichkeit der Anmeldung ja wieder rückgängig
ZitatZunächst mal das Login ermöglichen und ein passwort erstellen:
sudo cp /etc/passwd /etc/passwd.sav
sudo nano /etc/passwd
# in der Zeile: fhem:x:999:20::/opt/fhem:/bin/false
# von /bin/false auf /bin/bash ändern und speichern
Dann für den Benutzer fhem ein Kennwort eingeben
sudo passwd fhem
Nach dem Erstellen des rsa Schlüssels und Test wieder den alten Zustand herstellen
sudo cp /etc/passwd.sav /etc/passwd
Gruß Otto
Woher nimmt dein FHEM für die Anmeldung den Key?
"pi/home/.ssh"?
Ich möchte das er bei einem Umzug von FHEM auch sofort bereitsteht.
Ich habe noch ein Reserve NUC der ein ziehmlich neues Backup von NUC1_FHEM hat.
Und ich hab es auch mal mit einem PI3 versucht.
Hoffe das Backup wird auch da laufen.
"sudo halt" seint nicht zu gehen.
aber nur "halt" seint auch zu gehen.
Nö, fhem nimmt ja nicht den Key von Pi, sondern den von fhem -> /opt/fhem/.ssh
Aber das passiert für Dich ja transparent, der Key wird gespeichert während der Anmeldung mit fhem.
ssh-keygen -t rsa # Speichert automatisch in /opt/fhem/
probiere es aus, da wird es klar und sichtbar.
Du musst diesen Schlüssel natürlich mit sichern und mitnehmen.
Du musst allerdings auch verstehen, wie das mit den Schlüsseln funktioniert. Dann klappt auch alles sofort.
Vielleicht hilft das hier -> https://de.wikipedia.org/wiki/Public-Key-Authentifizierung
Zitat"sudo halt" seint nicht zu gehen.
aber nur "halt" seint auch zu gehen.
Dann hat die NAS kein sudo?!
Gruß Otto
sudo kann, glaube ich, nachinstalliert werden.
Habe denn key jetzt in die opt/fhem/.ssh gespeichert.
Jetzt geht es ohne Pfadangabe.
Danke Otto
du brauchst kein sudo auf synology seite.
versuch mal ob admin zum runterfahren reicht.
ansonsten kannst du ssh root@host verwenden.
du musst den key nur im .ssh verzeichnis des root users hinterlegen.
Du mußt nicht als User fhem den Key generieren, aber er muß die passende Berechtigung haben. Es ist natürlich einfacher, wenn Du dieses per ssh-keygen generieren lässt.
Was nicht verstanden wurde:
- werde zu "root"
- werde dann zu fhem
der User root braucht beim Userwechsel kein Passwort. In der Kurzform:
sudo su - fhem
Da ich baer immer vom User root ausgegangen bin, habe ich das "sudo" nicht hingeschrieben ..
Danke für die Antwort:
Zitatsudo su - fhem
geht nicht wenn für root kein password gesetzt ist.
Zitatsudo -H -u fhem ssh.........
sudo -u fhem ssh.........
solte gehen.
Kann aber sein das beim ausführen nicht auf das Home Verzeichnis von FHEM zugreift..
Das stimmt nicht. Hier extra ausprobiert.
Es muß nur für den user eine shell definiert sein
ZitatDas stimmt nicht. Hier extra ausprobiert.
Es muß nur für den user eine shell definiert sein
Ok.
Dann liegt es bei mir an der fehlenden Shell für FHEM USER.
Mit dem DS 207 klappt das mit Ssh wunderbar.
Aber mit dem neueren DS213j geht das nicht.
Hab es da mit User Admin und Damu versucht.
Key ist hinterlegt, Benutzerrechte angepasst.
Alles wie in der Anleitung.
Irgendwas fehlt aber trotzdem.
Hi Damu,
Du solltest bedenken und verstehen, dass Du an verschiedenen "Baustellen" kämpfst.
1. sudo ist ein Hilfsmittel, damit man normalerweise nicht mit "root" Berechtigungen am System angemeldet ist und arbeitet. Mit sudo kann man temporär den Benutzerkontext wechseln. Wenn es das auf dem System nicht gibt, ist es nicht weiter schlimm. Man verwendet es dann einfach nicht, muss aber admin Berechtigungen haben um bestimmte Aktionen auszuführen.
2. Remote Zugriff per ssh: sollte prinzipiell erst mal interaktiv gehen, also mit Benutzer Anmeldung. Normal kannst Du immer mit ssh remoteBenutzer@remoteSystemHostnameOderIP per ssh von einem lokalem System auf das Remotesystem zugreifen und wirst dabei nach dem remoteBenutzerPasswort gefragt. Vorausgesetzt ssh ist auf dem remoteSystem aktiv.
3. Die Übung mit den Schlüsseln dient dem Zugriff auf ein Remotesystem ohne Passwortabfrage, aber mit unverminderter Sicherheit (ich weiß darüber kann man philosophieren). Damit kann man dann auch mal Scripte ausführen lassen. Trotzdem passiert dieser Zugriff von einem lokalen Benutzer auf ein remoteSystem unter Verwendung eines bekannten remoteBenutzer Accountes.
Man darf dabei nicht den Überblick verlieren 8)
Also was geht jetzt nicht auf der DS213j ?
Gruß Otto
Hallo
Habe bei beiden Nas die gleichen Einstellungen gemacht.
Das Nas das geht hat DSM3.1 geht über root.
Das Nas das nicht geht hat DSM6.0 geht über admin.
Direkte Anmeldung über root geht bei diesem OS nicht.
Benutzerrechte sind die selben gesetzt.
Bei DSM3.1 sieht es so aus:
damu@fhem:~$ ssh -v root@192.168.178.7
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.178.7 [192.168.178.7] port 22.
debug1: Connection established.
debug1: identity file /home/damu/.ssh/id_rsa type 1
debug1: identity file /home/damu/.ssh/id_rsa-cert type -1
debug1: identity file /home/damu/.ssh/id_dsa type -1
debug1: identity file /home/damu/.ssh/id_dsa-cert type -1
debug1: identity file /home/damu/.ssh/id_ecdsa type -1
debug1: identity file /home/damu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/damu/.ssh/id_ed25519 type -1
debug1: identity file /home/damu/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 25:c9:58:8d:84:cd:72:5e:18:83:9c:6b:c8:94:a0:02
debug1: Host '192.168.178.7' is known and matches the RSA host key.
debug1: Found key in /home/damu/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/damu/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.178.7 ([192.168.178.7]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_CH.UTF-8
BusyBox v1.16.1 (2014-09-04 11:01:59 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Nas2>
Beim Nas mit DSM6.0:
damu@fhem:~$ ssh -v admin@192.168.178.60
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.178.60 [192.168.178.60] port 22.
debug1: Connection established.
debug1: identity file /home/damu/.ssh/id_rsa type 1
debug1: identity file /home/damu/.ssh/id_rsa-cert type -1
debug1: identity file /home/damu/.ssh/id_dsa type -1
debug1: identity file /home/damu/.ssh/id_dsa-cert type -1
debug1: identity file /home/damu/.ssh/id_ecdsa type -1
debug1: identity file /home/damu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/damu/.ssh/id_ed25519 type -1
debug1: identity file /home/damu/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ba:6f:18:01:fb:81:f1:df:07:0e:2a:b8:49:8e:dc:9f
debug1: Host '192.168.178.60' is known and matches the ECDSA host key.
debug1: Found key in /home/damu/.ssh/known_hosts:4
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/damu/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/damu/.ssh/id_dsa
debug1: Trying private key: /home/damu/.ssh/id_ecdsa
debug1: Trying private key: /home/damu/.ssh/id_ed25519
debug1: Next authentication method: password
Beim DSM6.0 akzeptiert das Nas den Key nicht und verlangt ein Password.
Die Keys sind aber die selben.
auch bei dsm 6.x kann man sich direkt per ssh als root anmelden sobald der key ausgetauscht ist. nur die anmeldung als root per password geht nicht.
[rojo:~] andre% ssh root@diskstation
root@DiskStation:~# uname -a
Linux DiskStation 3.10.77 #8451 SMP Tue Dec 20 16:19:56 CST 2016 x86_64 GNU/Linux synology_cedarview_1813+
Zitatauch bei dsm 6.x kann man sich direkt per ssh als root anmelden sobald der key ausgetauscht ist. nur die anmeldung als root per password geht nicht.
Danke.
Aber irgendwie hilft mir das nicht.
Die Anmeldung per ssh mit key klappt nicht bei OS6.0
und warum hilft das nicht?
hast du den entsprechenden key im authorized_keys file im .ssh verzeichnis von root hinterlegt?
Und auf den Besitzer der Datei (root) geachtet?
Hallo
Hab die datei in Home von root, admin und auch damu kopiert.
Bei root komm ich gar nicht rein auch nicht per ssh.
Admin und damu geht nur mit Password.
Auf root mit der Konsole geht über admin mit "sudo -i"
Der Key wird nicht akzeptiert.
Mache das syno Nas mal Platt und setze es neu auf.
Dann versuche ich mal das der Key das Syno Nas erstellt und kopiere ihn da auf den Nuc.
http://gander.in/dsm-6-und-login-als-root/ (http://gander.in/dsm-6-und-login-als-root/)
Wenn Du noch nicnht plat gemacht hasdt, gucke doch mal in den Logfiles, was dort steht.
Unter linux: /var/log/auth.log
Unter Synology (da ich gerade nicht gucken kann), muss es ähnlich sein (nicht gleich!)
Hallo
Habe es neu Installiert.
Der Fehler scheint aber die Datei "known_hosts" unter ".ssh" auf dem Nuc zu sein.
Du hast warscheinlich unter known_hosts einen veralteten Eintrag drin ..
wenn Du als User fhem vom NUC Dich versuchst auf die Synology einzuloggen, was sagt denn ssh als output?
Hab die Datei "known_hosts" auf dem Nuc gelöscht.
Sie wird bei jeder ersten Anmeldung angelegt.
Jetzt klappt es aber nur mit root. Weis aber nicht wieso nur mit root.
admin hat denselben key.
Habe aber nun auf dem Nuc eine "id_rsa (id_rsa_nas4)" vom Synology erstellt.
Ich versuche es auf die normale "id_rsa" erstellt vom Nuc.
Wenn Du Dich bei einem Server per ssh anmeldest, wirst Du bei beim ersten Mal gefragt, ob er den Zielserverkey speichern darf. Genau der landet im known-host. Damit stellt das System sicher, das es bei jeder ANmeldung beim richtigen System landet.
Da Du dieses nur für ein System gemacht hast, kann es nur bei dem.
Lösung:
Logge Dich von der Konsole auf das 2. System mal an .....
ZitatDa Du dieses nur für ein System gemacht hast, kann es nur bei dem.
Beim DS207 geht es über den NUC mit User FHEM und User Damu immer auf root vom DS.
Beim DS112+ geht es über den NUC mit User FHEM und User Damu mit der "id_rsa (id_rsa_nas4)" vom DS112+ erstellt nur mit user root.
Bin beim DS112+ auf der Konsole mit user admin.
Bei der ersten Anmeldung kommt die Meldung:
Zitat(ECDSA) to the list of known hosts
??? Irgendwie verstehe ich Dich nicht, sorry ....
Bevor wir jetzt weiter "rumraten":
Du bist auf dem NUC alsUser fhem eingelogt. Muß so sein, da Du es mit fhem starten willst und deshalb .... oder läuft bei Dir fhem unter dem user Damu??
Also .. Du bist jetzt fhem und machst
ssh root@DS207
ssh admin@DS112
DS207 und DS112 bitte passend ersetzen. So funktioniert es? Oder was bekommst Du für ausgaben?
Eventuell einfach mal den Debuglevel "hochdrehen":
ssh -v root@DS207
ssh -v admin@DS112
Bitte gebe mir den Output (in CODE-Tags)
Hallo
Danke für die Hife.
Zitatssh -v root@DS207
ssh -v admin@DS112
Hab ich in Beitrag #60 eingestellt.
Habe es nun beim DS112 mit OS6.0 auch mit root@DS112 versucht.
So klappt es.
Beim ersten Einloggen über ssh@DSmitOS6.0 kommt:
Zitat[damu@fhem:~$ sudo -u fhem ssh root@DSmitOS6.0
The authenticity of host '192.168.178.18 (192.168.178.18)' can't be established.
ECDSA key fingerprint is ............................................
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.178.18' (ECDSA) to the list of known hosts.
root@Nas4:~# exit
/quote]
Beim ersten Einlogen über ssh@DS3.1
Zitatdamu@fhem:~$ sudo -u fhem ssh root@DSmitOS3.1
The authenticity of host '192.168.178.9 (192.168.178.9)' can't be established.
RSA key fingerprint is ................................................
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.178.9' (RSA) to the list of known hosts.
BusyBox v1.16.1 (2014-09-04 11:01:59 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
Nas1> exit
Beim DS3.1 scheints über RSA und bei DS6.1 über ECDSA zu gehen.
Habe es mehreremal versucht, es scheint beim DS mit OS6.1 nur über root@DS zu gehen.
op der User jetzt root, admin oder brotchen heißt, ist DIr doch eigentlich egal ... Hauptsache er kann das, was Du willst ....
Zitatop der User jetzt root, admin oder brotchen heißt, ist DIr doch eigentlich egal ... Hauptsache er kann das, was Du willst ....
Ist schon egal, muss mann aber zuerst wissen.
Hab nochmals aufgeschrieben wie ich es gemacht habe:
Wenn in Fhem unter opt/fhem der ordner .ssh noch fehlt diesen mit PuTTY erstellen.
Zitatsudo mkdir -p /opt/fhem/.ssh
chmod 0700 /opt/fhem/.ssh
chown -R fhem /opt/fhem/.ssh/
Danach am Nuc auch über PuTTY einen SSH Key für Fhem erstellen
Zitatsudo -u fhem ssh-keygen -b 4096 -t rsa -f /opt/fhem/.ssh/id_rsa
https://wiki.ubuntuusers.de/SSH/
Die Rechte sollten eigentlich korrekt sein,sonst richtigstelllen:
Zitat
chmod 0644 /opt/fhem/.ssh/id_rsa
chmod 0644 /opt/fhem/.ssh/id_rsa.pub
Bei Synology (mit OS6.0)
Es scheint hier nur über den Benutzer root zu gehen.
Die Anmeldung über ssh ohne key geht nicht, da root kein Password kennt.
Habe zuerst alles auf dem User Admin gemacht und danach nach root kopiert.
Auf dem Synology Home Verzeichnis erstellen, Rechte anpassen etc.
Über PuTTY Benutzer Admin:
Zitat
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chown -R admin ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
Denn Key vom Nuc mit PuTTY auf das Synology kopieren:
Zitatsudo -u fhem ssh-copy-id -i opt/fhem/.ssh/id_rsa.pub admin@DSmitOS6.0
Den Key auf Benutzer root kopieren.
Zuerst den Benutzer von admin auf root wechseln:
Danach Ordner erstellen und die Datei kopieren.
Zitatsudo -i
mkdir -p /root/.ssh
chmod 0700 /root/.ssh
cp /volume1/homes/admin/.ssh/authorized_keys ~/.ssh
chown -R root ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
Danach SSH am Synology neu starten.
Am besten über Telnet oder Synology komplet neu starten.
Zitatsynoservicectl --restart sshd
Danach am Nuc mit PuTTY sich mit ssh am Synology anmelden.
Zitatssh root@ipDS
Beim ersten mal Bestätigen.
Danach das selbe über user fhem:
Zitatsudo -u fhem ssh root@ipDS
Hier auch einfach bestätigen.
Beim zweiten versuch sollte es ohne Password funktionieren.
Zurück auf den Nuc kommt man einfach mit:
Zitatexit
Der Befehl zum ausschalten in FHEM lautet:
Zitat{system ('ssh root@ipDS poweroff')}
FHEM gibt dann leider
Zitat-1
zurück
Vieleicht ist der Ausschaltbefehl besser in der 99_myUtils.pm aufgehoben.
Das DS meldet doch das es nun aus geht?
Beim Synology mit OS3.1, geht das direkt mit root:
Mit PuTTY auf Benutzer root anmelden.
Alle Ordner auf Benutzer root erstellen, Benutzerrechte anpassen.
Zitatchmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chown -R root ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
Der Key kommt vom Nuc dann direckt auf Benutzer root, nicht zuers auf admin.
Zitatsudo -u fhem ssh-copy-id -i opt/fhem/.ssh/id_rsa.pub admin@DSmitOS6.0
Auf dem NUC hättest Du die authorized_keys nicht kopieren müssen. Dort steht drin, wer darf. Beim NUC willst Du aber raus und nicht rein.
Für die Doku: Zuerst solltest Du dafür sorgen, das die Verzeichnisse existieren:
mkdir -p /opt/fhem/.ssh
Da Du die Rechte sowieso anpasst, würde ich es sogar noch etwas härter machen:
chmod 0600 /opt/fhem/.ssh/id_rsa*
Allerdings ... eigentlich macht man es nicht so, das man ein key erstellt und es dem User reinkopiert, sondern man erstellt am besten den key als der User!
Zitatmkdir -p /opt/fhem/.ssh
Komisch, bei mir war das schon da?
Danke.
ZitatAllerdings ... eigentlich macht man es nicht so, das man ein key erstellt und es dem User reinkopiert, sondern man erstellt am besten den key als der User!
Ich weis, aber ich möchte keinen USER FHEM erstellen. Ich meine User mit Login und Password
Möchte das es beim Umzug von FHEM auf einen anderen Server auch ohne Anpassung klappt.
Zitatsudo -u fhem ssh-keygen -t rsa -b 4096
oder so?
Zitatsudo -u fhem ssh-keygen -b 4096 -t rsa -f /opt/fhem/.ssh/id_rsa
Zitat von: Damu am 08 Februar 2017, 09:49:55
Ich weis, aber ich möchte keinen USER FHEM erstellen.
Möchte das es beim Umzug von FHEM auf einen anderen Server auch ohne Anpassung klappt.oder so?
Den User
fhem musst Du nicht erstellen, den gibt es ja. Es geht ja um das FHEM System nicht um das NAS System.
Beim Umzug von FHEM sicherst Du einfach /opt/fhem/.ssh mit! Ist im Standard backup nicht drin!
@Werner Oder geht das so nicht?
Gruß Otto
Danke Otto da muss ich schauen das .ssh auch mitkommt.
Otta: ja so geht es.
@Damu:
Wenn Du Dich zu einem neuen Server hin verbindest, Du also ncoh keinen ssh-Kontackt hattest und er deshalb folgerichtig nichts in der known_host steht, must Du Dich sowieso einmalig als fhem User mit dem Server verbinden um alle Meldungen mit (y) wegzubekommen. Sonst funzt das Automatische einloggen nicht.
Du must auf einem neuen System, wie schon mal geschrieben, dem User fhem kein Passwort geben. Er muß "nur" eine shell haben. Also in der passwd nach der Zeile suchen:
fhem:x:1000:1000::/opt/fhem:/bin/bash
Wenn dort am Ende anstatt "/bin/bash" etwas anderes steht, wie z.>B. /bin/false" oder "/bin/nologin", dur4ch "/bin/bash" ersetzen. Allerdings ist für die Fehlersuche es immer interessant, wenn man "schnell mal zum User fhem werden kann". Ohne passwort muß man "nur" einen Umweg über root machen:
sudo su - fhem
Hallo
Danke für die Antwort.
Zitatsudo su - fhem
Hab ich versucht.
Klappt aber bei mir nicht.
damu@fhem:~$ sudo su - fhem
[sudo] password for damu:
damu@fhem:~$
Ich bleib so bei damu@fhem, es sollte auf fhem@fhem gehen.
Aber mit:
Zitatsudo su -m fhem
und
Zitatsudo su -p fhem
geht.
damu@fhem:~$ sudo su -m fhem
fhem@fhem:~$ exit
exit
damu@fhem:~$ sudo su -p fhem
fhem@fhem:~$ exit
exit
damu@fhem:~$
Unterschied????
ZitatWenn Du Dich zu einem neuen Server hin verbindest, Du also ncoh keinen ssh-Kontackt hattest und er deshalb folgerichtig nichts in der known_host steht, must Du Dich sowieso einmalig als fhem User mit dem Server verbinden um alle Meldungen mit (y) wegzubekommen. Sonst funzt das Automatische einloggen nicht.
Hab die erste Anmeldung, für die Bestädigung, so gemacht.
Zitatsudo -u fhem ssh root@ipDS
Hat so geklappt.
Jetzt brauch ich noch eine Lösung beim Backup.
O.K. passiert wenn man nicht testet, so sollte es (wieder nicht getestet) gehen
sudo su -l fhem
Wichtig ist das "-" bzw. "-l", da nur dann auch die Umgebung von fhem geladen wird. Sonst testest Du nicht ...
Hi Damu,
Bedeutung su -> https://linux.die.net/man/1/su
Aber ich habe an der Stelle einfach su fhem gemacht, ohne sudo davor.
Gruß Otto