FHEM Forum

FHEM => Anfängerfragen => Thema gestartet von: jeti am 04 Januar 2019, 11:47:01

Titel: SSH ohne passwort
Beitrag 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ß
Titel: Antw:SSH ohne passwort
Beitrag von: CoolTux am 04 Januar 2019, 11:51:59
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.
Titel: Antw:SSH ohne passwort
Beitrag von: Byte09 am 04 Januar 2019, 11:53:20
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
Titel: Antw:SSH ohne passwort
Beitrag von: jeti am 04 Januar 2019, 14:51:43
Hallo zusammen,

ah ok, war als root angemeldet, ich probiere und gebe Bescheid,
Danke schonmal!!!

Gruß
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 04 Januar 2019, 15:03:06
Hi,

einfach das tun was ich beschrieben habe, das funktioniert :)
Manchmal ist jedes Wort im Text wichtig und Ruhe ist gefragt :)  ;D

Gruß Otto
Titel: Antw:SSH ohne passwort
Beitrag von: jeti am 04 Januar 2019, 17:37:08
 :'( 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
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 04 Januar 2019, 17:45:37
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
Titel: Antw:SSH ohne passwort
Beitrag von: Christoph Morrison am 04 Januar 2019, 20:38:51
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.
Titel: Antw:SSH ohne passwort
Beitrag von: jeti am 05 Januar 2019, 13:13:05
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.107
wird 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ß
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 05 Januar 2019, 14:50:40
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
Titel: Antw:SSH ohne passwort
Beitrag von: jeti am 05 Januar 2019, 15:39:45
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ß
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 05 Januar 2019, 15:59:54
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
Titel: Antw:SSH ohne passwort
Beitrag von: CBSnake am 16 Oktober 2020, 15:22:15
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
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 16 Oktober 2020, 22:32:34
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
Titel: Antw:SSH ohne passwort
Beitrag von: CBSnake am 17 Oktober 2020, 12:19:23
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
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 17 Oktober 2020, 17:43:01
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
Titel: Antw:SSH ohne passwort
Beitrag von: Dia81 am 18 Oktober 2020, 19:34:27
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 :>
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 18 Oktober 2020, 19:46:55
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
Titel: Antw:SSH ohne passwort
Beitrag von: Dia81 am 18 Oktober 2020, 20:26:08
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 ....
Titel: Antw:SSH ohne passwort
Beitrag von: Dia81 am 18 Oktober 2020, 20:30:14
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/)
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 18 Oktober 2020, 22:23:07
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
Titel: Antw:SSH ohne passwort
Beitrag von: Dia81 am 19 Oktober 2020, 13:13:00
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 ,,
Titel: Antw:SSH ohne passwort
Beitrag von: CBSnake am 21 Oktober 2020, 05:49:49
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.tmp


geht 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
Titel: Antw:SSH ohne passwort
Beitrag von: CBSnake am 21 Oktober 2020, 09:08:44
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
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 21 Oktober 2020, 09:37:25
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
Titel: Antw:SSH ohne passwort
Beitrag von: CBSnake am 22 Oktober 2020, 18:48:19
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
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 22 Oktober 2020, 20:16:05
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
Titel: Antw:SSH ohne passwort
Beitrag von: Otto123 am 26 Oktober 2020, 13:38:39
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:

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 sshd


Ich 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
Titel: Antw:SSH ohne passwort
Beitrag von: CBSnake am 07 Dezember 2020, 09:52:06
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