Spiegelung von NAS zu NAS
Moin alle zusammen,
ich stehe vor einem kleinem Problem. Wir nutzen NAS1 als Datenserver, auf dem regelmäßig gearbeitet wird. Nun soll NAS2 als Datensicherungsserver fungieren (Beides sind Synology-Geräte). Dazu wollte ich eine Aufgabe via Aufgabenplaner in der Systemsteuerung erstellen, mittels der die entsprechenden Ordner rüber kopiert werden sollen. Dazu musste ich vorerst dafür sorgen, dass über der ssh-verbindung keine Passwortabfrage gestellt wird, da dies automatisch geschehen soll. Hab dafür verwendet. Danach habe ich diesen mittels den code auf dem NAS2 kopiert und eingetragen.
Jetzt sollte eigentlich die Passwortabfrage wegfallen, stattdessen eine passphrase (sofern angegeben) verlangt werden. Jedoch bleibt das aus. Ich habe mal mittels ausgelesen, was genau er dort tut. Hier das Ergebnis:
Wenn ich das richtig verstehe, dann findet er zwar den Key, aber akzeptiert diesen nicht... Kann mir jemand weiterhelfen?
Vielen Dank schon einmal im vorraus
ich stehe vor einem kleinem Problem. Wir nutzen NAS1 als Datenserver, auf dem regelmäßig gearbeitet wird. Nun soll NAS2 als Datensicherungsserver fungieren (Beides sind Synology-Geräte). Dazu wollte ich eine Aufgabe via Aufgabenplaner in der Systemsteuerung erstellen, mittels der die entsprechenden Ordner rüber kopiert werden sollen. Dazu musste ich vorerst dafür sorgen, dass über der ssh-verbindung keine Passwortabfrage gestellt wird, da dies automatisch geschehen soll. Hab dafür
ssh-keygen -t rsa
cat ~/user/.ssh/id_rsa.pub | ssh user@Host 'cat»~/.ssh/authorized_keys'
Jetzt sollte eigentlich die Passwortabfrage wegfallen, stattdessen eine passphrase (sofern angegeben) verlangt werden. Jedoch bleibt das aus. Ich habe mal mittels
ssh user@host -vv
OpenSSH_6.8p1-hpn14v6, OpenSSL 1.0.2n-fips 7 Dec 2017
debug2: ssh_connect: needpriv 0
debug1: Connecting to nas02-host [192.168.XX.XX] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/rsync/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/rsync/.ssh/id_rsa-cert type -1
debug1: identity file /var/services/homes/rsync/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/rsync/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/rsync/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/rsync/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/rsync/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/rsync/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.8p1-hpn14v6
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 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-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 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,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 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,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: 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: kex_parse_kexinit: 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: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:isi3bTq1d8GyW7HzWoT1KBNo/V+F7eXhWUJYbUdqYj4
debug1: Host 'nas02HOST' is known and matches the ECDSA host key.
debug1: Found key in /var/services/homes/rsync/.ssh/known_hosts:1
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /var/services/homes/rsync/.ssh/id_rsa ((nil)),
debug2: key: /var/services/homes/rsync/.ssh/id_dsa (0x7fbe4c9395b0),
debug2: key: /var/services/homes/rsync/.ssh/id_ecdsa ((nil)),
debug2: key: /var/services/homes/rsync/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /var/services/homes/rsync/.ssh/id_rsa
debug1: Offering DSA public key: /var/services/homes/rsync/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /var/services/homes/rsync/.ssh/id_ecdsa
debug1: Trying private key: /var/services/homes/rsync/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
Wenn ich das richtig verstehe, dann findet er zwar den Key, aber akzeptiert diesen nicht... Kann mir jemand weiterhelfen?
Vielen Dank schon einmal im vorraus
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 361577
Url: https://administrator.de/contentid/361577
Ausgedruckt am: 17.11.2024 um 11:11 Uhr
13 Kommentare
Neuester Kommentar
Hallo littleAdm,
kennst Du das hier:
http://www.synology-wiki.de/index.php/Ssh_mit_Zertifikaten_absichern
http://www.synology-forum.de/forum.html
Muss es denn überhaupt über eine ssh-Verbindung gehen?
Du könntest doch auch am Nas1 einen Backupuser einrichten, der Leserechte an der Quelle hat und denselben user auf Nas2 einrichten der Schreibrechte am Ziel hat.
Dann nimmst Du eines der Backuptools wie z.B. "Active Backup" und lässt Ordner zu Ordner spiegeln.
Wenn es über eine "sichere" Leitung gehen soll, dann könntest Du die beiden Nas über eine der vielen Netzwerkschnittstellen direkt verbinden. Die Daten werden dann zwar unverschlüssel übertragen, aber über eine dedizierte Leitung, in einem eigenen Netzwerk (z.B. 192.168.10.0./24) , die keiner abhören kann.
Gruß Frank
kennst Du das hier:
http://www.synology-wiki.de/index.php/Ssh_mit_Zertifikaten_absichern
http://www.synology-forum.de/forum.html
Muss es denn überhaupt über eine ssh-Verbindung gehen?
Du könntest doch auch am Nas1 einen Backupuser einrichten, der Leserechte an der Quelle hat und denselben user auf Nas2 einrichten der Schreibrechte am Ziel hat.
Dann nimmst Du eines der Backuptools wie z.B. "Active Backup" und lässt Ordner zu Ordner spiegeln.
Wenn es über eine "sichere" Leitung gehen soll, dann könntest Du die beiden Nas über eine der vielen Netzwerkschnittstellen direkt verbinden. Die Daten werden dann zwar unverschlüssel übertragen, aber über eine dedizierte Leitung, in einem eigenen Netzwerk (z.B. 192.168.10.0./24) , die keiner abhören kann.
Lan ----- NAS1
| |
| |
+------- NAS2
Gruß Frank
Hallo,
Gruß,
Peter
Zitat von @littleAdm:
Zu dem wird im Zielverzeichnis eine Sicherung erstellt, mit der nicht sofort weiter gearbeitet werden kann, sollte die Haupt-NAS ausfallen ...
Das ist bei einem Backup oder Datensicherung so üblich das eigene Datenformate genutzt werden. Beim Kopieren von einzeilne Elemente/Dateien bleiben die Namen meistens erhalten, stellt aber nicht wirklich eine Datensicherung da. Ich würd sagen works as designed. Was du brauchst ist z.B. ein Cluster und das nicht nur von den Rechnenden Einheiten, sondern auch von deinen Daten Zu dem wird im Zielverzeichnis eine Sicherung erstellt, mit der nicht sofort weiter gearbeitet werden kann, sollte die Haupt-NAS ausfallen ...
Gruß,
Peter
Hallo,
Warum beschwerst du dich dann das wenn du ein Backup (Sicherungswerkzeug) nutzt du an die Daten erstmal nicht direkt dran kommst (Eigenes datenformat). Du hast dann dein Begriff Spiegelung in (Daten)Sicherung verwandelt, oder?
Gruß,
Peter
Warum beschwerst du dich dann das wenn du ein Backup (Sicherungswerkzeug) nutzt du an die Daten erstmal nicht direkt dran kommst (Eigenes datenformat). Du hast dann dein Begriff Spiegelung in (Daten)Sicherung verwandelt, oder?
Gruß,
Peter
Hallo,
Mal http://karlcode.owtelse.com/blog/2015/06/27/passwordless-ssh-on-synolog ... gelesen? Da soll es mit DSM 6.0 gelaufen haben.
Gruß,
Peter
Mal http://karlcode.owtelse.com/blog/2015/06/27/passwordless-ssh-on-synolog ... gelesen? Da soll es mit DSM 6.0 gelaufen haben.
Gruß,
Peter