rsync, nfs - Problem

[haweK]

Hallo zusammen,
seit geraumer Zeit versuche ich ein remote rsync von einem Debian client auf das Synology NAS 213 (aktuelles verfügbare DSM) zu machen. Wirklich zufrieden bin ich nicht. Das Wiki dazu scheint mir etwas alt und die Hilfe hilft mir nicht viel weiter. Gefunden habe ich verschiedenste Anleitungen. Am weitesten bin ich mit der Anleitung rsync per nfs gekommen, ich verliere dabei aber immer die User- und Gruppenrechte.
Weiter habe ich diese artikel gefunden "https://www.bitblokes.de/synology-r...sh-ohne-passwort-eingabe-auf-das-nas-sichern/!"
Obwohl ich die RSA Key angelegt habe, werde ich immer zur Passworteingabe aufgefordert. Anschließen gibt es eine Fehlermeldung.
Wer hat einen Tipp oder einen Link zu einer einfachen Anleitung?
---
sending incremental file list
ERROR: module is read only
rsync error: syntax or usage error (code 1) at main.c(1131) [Receiver=3.0.9]
rsync: connection unexpectedly closed (112 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.3]
---
> cat rsyncd.conf
#motd file = /etc/rsyncd.motd
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = yes

[NetBackup]
path = /var/services/NetBackup
comment = Network Backup Share
uid = root
gid = root
read only = no
list = yes
charset = utf-8
auth users = root,rsync
secrets file = /etc/rsyncd.secrets

 

[framp]

Zuerst musst Du es hinbekommen dass Du Dich ohne PWD per ssh anmelden kannst.

Zeige doch mal die Ausgabe von

ssh <synoip> -i <ssh key verzeichnis> -vvv

sowie dia Ausgabe von

ls -la <ssh key verzeichnis>

 

[haweK]

Danke für die Hilfestellung,

Zeige doch mal die Ausgabe von

ssh <synoip> -i <ssh key verzeichnis> -vvv

Vom Client ...

OpenSSH_7.9p1 Raspbian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.2.5 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.2.5 [192.168.2.5] port 22.
debug1: Connection established.
debug1: identity file /home/rsync/.ssh/hoshi2-rsync-key type 0
debug1: identity file /home/rsync/.ssh/hoshi2-rsync-key-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2
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.2.5:22 as 'rsync'
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.2.5
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-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,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-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
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,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: ciphers stoc: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: MACs ctos: hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com
debug2: MACs stoc: hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com
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: ecdsa-sha2-nistp256 SHA256:tQrFWen5adVl9Mob4Xbfco8LecBes3S0Taj/T2vbTM0
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.2.5
debug1: Host '192.168.2.5' is known and matches the ECDSA host key.
debug1: Found key in /root/.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
debug1: Will attempt key: /home/rsync/.ssh/hoshi2-rsync-key RSA SHA256:isj1BOdk1/e4kqYIPSN+eYvZD3NT2pSVvZBCY+lNdK4 explicit
debug2: pubkey_prepare: done
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 public key: /home/rsync/.ssh/hoshi2-rsync-key RSA SHA256:isj1BOdk1/e4kqYIPSN+eYvZD3NT2pSVvZBCY+lNdK4 explicit
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
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
rsync@192.168.2.5's password:

sowie dia Ausgabe von

ls -la <ssh key verzeichnis>

/home/rsync/.ssh:
insgesamt 20
drwxr-xr-x 2 rsync rsync 4096 Sep  3 09:22 .
drwxr-xr-x 7 rsync users 4096 Sep  3 09:15 ..
-rw------- 1 rsync users 1823 Sep  3 09:06 hoshi2-rsync-key
-rw-r--r-- 1 rsync users  394 Sep  3 09:06 hoshi2-rsync-key.pub
-rw-r--r-- 1 rsync users  222 Sep  3 09:13 known_hosts

 

[framp]

Zeige doch mal auf der Syno die Ausgabe von

grep -E "^[^#].*" /etc/ssh/sshd_config

Ausserdem kopiere mal Deinen Key auf dem Client auf die Syno mit

ssh-copy-id <user>@<synoip>

 

[haweK]

Zeige doch mal auf der Syno die Ausgabe von

grep -E "^[^#].*" /etc/ssh/sshd_config

Ciphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
MACs hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com
PubkeyAuthentication yes
AuthorizedKeysFile    .ssh/authorized_keys
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
AllowTcpForwarding no
UsePrivilegeSeparation sandbox        # Default for new installations.
UseDNS no
ChrootDirectory none
Subsystem       sftp    internal-sftp -f DAEMON -u 000
Match User root
    AllowTcpForwarding yes
Match User admin
    AllowTcpForwarding yes
Match User anonymous
    AllowTcpForwarding no
    GatewayPorts no

Ausserdem kopiere mal Deinen Key auf dem Client auf die Syno mit

ssh-copy-id <user>@<synoip>

OK, jetzt klappt der ssh login ohne Password aber die Felehmerldun bei rsync ist

sending incremental file list
ERROR: module is read only
rsync error: syntax or usage error (code 1) at main.c(1131) [Receiver=3.0.9]
rsync: connection unexpectedly closed (112 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.3]

Mein Fehler hier war wohl kein .ssh Directory für das "autorized_keys" File

 

[wolfn]

Habe zwar gerade kein rsync griffbereit, aber ein paar kleine Tips:
- das .ssh-directory muß dem richtigen user gehören und die Rechte 700 haben, die Dateien drinnen alle 600. ssh ist da sehr pingelig.
- Bei Deinem rsync sieht es auf den ersten Blick so aus, als liefen da sehr verschiedene Versionen (3.0.9 und 3.1.3). Solltest mal prüfen, ob es deswegen Verständigungsprobleme gibt, sowas ist mir mal vor Urzeiten auf den Fuß gefallen.
Und wegen 'module is read only' - könnte es sein, daß irgendein Zielverzeichnis falsche Rechte hat oder gar nicht definiert ist?

 

[haweK]

Habe zwar gerade kein rsync griffbereit, aber ein paar kleine Tips:
- das .ssh-directory muß dem richtigen user gehören und die Rechte 700 haben, die Dateien drinnen alle 600. ssh ist da sehr pingelig.

Das auf dem Client oder der DS? Bei beiden gehört es dem User rsync. Die Modes sind aber etwas unterschiedlich 755 und 644, so wie es in der Anleitung stand,

- Bei Deinem rsync sieht es auf den ersten Blick so aus, als liefen da sehr verschiedene Versionen (3.0.9 und 3.1.3). Solltest mal prüfen, ob es deswegen Verständigungsprobleme gibt, sowas ist mir mal vor Urzeiten auf den Fuß gefallen.

Ja, das 3.0.9 ist wohl von der DS und das 3.1.3 ist wohl von "Buster". Habe da wohl wenig einfluß, besonders bei der DS.

Und wegen 'module is read only' - könnte es sein, daß irgendein Zielverzeichnis falsche Rechte hat oder gar nicht definiert ist?

Ich habe gemeinsame Ordner eingerichtet, Wenn ich mir die Berechtigungen in DSM für diese Ordner ansehe, so hat der User rsync dort Schreib- und Leserechte. Wenn ich dann auf DSM über das Icon FileStaton Berechtigungen prüfe ist erst einmal rsync nicht aufgelistet. Wenn ich die "Erweiterten Berichtigungen" prüfe, hat der User rsync alle Häkchen gesetzt.

 

[haweK]

OK, ich bin jetzt die vorgeschlagenen Schritte noch einmal im einzelnen Durchgegangen und bin jetzt ein wenig weiter gekommen.
Ich habe mich jetzt von dem Client via ssh ohne Passwort als User "rsync" auf die DS eingeloggt. Dann lande ich in einer Shell. ein ls zeigt nichts. Dann ein CD /volume1/ und ich bin in dem Hauptverzeichnis.Darin ist u.A. das Verzeichnis "NetBackup". Ein cd NetBackup funktioniert.und ein ls -l auch. Soweit sollte doch dann alles richtig sein, oder?
Dann habe ich wider ein wenig vom Client aus experimentiert. Der letze Fehler war der rsync Targetaufruf. Hier darf ich nicht <user>@<ds_ip>:/volume1/NetBackup schreiben, sonder es muss <user>@<ds_ip>:NetBackup heissen.

Danke, ihr habt mir den richtigen Weg gezeigt.

 

[wolfn]

Freut mich, wenn es jetzt wunschgemäß läuft

Das mit den Pfad-Bezeichnungen hat mich auch schon öfters ins Schleudern gebracht.
Die Rechte am .ssh-Verzeichnis sollten immer so sein, egal wo. Hatte schon die seltsamsten Fehler, wenn das nicht OK war.
Mit Ziel-Verzeichnis meinte ich alles, wo evtl. hingeschrieben werden soll/muß. Da kennst Du Dich sicher besser aus...
Und wenn jetzt die beiden Versionen problemlos miteinander reden können, ist ja alles gut.
Im Extremfall könnte man evtl. auf dem Client ein Downgrade machen oder von der alten Version ein eigenes Paket bauen.
Ein aktuelleres Paket auf der DS selber bauen scheitert meist an der dort vorhandenen Umgebung.

 

[haweK]

Freut mich, wenn es jetzt wunschgemäß läuft

Danke, bin ein Schritt weiter aber "wunschgemäß" ist anders. Jetzt landet alles im Home-Verzeichnis des Users rsync mit den Rechten des Users rsync.
Muss dann morgen früh weiter suchen. Zumindest geht jetzt der remote login und das grundsätzliche syncen ...

 

[wolfn]

Na, immerhin.
Ich vermute ganz stark, daß in dem Fall die Angabe des Ziel-Pfades nicht paßt (siehe oben).
Nimm doch erstmal eine Sicherung mit nur ein paar Dateien, damit man im Log noch was wiederfindet und geh mal das Protokoll vom rsync Zeile für Zeile durch, notfalls in eine Datei umleiten, wenn das nicht sowieso schon passiert.
Bin ziemlich sicher, daß Dir dann das Problem recht schnell auffällt.

 

[framp]

OK, jetzt klappt der ssh login ohne Password aber die Felehmerldun bei rsync ist

D.h. irgendwas hast Du beim Kopieren des Keys falsch gemacht. Keine Ahnung warum immer beschrieben wird was man manuell machen muss. Dabei geht es mit ssh-copy-id so einfach ...

Zu Deinem rsync Problem. melde Dich doch mal mit dem rsync Benutzer per ssh an und teste ob Du im Zielverzeichnis eine Datei anlegen kannst. Einfach

touch /<zielverzeichnis>/rsyncTestdatei
ls -la /<zielverzeichnis>/rsyncTestdatei

 

[blurrrr]

Mal so "ganz" grundsätzlich... ich weiss ja wie verführerisch es ist, wenn man eine Problemstellung hat, eine Anleitung im Internet findet und dann quasi blindlings drauf los kopiert...Aber: 1) Die Zeiten ändern sich (Anleitung ggf. veraltet), 2) diese Hobby-Anleitungen... sind oft nach "Gutdünken" (hauptsache funktioniert "irgendwie"), 3) basierend auf "2" - sind gern auch mal einfach der "falsche" Weg.

Ist ein bisschen wie beim Reifenwechsel... NIEMAND knallt einfach nur Reifen ans Auto und fährt sofort auf die Autobahn und brettert da mit 200km/h durch die Gegend... Reifen dran, festschrauben, nochmal kontrollieren, ggf. nochmal nachziehen, "kleine" Runde fahren und mal gucken... nach ein paar Kilometern (kennen wir alle) halt nochmal Schrauben nachziehen.

Genau so sollte das auch bei solchen Projekten laufen. Das Ziel ist klar, dann wird geguckt, was an Diensten benötigt wird und in welcher Reihenfolge die Dinge ablaufen zu haben. Nach User-Erstellung, Anlage und Kopie des Keys muss natürlich auch erstmal die Verbindung getestet werden (mit dem entsprechenden User, denn genau so soll es ja auch laufen). Wenn das schon nicht läuft, muss man auch erst garnicht weitermachen, sondern sollte sich erstmal mit dem Grundproblem beschäftigen. Wenn die SSH-Sitzung dann problemlos aufgebaut werden kann, kommt halt der nächste Schritt.

Was @framp nun noch schrieb mit dem testen der Anlage von Dateien - das gehört sowieso schon dazu, noch bevor irgendwelche Automatisierungen greifen sollen. Wenn das schreiben/lesen schon nicht funktioniert, muss da auch kein Dienst laufen, der uns das nun ständig mit "geht nicht!" unter die Nase reicht.

Hört sich doof an (ich weiss) und geht (leider) auch in die Richtung "Ihr PC funktioniert nicht? Ist das Stromkabel denn eingesteckt und der PC eingeschaltet?", aber genau so muss es halt laufen. Ist schlussendlich auch einfacher bei der Problembehebung

 

[haweK]

Zu Deinem rsync Problem. melde Dich doch mal mit dem rsync Benutzer per ssh an und teste ob Du im Zielverzeichnis eine Datei anlegen kannst. Einfach

touch /<zielverzeichnis>/rsyncTestdatei
ls -la /<zielverzeichnis>/rsyncTestdatei

Ok, ich habe mich von dem Client wie oben beschrieben per ssh auf die DS eingeloggt. Das hat ohne password geklappt. Das Ergebnis ist nun

rsync@ds9:~$ ls -la /volume1/NetBackup/rsyncTestdatei
-rwxrwxrwx+ 1 rsync users 0 Sep  4 11:58 /volume1/NetBackup/rsyncTestdatei

Wenn ich

rsync@hoshi2:~ $ rsync -avuz --delete -e '/usr/bin/ssh -i /home/rsync/.ssh/hoshi2-rsync-key' /home/rsync rsync@192.168.2.5::NetBackup/

eingebe, wird eine Verbindung hergestellt und dann werde ich zur Passworteingabe aufgefordert. Wenn ich einfach die Eingabetaste drücke, geht es. Das ist bei der reinen ssh Verbindung nicht so. Ist in der rsyncd.conf bei den Modulen noch etwas einzustellen? Die Datei rsyncd.secrets ist leer.

 

[haweK]

Mal so "ganz" grundsätzlich...

OK, kann man so sehen.
Für mich ist rsync nicht gerade die Software mit der einfachsten User-Schnittstelle. Ein : oder Zwei, Mit / oder ohne. Mit ssh oder ohne. Dazu kommt noch das das Synology DSM Linux meiner Meinung nach auch ganz schön verbogen ist. Was mach nun der DAU in so einem Fall ...
Mhh - er versucht aus der Man-Page schlau zu werden, schafft das aber nicht. Er versucht aus der Hilfe der DSM schlau zu werden, Schaft das aber nicht.
Der nächste Schritt ist nun eine Anleitung zu finden, mhh auch das geht nicht wirklich gut aus. Also versucht der geneigte DAU das Problem mit seinem Wissen zu lösen, kommt aber auch nicht wirklich nicht weiter ...

Nichts für Ungut und ich bitte um Entschuldigung für die Belästigung.

 

[framp]

Was ist den die Ausgabe von

grep -v "^$" /home/rsync/.ssh/config

? Aber Achtung: Es koennen dort sensitive Informationen stehen Die vorher maskieren.

 

[the other]

Moin haweK,
ich gebe dir recht: mich hat die ssh Konfiguration zu Beginn auch etwas kirre gemacht. Dann noch rumtoben mit rsync auf dem Terminal ist ebenfalls gewöhnungsbedürftig. Aber man lernt ja gehen mit jedem einzelnen Schritt. Deswegen ja auch der Hinweis von blurrr: wenn du das Gehen gerade lernst, dann meldest du dich nicht gleich zum Marathonrennen an...

Und dabei bekommst du hier support, gerade blurrr und framp wissen idR (ähem, hi Jungs) schon sehr gut, wie es geht.
Belästigen tust du hier imho niemanden, dafür ist ein Forum doch da.
Vielleicht guckst du auch nochmal, was in der Datei /etc/sshd_config steht...vielleicht ist da für den user rsync noch anzupassen, dass KEINE Passwort abfrage kommen soll, sondern dieser ebenfalls mit dem PublicKey Auth-Verfahren (dann ohne Passphrase) eingeloggt wird.
Es ist am Anfang verwirrend. Aber du hast doch schon gut was geregelt bekommen, also einfach step-by-step weiterfragen, haben wir alle irgendwann mal so gemacht (und ich mach es heute noch so: wer nicht fragt bleibt dumm!)...

Wird die PW Abfrage auf dem Client hoshi2 UND/ODER 192.168.2.5 gemacht? In beiden clients mal in die sshd_config schauen, ob die richtig (hier Pubkey und no passphrase) gesetzt ist...

PS: der user Tommes hat ein Tool zur Erstellung von ssh Keys geschrieben, dass im Paketzentrum unter Synocommunity den Beginn etwas erleichtert, heisst es.

 

[haweK]

Was ist den die Ausgabe von

grep -v "^$" /home/rsync/.ssh/config

? Aber Achtung: Es koennen dort sensitive Informationen stehen Die vorher maskieren.

Auf dem Client oder NAS?

 

[the other]

Moinsen,
idR findest du das auf dem Client...

 

[haweK]

Was ist den die Ausgabe von

grep -v "^$" /home/rsync/.ssh/config

? Aber Achtung: Es koennen dort sensitive Informationen stehen Die vorher maskieren.

Sorry für die späte Antwort, ich hatte eine lange Schicht. Auf beiden Geräten

grep -v "^$" /home/rsync/.ssh/config
grep: /home/rsync/.ssh/config: No such file or directory

Auf dem Client liegt in dem Verzeichnis der privat- und public-key sowie die Datei known-hosts. Darin ist eine Zeile. das sollte wohl dann wohl der key vom NAS sein.

Auf dem NAS liegt unter /homes/rsync/.ssh/ nur die Datei "authorized_keys" mit einer Zeile Inhalt. Das ist dann wohl der Key vom client.