Hallo zusammen,
ich habe diesen Thread schon gefunden:
https://forum.fhem.de/index.php?topic=81121.0 (https://forum.fhem.de/index.php?topic=81121.0)
als auch Ottos Blogeintrag:
https://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html (https://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html)
hänge aber noch... Der Stand ist:
ich habe am lokalen System Fhem laufen, dort habe ich einen rsa key generiert und auf dem remote system (WD MyCloud) übertragen. Am remote System finde ich diesen auch wieder.
Ich kann mich auch per ssh root@remotesystem vom lokalen System auf mit dem remotesystem ohne passwort verbinden
allerdings nicht mit dem User fhem hier wird weiterhin das Passwort abgefragt.
Gibt es einen Tip wohin ich gucken muss?
Danke und Gruß
Du hättest das alles als User fhem machen sollen. Oder aber Du kopiert Deinen .ssh Ordner ins /opt/fhem/ Verzeichnis und passt die Rechte entsprechend für den User fhem an.
Zitat von: jeti am 04 Januar 2019, 11:47:01
Hallo zusammen,
ich habe diesen Thread schon gefunden:
https://forum.fhem.de/index.php?topic=81121.0 (https://forum.fhem.de/index.php?topic=81121.0)
als auch Ottos Blogeintrag:
https://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html (https://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html)
hänge aber noch... Der Stand ist:
ich habe am lokalen System Fhem laufen, dort habe ich einen rsa key generiert und auf dem remote system (WD MyCloud) übertragen. Am remote System finde ich diesen auch wieder.
Ich kann mich auch per ssh root@remotesystem vom lokalen System auf mit dem remotesystem ohne passwort verbinden
allerdings nicht mit dem User fhem hier wird weiterhin das Passwort abgefragt.
Gibt es einen Tip wohin ich gucken muss?
Danke und Gruß
wie warst du denn auf lokalem system bei einrichtung angemeldet ?
..... du musst das unter dem Account/User 'fhem' machen.
gruss Byte09
Hallo zusammen,
ah ok, war als root angemeldet, ich probiere und gebe Bescheid,
Danke schonmal!!!
Gruß
Hi,
einfach das tun was ich beschrieben habe, das funktioniert :)
Manchmal ist jedes Wort im Text wichtig und Ruhe ist gefragt :) ;D
Gruß Otto
:'( ich Probiere morgen nochmal... bisher keine Verbesserung...
auch nach mit Ottos Anleitung als User fhem...
Eigentlich gehts doch nur um die keys, oder? der id_ras.pub auf dem local client ist identisch mit dem authorized_keys am remote client...
per Passwort klappts aber nicht ohne... mmpf
Wenn Du nicht klar kommst solltest Du mehr Infos liefern. Es geht nicht - ist absolut ungenügend, da wird Dir keiner helfen können.
Also schreib bitte Step für Step auf was Du gemacht hast und welche Meldungen kommen! Und bitte nicht: Ich habe alles laut Anmeldung aber es geht immer noch nicht.
Hier noch ein Querverweis -> https://forum.fhem.de/index.php/topic,82942.0.html
Da waren Rechte falsch gesetzt.
Denke vor allem darüber nach mit welchen User Du wirklich arbeiten willst. Mit root überhaupt arbeiten und dann noch mit ssh auf das Remotesystem ist eigentlich ein NoGo!
Gruß Otto
Zitat von: jeti am 04 Januar 2019, 17:37:08
per Passwort klappts aber nicht ohne... mmpf
Mit
ssh -vv kannst du dir anschauen was nicht "geht" und dann kannst du bessere Fragen stellen.
Hallo zusammen,
Otto hat natürlich recht, war gestern nur etwas frustriert...
also:
nun mit korrektem Nutzer Ottos Anleitung auf dem localen Rechner durchgeführt mit folgenden ergebnis:
ssh-copy-id -i ~/.ssh/id_rsa fhem@192.168.1.107wird mit
Zitat
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/opt/fhem/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
fhem@192.168.1.107's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'fhem@192.168.1.107'"
and check to make sure that only the key(s) you wanted were added.
quittiert, sieht also richtig aus, oder? -> ich habe auch schon den key auf dem remote client umbenannt und einen neuen erstellt und ssh auf beiden rechner neu gestartet, jedes mal die PW abfrage folgendes resultat:
Zitat
fhem@rock64:~/.ssh$ ssh -vv fhem@192.168.1.107 date
OpenSSH_7.6p1 Ubuntu-4ubuntu0.1, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.1.107" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.1.107 [192.168.1.107] port 22.
debug1: Connection established.
debug1: identity file /opt/fhem/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debia n-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.107:22 as 'fhem'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2 -nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sh a256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman- group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ex t-info-c
debug2: host key algorithms: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2- 256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v0 1@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@open ssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256 -ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256 -ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-25 6-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-6 4@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-25 6-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-6 4@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 ,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes 128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael -cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes 128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael -cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha 2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha 2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compress ion: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compress ion: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:f3kiNy5JoEDsZLp2JUUvrxmUsVFkcSNWGlAr+NZS nNk
debug1: Host '192.168.1.107' is known and matches the RSA host key.
debug1: Found key in /opt/fhem/.ssh/known_hosts:1
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug2: key: /opt/fhem/.ssh/id_rsa (0x5598d00fa0)
debug2: key: /opt/fhem/.ssh/id_dsa ((nil))
debug2: key: /opt/fhem/.ssh/id_ecdsa ((nil))
debug2: key: /opt/fhem/.ssh/id_ed25519 ((nil))
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:qYTk3GB443MT5cIpUixxl45fw14qt9WVLvPtHftW 680 /opt/fhem/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /opt/fhem/.ssh/id_dsa
debug1: Trying private key: /opt/fhem/.ssh/id_ecdsa
debug1: Trying private key: /opt/fhem/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
fhem@192.168.1.107's password:
Der remote client antwortet also nicht auf die Schlüsselanfrage, oder?
da Reche ein Problem sein könnten so sieht es aus auf dem local rechner:
Zitat
drwxr-xr-x 2 fhem dialout 4096 Jan 5 13:00 .ssh
Zitat
fhem@rock64:~/.ssh$ ls -la
total 20
drwxr-xr-x 2 fhem dialout 4096 Jan 5 13:00 .
drwxr-xr-x 14 fhem dialout 4096 Jan 4 17:21 ..
-rwxr-xr-x 1 fhem dialout 1679 Jan 5 12:54 id_rsa
-rwxr-xr-x 1 fhem dialout 393 Jan 5 12:54 id_rsa.pub
-rwxr-xr-x 1 fhem dialout 442 Jan 4 14:54 known_hosts
und auf dem remote:
Zitatdrwxrw-r-- 2 fhem fhem 4096 Oct 31 01:09 .ssh
Zitatfhem@Backup:~/.ssh$ ls -la
total 20
drwxrw-r-- 2 fhem fhem 4096 Oct 31 01:09 .
drwxr-xr-x 3 1000 fhem 4096 Oct 30 01:25 ..
-rw------- 1 fhem fhem 393 Oct 31 01:09 authorized_keys
-rwxrw-r-- 1 fhem fhem 393 Oct 31 01:07 authorized_keys.sav -> von mir "umbenannt um ssh-copy-id neue erstellen zu lassen
-rwxrw-r-- 1 fhem fhem 222 Oct 30 05:20 known_hosts.sav > von mir "umbenannt um ssh-copy-id neue erstellen zu lassen
Danke für die Geduld und für jeden Tip!
Gruß
Hi,
bist Du sicher auf welchem Rechner Du was tust? Ich nämlich nicht :-[
fhem@192.168.1.107
fhem@rock64
fhem@Backup
Das sind jetzt drei?
Die Rechte sind falsch, wie schon vermutet. Ob das das eigentliche Problem ist kann ich nicht sagen! So muss es aussehen:
drwx------ 2 fhem dialout 4096 Nov 25 00:00 .
drwxr-xr-x 13 fhem dialout 4096 Jan 12 2018 ..
-rw------- 1 fhem dialout 1675 Jan 17 2017 id_rsa
-rw-r--r-- 1 fhem dialout 394 Jan 17 2017 id_rsa.pub
-rw-r--r-- 1 fhem dialout 806 Nov 25 00:03 known_hosts
Steht Übrigens extra als Fehlerhinweis in meiner Anleitung! 8)
Gruß Otto
Hi Otto,
192.168.1.107 = Backup
192.168.1.185 = Rock64
Berechtigungen sind nun auf dem lokalen Rechner korrigiert:
Zitat
drw-r--r-- 2 fhem dialout 4096 Jan 5 13:00 .ssh
Zitat
drwxr-xr-x 14 fhem dialout 4096 Jan 4 17:21 ..
-rw------- 1 fhem dialout 1679 Jan 5 12:54 id_rsa
-rw-r--r-- 1 fhem dialout 393 Jan 5 12:54 id_rsa.pub
-rw-r--r-- 1 fhem dialout 442 Jan 4 14:54 known_hosts
aber nun (ich habe da wohl ein Verständnisproblem...) :
Zitat
fhem@rock64:~$ cd .ssh/
-bash: cd: .ssh/: Permission denied
der Ordner /opt/fhem.ssh gehört doch fhem (in der Grupper dialout) warum darf fhem jetzt nicht mehr auf den Ordner zugreifen?
Danke und Gruß
Weil du anstatt drwx drw gemacht hast :-X
chmod -v u+x .ssh
Du weisst schon, das z.B. die Hostzertifikate separat behandelt werden, je nach dem ob man IP Adressen oder Hostnamen nimmt?
Gruß Otto
Hi ich grab das alte Thema mal wieder aus, da ich das selbe Problem hab und Otto ja auch schon mit on Bord ist :-)
Vorgeschichte: Windows 10 PC installiert auf Windows 7, nach der Anleitungen von Otto "SSH ohne Passwort" hinbekommen und Anleitung abgespeichert.
Jetzt hab ich den Windows 10 PC platt gemacht, neu aufgesetzt (User ist diesesmal aber an ein Microsoft Konto geknüpft) sonst alles beim Alten, die Anleitung abgearbeitet.
Client ist der PI mit FHEM
Server ist Windows 10
Fehlermeldungen gabs keine aber dafür das:
fhem@raspberrypi:~$ ssh -v micro@192.168.222.26
OpenSSH_7.4p1 Raspbian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.222.26 [192.168.222.26] port 22.
debug1: Connection established.
debug1: identity file /opt/fhem/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /opt/fhem/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u7
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_7.7
debug1: match: OpenSSH_for_Windows_7.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.222.26:22 as 'micro'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256: [b]XXXXXXX ausgexxxx vor dem Posten[/b]
debug1: Host '192.168.222.26' is known and matches the ECDSA host key.
debug1: Found key in /opt/fhem/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /opt/fhem/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /opt/fhem/.ssh/id_dsa
debug1: Trying private key: /opt/fhem/.ssh/id_ecdsa
debug1: Trying private key: /opt/fhem/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
Den alten Host eintrag hab ich vorher gelöscht, der wird beim ersten Versuch dann auch abgefragt
Rechte der Ordner hab ich überprüft
Leider find ich auf dem Windows Rechner keine Logfiles um mal die diese Seite zu betrachten. Gibts noch ne Idee was ich noch prüfen könnte?
Grüße
Achim
Hallo Achim,
ich kann die Fehler derzeit nicht deuten, ich bin allerdings derzeit eingeschränkt weil unterwegs.
Ob MS Konto oder Lokal ist eigentlich egal, Windows "mapped" das MS Konto auf ein Lokales, wobei dort der Kurzname von Windows bei der Anmeldung bestimmt wird. Der Kurzname ist bei der ssh Anmeldung zu verwenden. Sehen tut man den einfach wenn man mal cmd aufmacht. ;)
Dein Fehlerlog klingt aber eher so als ob user fhem keinen public key hat? Was gibt Dir denn:
{qx(ls -lha .ssh)} in der FHEM Kommandozeile zurück?
Gruß Otto
Hi,
der Kurzname passt, gebe ich nach der geposteten Fehlermeldung das Passwort ein bin ich per SSH auf dem Windows-Rechner.
total 24K
drwx------ 2 fhem dialout 4.0K Oct 16 14:58 .
drwxr-xr-x 16 fhem dialout 4.0K Oct 16 14:43 ..
-rw------- 1 fhem dialout 1.7K Oct 16 14:56 id_rsa
-rw-r--r-- 1 fhem dialout 398 Oct 16 14:56 id_rsa.pub
-rw------- 1 fhem dialout 222 Oct 16 14:58 known_hosts
-rw-r--r-- 1 fhem dialout 222 Oct 16 13:14 known_hosts.old
Hier die Ausgabe ;-)
Grüße
Achim
Hallo Achim,
ich kann momentan nichts testen da ich unterwegs bin.
Aber ich lese jetzt folgendes:
Der Windows User stimmt und kann sich anmelden
ssh Zugang funktioniert prinzipiell mit Passwort.
Dein fhem Account hat einen Key.
Der Windows Server akzeptiert aber nicht wenn User fhem seinen Key für user micro präsentiert.
Hast Du den Key von User fhem (Linux) auf den User micro (Windows) auch erfolgreich übertragen?
Ich hatte hier (https://heinz-otto.blogspot.com/2020/09/ssh-mit-public-key.html)nochmal einen komprimierten Artikel gemacht.
Kannst Du nochmal überprüfen (als User fhem)!?
ssh-copy-id -i ~/.ssh/id_rsa micro@192.168.222.26
Gruß Otto
ich hänge mich auch mal wieder dran ;)
Brauche SSH um ein Ipad aufzuwecken :) habe auch nach deiner Anleitung alles gemacht und komme auch per Verbindung auf das andere Geät, nur muss ich jedesmal den Schlüssel neu eingeben obwohl ich auf den fhem user gewechselt habe.
Da das noch ganz neue Materie ist für mich, weiss ich nicht wo ich ansetzen muss, welche Info ihr braucht oder wie es weitergeht.
Ziel soll sein ein Bewegungsmelder bei Motion das IPAD aufzuwecken. Der Befehl geht auch per Shell, allerdings immer mit der ensprechenden Eingabe des "Passworts".
Nun prügel auf mich ein :>
Zitat von: Dia81 am 18 Oktober 2020, 19:34:27
nur muss ich jedesmal den Schlüssel neu eingeben
Was genau meinst Du damit? Das Passwort?
BTW: Ich habe keine Ahnung ob und wie das bei einem iPad wirklich geht? Wo hat der ssh Server beim iPad seinen Speicherort für die Schlüssel? Beim Userpfad? Beim Serverpfad wie bei dropbear?
Gruß Otto
Zitat von: Otto123 am 18 Oktober 2020, 19:46:55
Was genau meinst Du damit? Das Passwort?
BTW: Ich habe keine Ahnung ob und wie das bei einem iPad wirklich geht? Wo hat der ssh Server beim iPad seinen Speicherort für die Schlüssel? Beim Userpfad? Beim Serverpfad wie bei dropbear?
Gruß Otto
Ich erzeuge den Schlüssel ja durch Eingabe einer Phrase oder eines Passwortes. Dieses wird verlangt wenn ich den ssh Befehl Richtung iPad abschicke. Nach Eingabe bin ich als Root auf dem ipad. Der Befehl den ich brauche um den bildschirm zu entsperren kann ich als Fhem User in der Shell eingeben. Das funktioniert auch , das iPad entsperrt und geht an, aber ich muss halt die Phrase eingeben.
Wo da was gespeichert wird weiß ich leider nicht , habe das einfach nach deiner verlinkten Anleitung gemacht. Geht nur mit einem gejailbreakten iPad und ein paar Einstellungen. Kann gerne das Tutorial dazu morgen verlinken. Da ich damit durch homematic Bewegungsmeldern den Bildschirm anschalten lassen kann könnte ich mein altes iPad nehmen und dadurch das viel ältere schrottige und langsame Android ersetzten für Anzeige von tablet ui. Das geht aber nur wenn ich aus fhem den Befehl ohne Phrase Angabe absetzen kann ....
Hier der link doch noch :
http://www.bastelbudenbuben.de/2017/03/21/ipad-1-mit-jailbreak-als-steuerzentrale-in-fhem-einbinden/
(http://www.bastelbudenbuben.de/2017/03/21/ipad-1-mit-jailbreak-als-steuerzentrale-in-fhem-einbinden/)
ZitatIch erzeuge den Schlüssel ja durch Eingabe einer Phrase oder eines Passwortes.
Aber genau das wäre der Fehler!
Du musst einen Schlüssel ohne Passphrase erstellen, so steht es auch in meiner Anleitung!
Mit PassPhrase hast Du so keine Chance, das geht dann eventuell mit irgendeinem Tool - was ich aber für nicht zielführend halte.
Gruß Otto
Zitat von: Otto123 am 18 Oktober 2020, 22:23:07
Aber genau das wäre der Fehler!
Du musst einen Schlüssel ohne Passphrase erstellen, so steht es auch in meiner Anleitung!
Mit PassPhrase hast Du so keine Chance, das geht dann eventuell mit irgendeinem Tool - was ich aber für nicht zielführend halte.
Gruß Otto
Okay dann Versuch ich das nochmal und hoffe ich kann das dann quasi ,,überschreiben ,,
Zitat von: Otto123 am 17 Oktober 2020, 17:43:01
Kannst Du nochmal überprüfen (als User fhem)!?
ssh-copy-id -i ~/.ssh/id_rsa micro@192.168.222.26
Gruß Otto
Hallo Otto,
den Befehl mag er nicht:
fhem@raspberrypi:/home/pi$ ssh-copy-id -i ~/.ssh/id_rsa micro@192.168.222.26
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/opt/fhem/.ssh/id _rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompt ed now it is to install the new keys
micro@192.168.222.26's password:
Der Befehl "exec" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Das System kann den angegebenen Pfad nicht finden.
Die Abfolge aus deiner Anleitung:
ziel=user@host # Benutzer und Host einmal eintragen
#### Linux System
ssh-copy-id -i ~/.ssh/id_rsa $ziel
#### Windows System
scp ~/.ssh/id_rsa.pub $ziel:key.tmpgeht allerdings und ergibt:
fhem@raspberrypi:/home/pi$ ziel=micro@192.168.222.26
fhem@raspberrypi:/home/pi$ scp ~/.ssh/id_rsa.pub $ziel:key.tmp
micro@192.168.222.26's password:
id_rsa.pub 100% 398 49.0KB/s 00:00
Die Datei authorized_keys auf dem Windows Rechner ist danach aktualisiert und enthält den Key aus id_rsa.pub vom fhem user auf dem Raspberry
So, habs gelöst 8)
micro@.... ist admin, dann gelten besondere Regeln unter Windows ::)
@otto hier mal die Anleitung die zusätzlich nötig ist
https://www.concurrency.com/blog/may-2019/key-based-authentication-for-openssh-on-windows (https://www.concurrency.com/blog/may-2019/key-based-authentication-for-openssh-on-windows)
die administrators_authorized_keys ins angegebene Verzeichnis
unter Windows Powershell als Admin starten und dann:
$acl = Get-Acl C:\ProgramData\ssh\administrators_authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$administratorsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Administrators","FullControl","Allow")
$systemRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($administratorsRule)
$acl.SetAccessRule($systemRule)
$acl | Set-Acl
Grüße
Achim
Hallo Achim,
sorry für den Fehler in #15 - klar ssh-copy-id geht da nicht.
Zum Administrator Problem: Das muss ich nochmal durchdenken, aber ich meine in dem Artikel in deinem Link wird nur ein alternativer Lösungsansatz verwendet?
Schau mal hier in meinen Artikel https://heinz-otto.blogspot.com/2019/05/windows-von-fhem-aus-steuern.html weiter hinten bei Eigenheiten Windows Server 2012.
Bei Windows 10 hatte ich dieses Verhalten noch nicht. Welche Version hast Du genau installiert? Home oder pro De oder EN mit MUI?
Kannst Du mal den Inhalt der C:\ProgramData\ssh\sshd_config posten? Da steht nichts Systemspezifisches drin.
Vielleicht ist auch die sshd Version aktuell geändert?
Gruß Otto
Hi Otto,
ich hab die Pro und ich denke keine EN MUI
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedPrincipalsFile none
# For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp sftp-server.exe
# Example of overriding settings on a per-user basis
#Match User anoncvs
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Match Group administrators
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
Der letzte Eintrag wäre dann wohl zum auskommentieren :-)
Grüße
Achim
Ja :)
Ok ich sehe ich muss meinen Ablauf neu testen. Wahrscheinlich hat das nichts mit der Windows Version zu tun sondern mit der OpenSSH Version.
Ich muss da nochmal tiefer "graben" :)
Ich melde mich zurück wenn ich mehr weiß.
Gruß Otto
Hi,
es ist etwas "verrückter" als ich vermutet habe. Ich hatte kurz an mir gezweifelt ...
Ich weiß noch nicht ob man Bug oder Feature dazu sagen soll :o
Ich habe nicht alle Kombinationen getestet, aber kann folgendes sagen:
- Windows 10 Version 1803 enthält eine Datei C:\ProgramData\ssh\sshd_config ohne den Abschnitt "Match Group administrators ..." ganz am Ende.
- Windows 10 Version 2004 (und 20H2) enthält eine Datei C:\ProgramData\ssh\sshd_config mit den Abschnitt "Match Group administrators ..." ganz am Ende.
Ich dachte bisher: Der Start des Update durch "Setup" von der DVD/ dem ISO Image Windows 10, welches man mit dem MediaCreationToolxxxx erhält, liefert das gleiche Ergebnis wie das Versions Update welches einem irgendwann angeboten wird bzw. durch den "Windows 10-Update-Assistent" erzwungen werden kann. Beide Tools kann man hier (https://www.microsoft.com/de-de/software-download/windows10)herunterladen.
Dem ist nicht so! Zumindest wird durch ersteres der sshd Service wieder entfernt die Datei C:\ProgramData\ssh\sshd_config bleibt aber zunächst erhalten. Man muss den Service neu installieren.
Egal wie man dazu kommt, die Datei C:\ProgramData\ssh\sshd_config wir in der neuer Version (mindestens ab 2004) so verändert, das die Anmeldung der Gruppe Administratoren per ssh (über den Weg homedir/.ssh/ ) unterbunden wird.
Die OpenSSH Version ist in jeder Version die gleiche: OpenSSH.Server~~~~0.0.1.0
Dieser Powershell Code behebt das "Problem" der Anmeldung von Administratoren über ssh.
Edit: Achtung: in administrativer Powershell ausführen ;)
# Patch sshd config to allow administrators Group public Key logon
$Quelle="${Env:ProgramData}\ssh\sshd_config"
write-output "patch the sshd config on $Quelle"
Stop-Service -Name sshd
$Inhalt = Get-Content $Quelle
#search 2 lines contains administrators and insert commment sign
$Inhalt|foreach {if ($_ -match "administrators") {$Inhalt[$_.readcount-1]=$_.Insert(0,"#")}}
set-Content $Quelle $Inhalt
Start-Service -Name sshdIch muss nochmal über die Variante "Feature" oder "Fehlerkorrektur" nachdenken: Was bedeutet es, wenn man für die Gruppe der Administratoren eine gemeinsame administrators_authorized_keys Datei unterhalb von C:\ProgramData\ssh\ pflegt?
Gruß Otto
Moin,
nachdem FHEM vom PI auf den Debian Server zog war natürlich die "Anmeldung" am Windowsrechner futsch :-) Hab deinen Powershell Patch daher gleich mal probiert (Wichtig: als Admin ausführen ;-) und tada klappt prima
Dankeschön :-)
Grüße
Achim