在没有 ssh 的守护进程模式下使用 rsync 有多不安全
正如我们所知，我们可以通过 ssh 使用 rsync 在计算机之间发送文件，特别是在不同网络（例如互联网）中进行安全传输。 （这是正确的，我们都同意）
并且据我们所知，rsync 在使用正常方式传输数据时不提供任何安全性，因此我们使用 ssh 作为掩护。
所以这个想法！
如果我们在守护进程模式下使用 rsync（例如，在位于英国的 Linux 备份服务器上），并且我们开始使用互联网线路备份 Linux 计算机（例如来自法国）的数据，而不使用 ssh（只需使用普通的 rsync 守护进程选项)
示例：
rsync -vazi --progress source rsync://[email protected]/somefolder/
那么问题是
您认为这是一种安全的方式吗？
如果没有，是否有人可以知道我们正在传输什么以及我们正在传输的文件内容是什么？
当 rsync 提示输入 rsync 用户密码时，是否有机会捕获我们输入的密码？
我知道使用 ssh 或 stunnel 更安全。但我真的想更多地了解为什么使用正常方式时它不安全，特别是当我们通过互联网在计算机之间同步数据时。
感谢您的回答。
As we know we can use rsync via ssh to send files between computers especially in different network (e.g Internet) to have some secure transfers. (thats right and we all agree with it)
and as we know also rsync does not provide any security while transferring data using normal way therefore we use ssh as cover.
So the idea!.
If we use rsync in daemon mode (on the linux backup server located in England for example) and we start backing up the data from linux computers (from France for example) using the internet line without using ssh (just use the normal rsync daemon option)
example:
rsync -vazi --progress source rsync://[email protected]/somefolder/
So the question is
do you think this is a secure way?
if not , is there any one can know what we are transferring and what the content of the files we are transferring?.
also is there chance to catch the password which we entered when rsync prompt for the rsync user password?
I know that using ssh or stunnel is more secure. but really i want to know more about why is it in-secure while using the normal way especially when we are rsync data between computers over the Internet.
and Thanks for any answers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
没有 SSH 的 Rsync 事务是不安全的，因为协议和软件本身不包含任何内容加密。因此，如果中间有一个人，他可以读取/复制您正在备份的内容。也可以读取身份验证。
您应该考虑在生产网络和备份网络之间使用 SSH 或 VPN。
Rsync transactions without SSH are insecure because the protocol and the software itself does not include any content encryption. So if there is a man in the middle he can read/copy what you are backing up. Authentication can be read also.
You should consider either using SSH or VPN between your production and backup network.
当您使用 SSH 时，您不仅可以获得机密性，还可以获得身份验证。
保密性可确保没有人可以看到您通过互联网发送的数据。身份验证可确保您实际上连接到正确的服务器（如 fyr 提到的中间人攻击）。如果您的数据没那么重要，您可能会说“嘿，没有人会窃取我的数据，这没那么重要”。
真正让我担心的安全问题是，当您在没有身份验证的情况下进行 rsync 时，缺乏身份验证。这意味着任何人都可以连接您的计算机并向您的计算机发送数据。想象一下，有人坐在服务器之间的任何位置，他们看到一个未经身份验证的连接通过 rsync 写入数据。现在他们知道如何登录您的服务器并转储和检索信息。您刚刚为每个人创建了一个免费的匿名文件转储。这看起来似乎不是什么大问题，直到人们开始将它用于非法目的，或者只是将病毒/rootkit 转储到您的计算机上。
在我看来，没有1-10级的风险可以量化这种风险，这是不可接受的。只需进行端口扫描即可查看端口是否打开，然后脚本就可以发现漏洞。
When you use SSH you gain not only confidentiality but you also gain authentication.
The confidentiality makes sure that nobody can see your data as it's being send over the internet. The authentication makes sure that you are actually connected to the right server (man in the middle attack like fyr mentioned). If your data isn't that important you may say something like "Hey, nobody's going to steal my data it's not that important".
The security issue which really worries me is the lack of authentication when you just do rsync without authentication. This means that anybody can connect and send data to or from your machine. Imagine someone's sitting anywhere in between the servers and they see an unauthenticated connection writing data via rsync. Now they know how to log into your server and dump and retrieve information. You've just created a free anonymous file dump for everyone. This may seem like not a big problem until people start using it for illegal purposes, or just dump a virus/rootkit onto your machine.
In my opinion there is no risk level 1-10 which can quantify this risk, it's simply unacceptable. It only takes a port scan to see that port is open, then a script may find the vulnerability.
您还可以在 rsyncd.con 模块中使用“hosts allowed = xxx.xxx.xxx.xxx”。即使攻击者掌握了用户/密码，它也只允许来自给定主机的连接。
you can also use the "hosts allow = xxx.xxx.xxx.xxx" in the rsyncd.con module. After even if the attacker gets is hands on the user/password it only allow connection from the given host.