mit fhem windows steuern - alternativensuche

[the ratman]

so, einrichtung auf meinem schleppi erledigt. kriege per ssh die shell, scheint also mal zu funzen. mehr hab ich derweil nicht probiert.

deine anleitungen werden idiotensicherer *lach*

ich frag' mich grade, ob man das nicht in ein fhem modul packen könnte - so für jene, die noch weniger als ich verstehen ...
meine, die linux-seite wäre dann abgedeckt und windows den server nachzuinstallieren ist auch ned schwer.

aja, erwähne mal bei dir, dass der opensshserver und der agent dafür in den diensten besser auf automatischen start gestellt werden sollten. zumindest bei mir waren beide "manueller start" (hoffe, ich hab das bei dir jetzt ned übersehen, hab einfach nur mal schnell befehle kopiert)

[Otto123]

der opensshserver und der agent dafür in den diensten besser auf automatischen start gestellt werden sollten.

Steht in Zeile 2

Code Auswählen Erweitern

Get-Service -Name sshd | Set-Service -StartupType AutomaticDen Agenten braucht man mMn nicht.

[the ratman]

fux - eh klar. hatte den server schon über die optionalen features installiert gehabt, den teil in deiner anleitung natürlich nur überflogen *g*
asche über mein haupt.

btw. - der agent muss dann entweder mit dem server mit installiert worden sein, oder war schon installiert. mir ist der nur aufgefallen, weil ich eben aufgrund meiner "klick-installation", die automatik ja erst einschalten musste.

na ja, wurscht. auf jeden fall war das angenehm einfach.

[Otto123]

der Agent ist immer installiert. Das ist eventuell ein Teil, was für den ssh Client (der ist ja auch immer installiert) benutzt werden kann. Hab mich bisher damit nicht beschäftigt.

Schön das es funktioniert

[the ratman]

gut, halb funzt es *g*

ich komme, wie gesagt per terminal und user fhem auf den pc
bspl.:

Code Auswählen Erweitern

fhem@luke-8:/root$ ziel=xxx@192.168.178.21
fhem@luke-8:/root$ ssh $ziel
xxx@192.168.178.21's password:
-----------------------------------
Microsoft Windows [Version 10.0.22621.1928]
(c) Microsoft Corporation. Alle Rechte vorbehalten.

xxx@LITTLEBASTARD C:\Users\xxx>wunderbar

aber von fhem weg pack ichs ned
ich probiere:
"ssh -T xxx@192.168.178.21 'C:\Users\xxx\Music\foobar2000\foobar2000.exe /playpause'"
oder auch
"ssh -T fhem@192.168.178.21 'C:\Users\xxx\Music\foobar2000\foobar2000.exe /playpause'"
ergibt:

Code Auswählen Erweitern

xxx@192.168.178.21: Permission denied (publickey,password,keyboard-interactive).
Permission denied, please try again.
Permission denied, please try again.
fhem@192.168.178.21: Permission denied (publickey,password,keyboard-interactive).
Permission denied, please try again.was hab ich wieder übersehen? gleich wirds wieder peinlich *g*

[Otto123]

Du hast eventuell den public key nicht übertragen? Der Terminal Auszug oben fragt nach dem Passwort, public key Autorisierung geht ohne Passwort.
Hat der User fhem überhaupt ein Key Pärchen?

Code Auswählen Erweitern

sudo -su fhem
ls -lha ~/.sshOder in FHEM in der Kommandozeile

Code Auswählen Erweitern

{qx(ls -lha ~/.ssh)}Hat littlebastard schon eine Datei authorized_keys?
Du stehts hier:

Code Auswählen Erweitern

xxx@LITTLEBASTARD C:\Users\xxx>Dann

Code Auswählen Erweitern

dir .ssh

[the ratman]

nu denne:

Code Auswählen Erweitern

fhem@luke-8:/root$ ls -lha ~/.ssh
insgesamt 20K
drwx------  2 fhem dialout 4,0K  5. Jul 13:31 .
drwxr-xr-x 14 fhem dialout 4,0K  5. Jul 13:32 ..
-rw-------  1 fhem dialout  399  5. Jul 13:08 id_ed25519
-rw-r--r--  1 fhem dialout   93  5. Jul 13:08 id_ed25519.pub
-rw-r--r--  1 fhem dialout  222  5. Jul 13:31 known_hosts

Code Auswählen Erweitern

C:\Users\xxx\.ssh>dir
 Datenträger in Laufwerk C: ist System
 Volumeseriennummer: 988B-B3B6

 Verzeichnis von C:\Users\xxx\.ssh

05.07.2023  20:49    <DIR>          .
06.07.2023  08:47    <DIR>          ..
05.07.2023  13:08               399 id_ed25519
05.07.2023  13:08                93 id_ed25519.pub
               2 Datei(en),            492 Bytes
               2 Verzeichnis(se), 311 061 815 296 Bytes freida könnte der fehler liegen. ich musste .ssh selber anlegen und hab die daten von der fhem-seite kopiert. sicher wieder zu naiv gedacht?

[Otto123]

hab die daten von der fhem-seite kopiert. sicher wieder zu naiv gedacht?

leider völlig falsch. Hatte ich auch nirgendwo so geschrieben
Mach bitte folgendes:
Du stehst hier: fhem@luke-8:/root$

Code Auswählen Erweitern

cat ~/.ssh/id_ed25519.pubDie Ausgabe kopierst Du in die Zwischenablage - muss in etwa so aussehen! Also drei Worte, eine Zeile

Code Auswählen Erweitern

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFfqZQDEcjL7ZGWQKImsupE2SDSfsz7I/Qgb6PxXII3z fhem@fhem-dockerDann stehst Du hier C:\Users\xxx\.ssh>
entweder

Code Auswählen Erweitern

notepad authorized_keysund die Zeile aus der Zwischenablage einfügen und speichern. Oder

Code Auswählen Erweitern

echo DeineZeile >>authorized_keys
Hinweis: Du kannst auch den kompletten Pfad angeben (wenn Du woanders stehst) %HOMEDRIVE%%HOMEPATH%\.ssh\authorized_keys

Danach sollte bei

Code Auswählen Erweitern

fhem@luke-8:/root$ ziel=xxx@192.168.178.21
fhem@luke-8:/root$ ssh $zielkeine passwort Abfrage mehr kommen - falls doch - kann noch folgendes Problem vorliegen:
Der Benutzer ist Mitglied der Gruppe Administratoren dann musst Du einmalig noch folgendes machen:

Code Auswählen Erweitern

notepad C:\ProgramData\ssh\sshd_configganz am Ende gibt es eine Zeile, die musst Du auskommentieren:

#Match Group administrators
#       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

[the ratman]

• sudo -su fhem
• cat ~/.ssh/id_ed25519.pub --> ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPg3RValfPOP0c53bVnllxkdhUBqH6/C97rBk3HcR22U fhem@luke-8
• eingefügt in "authorized_keys" hab ich eben (ein normales textfile utf8 ohne endung) angelegt und obige zeile reinkopiert.
• in der sshd_config hab ich die zeile auskommentiert
• sicherheitshalber den schleppi restarted ...

"ssh -T xxx@192.168.178.21 'C:\Users\xxx\Music\foobar2000\foobar2000.exe /playpause'"
keine fehlermeldung mehr in fhem, aber am schleppi passiert nix.

hmm, fehler bei win?

Code Auswählen Erweitern

Fehler beim Anmelden eines Kontos.

Antragsteller:
Sicherheits-ID: SYSTEM
Kontoname: LITTLEBASTARD$
Kontodomäne: WORKGROUP
Anmelde-ID: 0x3E7

Anmeldetyp: 8

Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: NOUSER
Kontodomäne: LittleBastard

Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D
Unterstatus:: 0xC0000064

Prozessinformationen:
Aufrufprozess-ID: 0x16c0
Aufrufprozessname: C:\Windows\System32\OpenSSH\sshd.exe

Netzwerkinformationen:
Arbeitsstationsname: LITTLEBASTARD
Quellnetzwerkadresse: -
Quellport: -

Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: Advapi 
Authentifizierungspaket: Negotiate
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0

Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.

Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".

Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).

Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.

Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an.  Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.

Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.

[Otto123]

Der "einfache" Test ohne Fallstricke in FHEM wäre in der FHEM Kommandozeile

Code Auswählen Erweitern

{qx 'ssh xxx@192.168.178.21 echo vom HostB' }
Der Windows Fehler scheint mir zu melden das der user xxx nicht existiert. Aber das kann ja nicht sein.

Ich hatte den Fallstrick vergessen: Du musst für ssh Zugriff auf Windows von Linux in jedem Fall die \ schützen 

Code Auswählen Erweitern

"ssh -T xxx@192.168.178.21 'C:\\Users\\xxx\\Music\\foobar2000\\foobar2000.exe /playpause'"Ich umgehe so etwas gerne, indem ich die Befehle in Scriptdateien packe.

Eigentlich steht auch ne Meldung im FHEM Log?

EDIT: Aber bevor wir damit weiter versuchen: Ich kann foobar2000 über diesen Weg nicht kontrollieren, da gibt es ein Berechtigungsproblem ...

[the ratman]

{qx 'ssh xxx@192.168.178.21 echo vom HostB' }

ergibt (natürlich mit dem richtigen win-user und nicht xxx *g*):
o) kein eintrag im logfile von fhem
o) nix passiert auf win-seite

sag amal: wenn ich als derselbe user auf win schon angemeldet bin, könnte das probleme geben?
im systemprotokoll:

Code Auswählen Erweitern

Ein Konto wurde erfolgreich angemeldet.

Antragsteller:
    Sicherheits-ID:        SYSTEM
    Kontoname:        LITTLEBASTARD$
    Kontodomäne:        WORKGROUP
    Anmelde-ID:        0x3E7

Anmeldeinformationen:
    Anmeldetyp:        5
    Eingeschränkter Administratormodus:    -
    Remote Credential Guard:    -
    Virtuelles Konto:        Ja
    Token mit erhöhten Rechten:        Ja

Identitätswechselebene:        Identitätswechsel

Neue Anmeldung:
    Sicherheits-ID:        VIRTUAL USERS\sshd_14704
    Kontoname:        sshd_14704
    Kontodomäne:        VIRTUAL USERS
    Anmelde-ID:        0x1233486
    Verknüpfte Anmelde-ID:        0x0
    Netzwerk-Kontoname:    -
    Netzwerk-Kontodomäne:    -
    Anmelde-GUID:        {00000000-0000-0000-0000-000000000000}

Prozessinformationen:
    Prozess-ID:        0x3970
    Prozessname:        C:\Windows\System32\OpenSSH\sshd.exe

Netzwerkinformationen:
    Arbeitsstationsname:    -
    Quellnetzwerkadresse:    -
    Quellport:        -

Detaillierte Authentifizierungsinformationen:
    Anmeldeprozess:        Advapi 
    Authentifizierungspaket:    Negotiate
    Übertragene Dienste:    -
    Paketname (nur NTLM):    -
    Schlüssellänge:        0

Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.

Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie Winlogon.exe oder Services.exe.

Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).

Die Felder für die neue Anmeldung geben das Konto an, für das die neue Anmeldung erstellt wurde, d. h. das angemeldete Konto.

Die Netzwerkfelder geben den Ursprung einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.

Das Feld für die Identitätswechselebene gibt an, in welchem Umfang ein Prozess in der Anmeldesitzung einen Identitätswechsel vornehmen kann.

Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser spezifische Anmeldeanforderung.
    – Die Anmelde-GUID ist ein eindeutiger Bezeichner, der verwendet werden kann, um dieses Ereignis mit einem KDC-Ereignis zu korrelieren.
    – Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
    – Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
und "special logon"

Code Auswählen Erweitern

Einer neuen Anmeldung wurden besondere Rechte zugewiesen.

Antragsteller:
    Sicherheits-ID:        VIRTUAL USERS\sshd_14704
    Kontoname:        sshd_14704
    Kontodomäne:        VIRTUAL USERS
    Anmelde-ID:        0x1233486

Berechtigungen:        SeImpersonatePrivilegeer passt auch die policy an ... aber dann wird einfach abgemeldet:

Code Auswählen Erweitern

Ein Konto wurde abgemeldet.

Antragsteller:
    Sicherheits-ID:        VIRTUAL USERS\sshd_14704
    Kontoname:        sshd_14704
    Kontodomäne:        VIRTUAL USERS
    Anmelde-ID:        0x1233486

Anmeldetyp:            5

Dieses Ereignis wird generiert, wenn eine Anmeldesitzung zerstört wird. Es kann anhand des Wertes der Anmelde-ID positiv mit einem Anmeldeereignis korreliert werden. Anmelde-IDs sind nur zwischen Neustarts auf demselben Computer eindeutig.sicher nicht von mir *g*

was foobar angeht, so hat das genau so bis jetzt mit winconnect gefunzt. bspl. https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Commandline_Guide
mein vollständiges und funzendes doif aus dem derzeigien fhem dazu:

Code Auswählen Erweitern

([$SELF:cmd_1])
( set littlebastard_winconnect commandhide "C:\Users\xxx\Music\foobar2000\foobar2000.exe" /playpause )

DOELSEIF

([$SELF:cmd_2])
( set littlebastard_winconnect commandhide "C:\Users\xxx\Music\foobar2000\foobar2000.exe" /next )

DOELSEIF

([$SELF:cmd_3])
( set littlebastard_winconnect commandhide "C:\Users\xxx\Music\foobar2000\foobar2000.exe" /prev )

DOELSEIF

([$SELF:cmd_4])
( set littlebastard_winconnect commandhide "C:\Users\xxx\Music\foobar2000\foobar2000.exe" /stop )

DOELSEIF

([$SELF:cmd_5])
( set littlebastard_winconnect commandhide "C:\Users\xxx\Music\foobar2000\foobar2000.exe" /play )

[Otto123]

o) nix passiert auf win-seite

Aber im Browser von FHEM sollte doch die echo Meldung kommen?  Sonst funktioniert es immer noch nicht.

[the ratman]

nö, da kommt nix im log ...
aber es kommt doch was an bei win: "Einer neuen Anmeldung wurden besondere Rechte zugewiesen."

btw - hab im obigen beitrag gerade erweitert, als du geschrieben hattest. nur, damit dus nicht übersiehst *g*
und ich hab grad mein obiges doif nochmal probiert - das funzt. also die befehle gehen sicher.

[Otto123]

sag amal: wenn ich als derselbe user auf win schon angemeldet bin, könnte das probleme geben?

Eigentlich nicht, mach ich genauso.

Was passiert denn wenn Du mit

Code Auswählen Erweitern

sudo -su fhem
ssh xxx@192.168.178.21eine interaktive Sitzung öffnest? Wird ein Passwort abgefragt?

Ich bin etwas ratlos

[the ratman]

nö, ich krieg' sofort die konsole, kein pwd nötig. (als test ruf' ich dann auch noch n "dir" auf. das kommt auch korrekt)
das ist ja immerhin schon ein fortschritt zu gestern *g*

schön, dann haben wir gemeinsamkeiten *g*


ich schreib' zur sicherheit nochmal meine standards auf:
das system ist "omv", also ein kleines debian mit omv als "grafische oberfläche". installiert per omv, also *nicht* vorher debian, dann omv, sondern das image von der omv-seite.
fhem ist da drauf ganz normal (also kein container, keine dummen spielchen über omv) installiert und läuft (inkl. des users "fhem") unauffällig == ich kann z.b. auf sämtliche hw zugreifen, nix im neuen fhem verhält sich anders als im echt-fhem.
der user "xxx" hat eingeschränkte adminrechte auf win.
was wäre noch wichtig zu wissen?

nachtrag:
habs jetzt nicht nur per "web-console" der omv probiert, sondern auch mal "kiddy" bemüht (is putty, nur mit der möglichkeit pwd's zu speichern) - auch dort gehts. und zwar direkt vom angesprochenen schleppi, wie auch von meiner aktiven nas weg, also auch hardware-technisch getrennt.
sprich: ich hab jetzt mal "direkt" vom meinem nuc (das zukünftige fhem) und auch mit konsole vom win-schhleppi (vielleicht macht es ja unterschiede) probiert.
verhalten is immer gleich