ssh Remote Befehle direkt ausführen Problem

[rizo]

und ein
sudo su -s /bin/bash -c 'ssh zielhosz' fhem
ergibt was genau?

Code Auswählen Erweitern

sudo su -s /bin/bash -c fhem 192.168.0.14



da kommt dann

Code Auswählen Erweitern

No passwd entry for user '192.168.0.14'

Sag mal .. hat fhem nicht als Default-Gruppe fhem? Dann ist es nicht gut, wenn .ssh der Gruppe "dialout" gehört. Mache doch mal:

Code Auswählen Erweitern

chown -R fhem: /opf/fhem/.ssh

Gleiches, mit angepasstem Ordner, auch gerne auf dem Zielsystem.

Hintergrund:
Durch das weglassen der Gruppe hinter dem ":" wird die "Defaultgruppe" verwendet. Ist übrigens deutlich besser, als der immer wieder gerne zitierte fhem:dialout

Fürs debugging kannst Du übrigens ssh dazu bringen, gesprächiger zu sein:

Code Auswählen Erweitern

ssh -vvv .....
Und viele Infos findest Du (auf dem Zielsystem) in den Logfiles, z.B. vor dem einloggen in einem 2. Fenster:

Code Auswählen Erweitern

tail -f /var/log/syslog

chown Befehl ausgeführt...

ssh -vvv ergibt folgendes:

Code Auswählen Erweitern

OpenSSH_7.4p1 Raspbian-10+deb9u1, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.0.14" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.0.14 [192.168.0.14] 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+deb9u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u1
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.0.14:22 as 'fhem'
debug3: hostkeys_foreach: reading file "/opt/fhem/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /opt/fhem/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.0.14
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
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-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@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-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@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: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,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-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@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-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
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: 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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ***
debug3: hostkeys_foreach: reading file "/opt/fhem/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /opt/fhem/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.0.14
debug1: Host '192.168.0.14' is known and matches the ECDSA host key.
debug1: Found key in /opt/fhem/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /opt/fhem/.ssh/id_rsa (0xb94ed0)
debug2: key: /opt/fhem/.ssh/id_dsa ((nil))
debug2: key: /opt/fhem/.ssh/id_ecdsa ((nil))
debug2: key: /opt/fhem/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /opt/fhem/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /opt/fhem/.ssh/id_dsa
debug3: no such identity: /opt/fhem/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /opt/fhem/.ssh/id_ecdsa
debug3: no such identity: /opt/fhem/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /opt/fhem/.ssh/id_ed25519
debug3: no such identity: /opt/fhem/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password



[CoolTux]

Code Auswählen Erweitern

sudo su -s /bin/bash -c Ip-Adresse fhem


da kommt dann bash: Ip-Adresse: command not found

Kann auch nicht gehen wenn du es nicht mal schaffst einen Befehl korrekt ab zu schreiben 

[rizo]

Kann auch nicht gehen wenn du es nicht mal schaffst einen Befehl korrekt ab zu schreiben 

Ja sry noch nicht ganz wach habs oben geändert

[CoolTux]

Ja sry noch nicht ganz wach habs oben geändert

Sag Bescheid wenn Du wacher bist dann schau ich hier noch mal rein. Bis dahin viel Erfolg für die anderen Helfenden.

[rizo]

Oh man tut mir leid. So sollte es doch jetzt richtig sein...

Code Auswählen Erweitern

sudo su -s /bin/bash -c ssh fhem@192.168.0.14

ergibt

Code Auswählen Erweitern

No passwd entry for user 'fhem@192.168.0.14'


[Elektrolurch]

Hallo, habe das gleiche  Problem:
Trotz der korrekten Einrichtung verlangt die Verbindung über ssh ein Passwort.
Wenn man
ssh -v fhem@server
startet, so sieht man, das zwar auf dem Zielrechner in
.ssh/autorizedhosts (?)
der Ausgangsserver erkannt wird, dann wird aber ein matching mit möglichen keys im .ssh - Verzeichnis durchgeführt und der id_rsa-key wird nicht angewandt.

Code Auswählen Erweitern


identity file /home/fhem/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/fhem/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1:


und nach dem die session ausgehandlet wurde:

Code Auswählen Erweitern


debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/fhem/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password


Nach meiner Lesart scheint ssh den id_rsa.pub nicht lesen zu wollen:

Code Auswählen Erweitern


-rw-r--r-- 1 fhem dialout 1689 Jan 16 12:35 config
-rw------- 1 fhem dialout 1679 Jan 20 11:40 id_rsa
-rw-r--r-- 1 fhem dialout  401 Jan 20 11:40 id_rsa.pub
-rw-r--r-- 1 fhem dialout  444 Jan 16 10:57 known_hosts
[/cod]
Also, die Rechte stimmen meiner Meinung nach und in der passwd habe ich das home-Verzeichnis für fhem von /opb/fhem auf /home/fhem geändert. fhem - service startet trotzdem korrekt.
Auch wird die lokale config Datei für ssh ja gelesen (/home/fhem/.ssh/config)

Auf der Zielmaschine muss unter
/home/fhem/.ssh
Die Datei authorized_keys existieren. In Abhängigkeit von der ssh-Version kann die auch
authorized_keys2 heissen. Also einfach kopieren. Hat aber auch nichts geholfen.
Jetzt bin ich mit meinem Latein auch ab Ende.

Elektrolurch


[rizo]

Bin ja froh damit nicht alleine zu sein.

Vielleicht liegt es ja auch an den ssh config files? Kann es sein das sich bei raspian stretch da was geändert hat?

[Elektrolurch]

Also, habe das gerade mal für einen anderen Nutzer angelegt und da klappt es.
Es liegt also am Nutzer fhem, zumindest bei mir. Grund leider nicht bekannt. Werde mal die beiden logs bei ssh -v für die beiden Nutzer vergleichen. Vielleicht erhält das ja

Elektrolurch

[rizo]

Hab das Problem gefunden!
Es war ein Rechte Problem. Der FHEM Ordner und alles darin hatte 777 habe es nun auf 700 geändert und es funzt ohne password...

[Otto123]

Und warum muss es fhem sein? Na egal...

[rizo]

Und warum muss es fhem sein? Na egal...

muss nicht Otto. Aber jetzt weiß ich wenigstens wo der Fehler war.

Danke euch für eure Unterstützung

[Otto123]

Hab das Problem gefunden!
Es war ein Rechte Problem. Der FHEM Ordner und alles darin hatte 777 habe es nun auf 700 geändert und es funzt ohne password...

Das versteh ich auch nicht, da die Rechte auf den Dateien unterhalb .ssh durch den Prozess richtig gesetzt werden.

Ich würde nämlich gerne verstehen, ob an meiner Beschreibung was falsch oder unvollständig ist. 

Gruß Otto

[rizo]

Ich kann es leider auch nicht verstehen, also Fhem und unterordner ( außer .ssh ) hatte Reche 777. SSH hatte 700. Nachdem FHem + unterordner Rechte 700 hatte ging es

[Otto123]

Eigentlich haben HomeDirs 755, das ist bei /opt/fhem/ normalerweise auch so.

[Elektrolurch]

Die Rechte habe ich überprüft und die stimmen. Trotzdem geht fhem als Nutzer nicht...
Da gibt es wohl mehrere Probleme, die zum gleichen Fehlverhalten führen.