ssh Remote Befehle direkt ausführen Problem

Begonnen von rizo, 18 Januar 2018, 12:27:01

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1 2 3 Alle
Benutzer-Aktionen

rizo

18 Januar 2018, 12:27:01 Letzte Bearbeitung: 18 Januar 2018, 12:51:06 von rizo
Hallo,

erstelle einen neuen Thread, um keine anderen voll "zu müllen".

Ich möchte gerne von meinem FHem Raspi einen anderen raspi runterfahren.

Dazu habe ich folgendes gemacht:

Code Auswählen
sudo cp /etc/passwd /etc/passwd.sav
sudo  sed -i -e 's/fhem:.*/fhem:x:999:20::\/opt\/fhem:\/bin\/bash/' /etc/passwd
sudo passwd fhem             # Passwort vergeben und bestätigen
su fhem                      # Als fhem einloggen, es startet eine neue session!
ssh-keygen -t rsa            # Speichert automatisch in /opt/fhem/
ssh-copy-id -i ~/.ssh/id_rsa <user>@<remote-system> # gleich den angebotenen Test machen
ssh <user>@<remote-system>   # es startet eine neue session!
exit                         # aus der ssh Test session vom Remotehost!
exit                         # aus der Anmeldung von fhem! 
sudo cp /etc/passwd.sav /etc/passwd

Das ist von Ottos Technik Blog.

Das habe ich auf dem FHEM Raspi durchgeführt und auch auf dem anderen Raspi.

Verbindung ssh fhem@ip-adresse klappt auch, aber nur!! mit Password abfrage. Ich dachte durch den Key gebe es keine Passwordabfrage mehr.

#includedir /etc/sudoers.d
fhem    ALL=(ALL:ALL) NOPASSWD: ALL

ist auf deine Raspi`s eingefügt.

Kann mir bitte jemand helfen?

Wernieman

#1
18 Januar 2018, 12:53:34
Du hast wirklich "ssh-copy-id -i ~/.ssh/id_rsa <user>@<remote-system>" gemacht?

Gucke doch mal bei einem Zielsystem, was denn in folgender Datei Steht:
Code Auswählen
cat /home/<user>/.ssh/authorized_keys

Du hast wirklich folgendes getestet? Un es hat funktioniert??
Code Auswählen
ssh <user>@<remote-system>

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rizo

#2
18 Januar 2018, 12:59:12
Code Auswählen
ssh <user>@<remote-system> klappt mit Passwordeingabe.

Aber es soll doch ohne klappen...

der .ssh Ordner ist bei beiden unter /opt/fhem/.ssh
und die dateien sind alle da drin

Otto123

#3
18 Januar 2018, 13:34:59 Letzte Bearbeitung: 18 Januar 2018, 14:04:46 von Otto123
Hi,

hat Dein zweiter pi denn einen Benutzer fhem? Wenn ja hat der Rechte sich per ssh anzumelden?
Funktioniert das  mit dem User Pi?
Hast Du eine passphrase eingegeben?

Zitat# Die Frage nach der passphrase wird zweimal mit enter quittiert, also die passphrase bleibt leer
ssh-keygen -t rsa

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rizo

#4
18 Januar 2018, 15:17:18
AUf dem anderen Raspi ist auch Fhem installiert, also Benutzer ist vorhanden.
Ob der Rechte hat? Ich habe da nix eingestellt. Wie finde ich das raus und stell das ein?

Passphrase habe ich nicht eingegeben. Nur mit Enter quittiert.

User Pi nix eingestellt, gerade ausprobiert. Ist genau das gleiche. ssh pi@ip-adresse password eingabe erforderlich....

Otto123

#5
18 Januar 2018, 21:12:18
hast Du den Schritt
Code Auswählen
ssh-copy-id -i ~/.ssh/id_rsa <user>@<remote-system> # gleich den angebotenen Test machen
auch für Pi gemacht?

Ich habe keine Ideen mehr, bei mir hat diese Vorgehensweise bisher bei verschiedenen System auf Anhieb funktioniert.
Irgendwas hast Du anders gemacht, oder Dein System ist anders.

Ich habe es mit User fhem nie probiert, ich halte nix von der Verwendung von Service Konten.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rizo

#6
19 Januar 2018, 06:17:36
Werde ich nachher Mal für User Pi machen. Und dann berichten.

Wernieman

#7
19 Januar 2018, 09:09:48
Ich möchte auf meine Frage in folgender Antwort hinweisen:
Zitat« am: Gestern um 12:53:34 »

Bitte um Input für Output (= Fehlersuche)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rizo

#8
19 Januar 2018, 12:16:11
so gerade probiert nach Anleitung. Mit User Pi geht es jetzt ohne Passworteingabe...

aber nach genau der Anleitung gemacht mit User fhem geht es nicht...

@Wernieman in der Authorized steht ein ssh-rsa key...soll ich dir den ganzen Inhalt posten?

Otto123

#9
19 Januar 2018, 13:24:36
Hallo rizo,

das hier ist eigentlich verantwortungslos, ich würde das nie machen:
Zitat#includedir /etc/sudoers.d
fhem    ALL=(ALL:ALL) NOPASSWD: ALL
Auch kann ich Dir nur abraten, den User fhem dauerhaft für interactive Anmeldung zu verwenden.

Also sei so gut, mach es mit einem neuen User und schau Step by Step was Du für Rechte wirklich brauchst.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

CoolTux

#10
19 Januar 2018, 13:38:05
ls -all /opt/fhem/
ls -all /opt/fhem/.ssh/


zeig mal was Du da hast
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Wernieman

#11
19 Januar 2018, 14:23:42
@rizo

Natürlich nicht! ... Du könntest aber mal vergleichen, ob da die gleichen Daten "drinstehen":
Code Auswählen
#ZielSystem:
cat /home/<user>/.ssh/authorized_keys
#FHem-Server
cat /opt/fhem/.ssh/id_rsa.pub


Wobei Du laut Deiner Beschreibung in der /home/<user>/.ssh/authorized_keys 2 Zeilen haben müstest .... und eine stimmt mit der id_rsa.pub überein.

P.S. Ich gehe jetzt einfach mal davon aus, das Du reinen RSA-Key definiert hast
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rizo

#12
19 Januar 2018, 15:21:33
Zitat von: CoolTux am 19 Januar 2018, 13:38:05
ls -all /opt/fhem/
ls -all /opt/fhem/.ssh/


zeig mal was Du da hast
Fhem Raspi
ls -all /opt/fhem/
Code Auswählen
drwxrwxrwx 16 fhem dialout   4096 Jan 18 11:49 .
drwxr-xr-x  4 root root      4096 Nov  5 09:59 ..
drwxr-xr-x  2 fhem dialout   4096 Jan 17 12:43 backup
-rw-------  1 fhem dialout   3150 Jan 19 12:41 .bash_history
drwxr-xr-x  2 fhem dialout   4096 Jan 10 14:18 cache
-rw-rw-rw-  1 fhem dialout 229214 Jan 18 15:23 CHANGED
drwx------  3 fhem dialout   4096 Nov 19 10:58 .config
-rw-rw-rw-  1 fhem dialout  39329 Jan 10 14:09 configDB.pm
drwxrwxrwx 40 fhem dialout   4096 Nov  5 10:00 contrib
drwxrwxrwx  3 fhem dialout   4096 Nov  5 10:00 demolog
drwxrwxrwx  4 fhem dialout   4096 Nov  5 10:04 docs
drwxrwxrwx  6 fhem dialout  28672 Jan 17 12:43 FHEM
-rw-rw-rw-  1 fhem dialout  87560 Jan 19 12:46 fhem.cfg
-rw-rw-rw-  1 fhem dialout  15740 Nov  5 10:04 fhem.cfg.demo
-rwxrwxrwx  1 fhem dialout 142171 Jan 17 12:43 fhem.pl
drwxrwxrwx  2 fhem dialout  20480 Jan 19 00:00 log
-rw-rw-rw-  1 fhem dialout  36281 Jan 17 12:43 MAINTAINER.txt
drwxr-xr-x  2 fhem dialout   4096 Jan 17 15:03 .nano
-rw-rw-rw-  1 fhem dialout    935 Feb 19  2017 README_DEMO.txt
drwxrwxrwx  5 fhem dialout   4096 Jan 19 12:45 restoreDir
drwxrwxrwx  2 pi   pi        4096 Nov  5 11:52 script
drwx------  2 fhem dialout   4096 Jan 19 12:42 .ssh
drwxrwxrwx  2 fhem dialout   4096 Nov  5 10:04 unused
-rw-rw----  1 fhem root       275 Nov 19 10:40 WebStreams.txt
drwxrwxrwx  9 fhem dialout   4096 Nov  5 10:03 www


ls -all /opt/fhem/.ssh/
Code Auswählen
drwx------  2 fhem dialout 4096 Jan 19 12:42 .
drwxrwxrwx 16 fhem dialout 4096 Jan 18 11:49 ..
-rw-------  1 fhem dialout  398 Jan 19 12:42 authorized_keys
-rw-------  1 fhem dialout 1679 Jan 18 11:51 id_rsa
-rw-r--r--  1 fhem dialout  398 Jan 18 11:51 id_rsa.pub
-rw-r--r--  1 fhem dialout  222 Jan 18 11:52 known_hosts



anderer Raspi

ls -all /opt/fhem/

Code Auswählen
drwxrwxrwx 13 fhem dialout   4096 Jan 18 11:52 .
drwxr-xr-x  9 root root      4096 Jan 12 16:15 ..
-rw-------  1 fhem dialout   1405 Jan 19 12:42 .bash_history
drwxr-xr-x  2 fhem dialout   4096 Jan 11 13:49 cache
-rw-rw-rw-  1 fhem dialout 229214 Jan 18 15:22 CHANGED
-rw-rw-rw-  1 fhem dialout  39329 Jan 10 14:59 configDB.pm
drwxrwxrwx 40 fhem dialout   4096 Oct 18 17:30 contrib
drwxrwxrwx  3 fhem dialout   4096 Oct 18 17:30 demolog
drwxrwxrwx  4 fhem dialout   4096 Oct 18 17:36 docs
drwxrwxrwx  6 fhem dialout  20480 Jan 18 15:23 FHEM
-rw-rw-rw-  1 fhem dialout   1626 Jan 16 12:31 fhem.cfg
-rw-rw-rw-  1 fhem dialout  15740 Oct 18 17:35 fhem.cfg.demo
-rwxrwxrwx  1 fhem dialout 142171 Jan 18 15:23 fhem.pl
drwxrwxrwx  2 fhem dialout   4096 Jan 12 16:28 log
-rw-rw-rw-  1 fhem dialout  36281 Jan 18 15:22 MAINTAINER.txt
-rw-rw-rw-  1 fhem dialout    935 Feb 19  2017 README_DEMO.txt
drwxrwxrwx  5 fhem dialout   4096 Jan 18 15:22 restoreDir
drwxr-xr-x  2 pi   pi        4096 Oct 19 12:54 script
drwx------  2 fhem dialout   4096 Jan 19 12:42 .ssh
drwxrwxrwx  2 fhem dialout   4096 Oct 18 17:35 unused
drwxrwxrwx  9 fhem dialout   4096 Oct 18 17:41 www


ls -all /opt/fhem/.ssh/

Code Auswählen
drwx------  2 fhem dialout 4096 Jan 19 12:42 .
drwxrwxrwx 13 fhem dialout 4096 Jan 18 11:52 ..
-rw-------  1 fhem dialout 1590 Jan 19 12:21 authorized_keys
-rw-------  1 fhem dialout 1679 Jan 19 12:20 id_rsa
-rw-r--r--  1 fhem dialout  398 Jan 19 12:20 id_rsa.pub
-rw-r--r--  1 fhem dialout  444 Jan 19 12:21 known_hosts



Zitat von: Wernieman am 19 Januar 2018, 14:23:42
@rizo

Natürlich nicht! ... Du könntest aber mal vergleichen, ob da die gleichen Daten "drinstehen":
Code Auswählen
#ZielSystem:
cat /home/<user>/.ssh/authorized_keys
#FHem-Server
cat /opt/fhem/.ssh/id_rsa.pub


Wobei Du laut Deiner Beschreibung in der /home/<user>/.ssh/authorized_keys 2 Zeilen haben müstest .... und eine stimmt mit der id_rsa.pub überein.

P.S. Ich gehe jetzt einfach mal davon aus, das Du reinen RSA-Key definiert hast

Ich werde morgen nochmal von vorne anfangen und die .ssh Ordner auf dem Ziel und FHem System löschen

@Otto Lege dann morgen auch einen neuen User an

CoolTux

#13
19 Januar 2018, 15:44:31
und ein
sudo su -s /bin/bash -c 'ssh zielhosz' fhem
ergibt was genau?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Wernieman

#14
19 Januar 2018, 16:07:24 Letzte Bearbeitung: 19 Januar 2018, 16:09:36 von Wernieman
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
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
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
tail -f /var/log/syslog
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rizo

#15
20 Januar 2018, 10:54:05 Letzte Bearbeitung: 20 Januar 2018, 11:01:49 von rizo
Zitat von: CoolTux am 19 Januar 2018, 15:44:31
und ein
sudo su -s /bin/bash -c 'ssh zielhosz' fhem
ergibt was genau?

Code Auswählen
sudo su -s /bin/bash -c fhem 192.168.0.14



da kommt dann
Code Auswählen
No passwd entry for user '192.168.0.14'


Zitat von: Wernieman am 19 Januar 2018, 16:07:24
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
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
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
tail -f /var/log/syslog

chown Befehl ausgeführt...

ssh -vvv ergibt folgendes:

Code Auswählen
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

#16
20 Januar 2018, 10:58:17
Zitat von: rizo am 20 Januar 2018, 10:54:05
Code Auswählen
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  :'(
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rizo

#17
20 Januar 2018, 11:02:43
Zitat von: CoolTux am 20 Januar 2018, 10:58:17
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

#18
20 Januar 2018, 11:09:56
Zitat von: rizo am 20 Januar 2018, 11:02:43
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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rizo

#19
20 Januar 2018, 11:21:53
Oh man tut mir leid. So sollte es doch jetzt richtig sein...

Code Auswählen
sudo su -s /bin/bash -c ssh fhem@192.168.0.14

ergibt
Code Auswählen
No passwd entry for user 'fhem@192.168.0.14'



Elektrolurch

#20
20 Januar 2018, 11:59:32
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

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

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

-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
configDB und Windows befreite Zone!

rizo

#21
20 Januar 2018, 12:16:59
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

#22
20 Januar 2018, 12:51:07
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
configDB und Windows befreite Zone!

rizo

#23
20 Januar 2018, 13:00:56
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

#24
20 Januar 2018, 13:04:38
Und warum muss es fhem sein? Na egal...
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rizo

#25
20 Januar 2018, 13:06:44
Zitat von: Otto123 am 20 Januar 2018, 13:04:38
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

#26
20 Januar 2018, 13:11:57
Zitat von: rizo am 20 Januar 2018, 13:00:56
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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rizo

#27
20 Januar 2018, 13:34:06
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

#28
20 Januar 2018, 14:01:43
Eigentlich haben HomeDirs 755, das ist bei /opt/fhem/ normalerweise auch so.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Elektrolurch

#29
20 Januar 2018, 14:29:53
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.
configDB und Windows befreite Zone!

Wernieman

#30
20 Januar 2018, 17:29:02
Könnte es sein, das Ihr mal über den komplette ordner /opf/fhem die rechte auf 777 gesetzt habt?
1. IST DAS BÖSE!!
2. Alle Anleitung (Nicht Deine Otto) die so etwas schreiben: vergessen, sind BÖSE!!
3. SSH läzuft nur, wenn die rechte korrekt gesetzt wurden, bei zuviel rechten (wie eben 777), passiert eben so etwas.

Ergebnis: Mit Richtigen rechten (User/Gruppe,Zugrifss-Rechten) arbeiten

P.S. In dem "ls" von /opt/fhem/.ssh auf der ersten Seiten sind die rechte (700) aber so gesetzt ... wurde also später mal "falsch gemacht"
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rizo

#31
20 Januar 2018, 19:01:03
Zitat von: Wernieman am 20 Januar 2018, 17:29:02
Könnte es sein, das Ihr mal über den komplette ordner /opf/fhem die rechte auf 777 gesetzt habt?
1. IST DAS BÖSE!!
2. Alle Anleitung (Nicht Deine Otto) die so etwas schreiben: vergessen, sind BÖSE!!
3. SSH läzuft nur, wenn die rechte korrekt gesetzt wurden, bei zuviel rechten (wie eben 777), passiert eben so etwas.

Ergebnis: Mit Richtigen rechten (User/Gruppe,Zugrifss-Rechten) arbeiten

P.S. In dem "ls" von /opt/fhem/.ssh auf der ersten Seiten sind die rechte (700) aber so gesetzt ... wurde also später mal "falsch gemacht"

Ja ich gebe Dir recht. Otto deine Anleitung war / ist super, daran lag es nun wirklich nicht. Der Fehler war durch vieles rumprobieren anscheinend entstanden.

Elektrolurch

#32
20 Januar 2018, 19:44:41
gelöst:
Habe mir mal mit
ssh -vvv fhem@server2
Das log genauer angeschaut. Ergebnis: Nach dem Senden des .pub Schlüssels liefert server2 nichts zurück.
Grund:
Auf server2 war das .ssh - Verzeichnis nicht auf 700 gesetzt.
Also die Rechte müssen ab dem home-Verzeichnis auf beiden Seiten tatsächlich strikt auf den user fhem eingeschränkt werden.
Na ja. Schön, das es bei ssh gestaffelte verbose gibt.

Elektrolurch
configDB und Windows befreite Zone!

Otto123

#33
20 Januar 2018, 21:00:46
Nicht das es jetzt falsch in die andere Richtung geht:
Code Auswählen
/home/pi/.ssh:

drwx------ 2 pi pi 4096 Nov 24 17:50 .
drwxr-xr-x 3 pi pi 4096 Oct 25 14:32 ..
-rw------- 1 pi pi 1679 Jan 16  2017 id_rsa
-rw-r--r-- 1 pi pi  392 Jan 16  2017 id_rsa.pub
-rw------- 1 pi pi 1552 Nov 24 17:49 known_hosts


Der Public Key sollte lesbar sein.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz
Drucken
Nach oben Seiten1 2 3 Alle
Benutzer-Aktionen