Toggle sidebar

SSH Authentifizierung über key funktioniert nicht

E

eMBae

Benutzer
Mitglied seit
06. Jul 2016
Beiträge
77
Punkte für Reaktionen
22
Punkte
8
Hallo in die Runde

Folgende Situation:
Ich möchte für BasicBackup eine SSH-Verbindung über RSA-Schlüssel erstellen.

Lokaler Server DS220+ - DSM7 (neuste Version)
Remote Server DS718+ - DSM6 (neuste Version)

Ich habe alles nach Anleitung von Tommes (Hilfe in BasicBackup) durchgeführt, aber er möchte noch immer das Passwort haben.
1640781079135.png Lokaler Server

1640781131763.png Remote Server

Und hier die Debug-Informationen:

Code: 
OpenSSH_8.2p1, OpenSSL 1.1.1l  24 Aug 2021
debug2: resolve_canonicalize: hostname 192.168.xxx.xx is address
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: ssh_connect_direct
debug1: Connecting to 192.168.xxx.xx [192.168.xxx.xx] port xxxxx.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.xxx.xx:xxxxx as 'BBBackup'
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-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,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,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,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
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,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
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:KFY+KoAVZ25/gakiUR0P4W70NYffrt/QYE6OHuAP/50
debug1: Host '[192.168.xxx.xx]:xxxxx' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:oT+G3lHOW/dPZ6+37baFLy9VM5o+8iDuX002eiMg+60
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_ed25519_sk
debug1: Will attempt key: /root/.ssh/id_xmss
debug2: pubkey_prepare: done
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>
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: /root/.ssh/id_rsa RSA SHA256:oT+G3lHOW/dPZ6+37baFLy9VM5o+8iDuX002eiMg+60
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug1: Trying private key: /root/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Ich stehe gerade echt auf dem Schlauch.
Danke für eure Hilfe
 
Kurt-oe1kyw

Kurt-oe1kyw

Benutzer
Sehr erfahren
Mitglied seit
10. Mai 2015
Beiträge
9.139
Punkte für Reaktionen
1.778
Punkte
314
Kann es das 4096 Problem auf der DS220+ sein?

Ich meine damit dass die Erstellung für die DS220+ mit DSM7 nicht korrekt vorgenommen wurde.
Ich habe das damals mit Bildern im Detail genau erklärt und wie du auf 4096 Verschlüsselung umschaltest damit die erzeugten Schlüssel auch vom neuem DSM 7 wieder akzeptiert werden.
Bitte nachlesen
https://www.synology-forum.de/threa...fuer-winscp-gesucht.74476/page-10#post-950965
 
Tommes

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.148
Punkte für Reaktionen
1.113
Punkte
314
Hi!

Kurt-oe1kyw schrieb:
Kann es das 4096 Problem auf der DS220+ sein?
Zum Vergrößern anklicken....

Ich habe in der Hilfe einen 4096 Bit Key zum erstellen angegeben…

Bash: 
ssh-keygen -b 4096 -t rsa -f ~/.ssh/[FILENAME]

…daran sollte es also nicht liegen.

Ich bin grad aber auch überfragt und könnte mir nur vorstellen, das im Teil 3 der Basic Backup Anleitung irgendwas schief gelaufen ist. Ich lese mir die Anleitung aber selber nochmal durch und stelle das nach. Vielleicht habe ich je auch irgendwas vergessen bzw. übersehen.
 
E

eMBae

Benutzer
Mitglied seit
06. Jul 2016
Beiträge
77
Punkte für Reaktionen
22
Punkte
8
Ich werde morgen auch nochmal testen.
 
Tommes

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.148
Punkte für Reaktionen
1.113
Punkte
314
Hm... soweit scheint die Basic Backup Anleitung stimmig zu sein, oder ich bin einfach schon so Betriebsblind, das ich einen Möglichen Fehler übersehe.

Was habe ich gemacht?
Auf der lokalen Diskstation habe ich die SSH-Ordnerstruktur so gelassen wie sie ist. Ich habe nur den schon vorhandenen Eintrag des Remote Servers aus der known_hosts gelöscht, damit der Handshake nochmal ausgelöst wird. Auf dem Remote Server selber habe ich hingegen die SSH-Ordnerstruktur komplett gelöscht und im Anschluss nach Teil 2 und Teil 3 der Basic Backup Anleitung die Remote Server Verbindung eingerichtet. Hat alles ohne Probleme funktioniert. Von daher bin ich gespannt, ob deine morgigen Tests vielleicht neue Erkenntnisse bringen.

Kurz nachgedacht: In deinem Eingangspost sollte im ersten Screenshot noch eine known_hosts zu sehen sein, so wie hier...

1640801455874.png

... hier könnte der mögliche Fehler liegen, das der Handshake nicht funktioniert hat.

Tommes
 
E

eMBae

Benutzer
Mitglied seit
06. Jul 2016
Beiträge
77
Punkte für Reaktionen
22
Punkte
8
Moin,

die known_hosts Datei war natürlich auch vorhanden, leider nicht mit auf dem Screenshot.

Habe heute Morgen alles nochmal gelöscht und neu durchgeführt.
Remote Diskstation durchgestartet und die Passwortabfrage kommt dennoch.
 
Tommes

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.148
Punkte für Reaktionen
1.113
Punkte
314
Hm, das ist echt seltsam und bin für den Moment auch überfragt. Wenn ich aber deine Debug-Informationen anschaue, dann sieht erst mal soweit alles gut aus, bis auf die letzten zwei Zeilen...

debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Zum Vergrößern anklicken....

Ich hab debug2: we did not send a packet, disable method mal in eine Suchmaschine eingegeben und habe u.a. sowas hier gefunden...

https://stackoverflow.com/questions/47875126/we-did-not-send-a-packet-disable-method

Folge ich dann dem Link in der ersten Antwort, könnte man vermuten, das das Problem mit der authorized_keys des Remote Servers zusammenhängt, aber lies mal selber...

https://unix.stackexchange.com/questions/131886/ssh-public-key-wont-send-to-server

Schau mal, ob dich das weiter bringt, ansonsten meld dich gerne nochmal. Es ist für mich nur schwierig einem Problem auf dem Grund zu gehen, was ich selber nicht nachstellen kann.

Tommes
 
E

eMBae

Benutzer
Mitglied seit
06. Jul 2016
Beiträge
77
Punkte für Reaktionen
22
Punkte
8
So, heute habe ich mich nochmal versucht.

Das Problem ist gelöst, der Zugriff funktioniert nun.

Ich musste die Berechtigung des home-Verzeichnisses des Benutzers, auf der Remote Disk (mit dem ich auf die DS zugreifen möchte) anpassen.
chmod 755 /volume1/homes/Benutzer der per ssh angesprochen wird


Nun wird BasicBackup getestet ;-)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: fattony2k
F

fattony2k

Benutzer
Mitglied seit
11. Jan 2014
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Danke dass du auch die Lösung hier gepostet hast, bin schon fast verzweifelt <3
Und sorry dass ich den Thread nochmal nach oben hole.
 
NAS-Central - Ihr Partner für NAS Lösungen
NAS-Central - The Home of NAS
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat 

Hosted by netcup
IT Lösungen mit NAS Servern
IT Firma Trier
Fotograf Trier
 
 
Oben Unten
Zurück