from Donatello@lemmy.ml to linux@lemmy.ml on 24 Nov 12:15
https://lemmy.ml/post/22845490
Hi,
I need to setup a Rsync server to backup a š” NAS.
So I want to run it under SSH.
man rsync
> Also note that the rsync daemon protocol does not currently provide any encryption of the data that is transferred over the connection. Only authentication is provided. Use ssh as the transport if you want encryption.
but when I do rsync --config=/etc/rsyncd.conf --rsh=ssh --dry-run
I get:
rsync: --rsh=ssh: unknown option (in daemon mode) So there no way to specify that rsync daemon should run under ssh ?
Also is this following A.I statement is correct ?
The rsyncd.conf file is only used when the rsync daemon is running on the remote host and the client connects to the daemon directly, without using an SSH connection.
So there is no way with Rsync (under ssh) to set settings (config file or other) that will apply to all clients !!??
So itās the client that configure rsync and the server !? there is no way around ?!
threaded - newest
Soā¦ As long as you have ssh running open on the receiving server, you donāt need the rsync daemon. Rsync client will ssh, then execute rsync recipient automatically.
The daemon is only for if you donāt want to or cannot run ssh really.
Is there a specific reason you are looking at the daemon, or just unfamiliar?
Using the daemon also allows you to transfer faster by removing compression and encryption. It tends to hit the same rclone speeds without the data corruption issues.
You can do so directly in the ssh config or command line also. Iāve used this very thing in dense cluster private OpenStack deployments over the years.
Just trying to narrow down use case but I suspect the complex documentation just overwhelmed.
(disclaimer: this information might be years out of date but i think it is still accurate?)
SSH doesnāt have a null cipher, and if it did, using it still wouldnāt make an SSH tunnel as fast as a TCP connection because SSH has its own windowing mechanism which is actually what is slowing you down. Doing the cryptography at line speed should not be a problem on a modern CPU.
Even though SSH tunnels on your LAN are probably faster than your internet connection (albeit slower than LAN TCP connections), SSHās windowing overhead will also make for slower internet connections (vs rsync or something else over TCP) due to more latency exacerbating the problem. (Whenever the window is full, it is sitting there not transmitting anythingā¦)
So, to answer OPās question:
ārsh=ssh
as that is the default).man rsync
and read the section referred to by this:HTH.
Iāve been doing the same in pull-backups for years. It works nicely.
I think you donāt need to specify that you want to use SSH. unless you give the location as starting with rsync://, or set to use the rsh protocol, it should use ssh by default.
just use user@targethost:path. The part before : is the same as what you use in SSH, and the part after it may be an absolute or a relative (to user home) path
The statement is correct, rsync by itself doesnāt use ssh if you run it as an daemon and if you trigger rsync over ssh then it doesnāt use daemon but instead starts rsync with UID of the ssh-user.
But, you can run rsyncd and bind it only to localhost and connect to that over ssh-tunnel. That way you can get benefits of rsync daemon and still have encrypted connection with ssh.
Thank you @IsoKiero@sopuli.xyz !
This is the solution.
unfortunately I canāt apply it, because the NAS is a closed proprietary š©
You basically want to use the daemon but under ssh. I looked into this before, and I think it is possible but the command for it is weird and confusing. Wish I remembered it, but just commenting to say that I vaguely remember thereās a way (or maybe Iām hallucinating).
stackoverflow.com/ā¦/copying-files-using-rsync-froā¦
Hereās several ways to run rsync over SSH.
Given that you can already use rsync over ssh, I suspect you want to allow the rsync configuation options on the server side, but still use ssh to secure the transit. I would do it like this:
That would encrypt the traffic over your ssh tunnel, but still allow you to use the receiverās rsyncd paths.