| View previous topic :: View next topic |
| Author |
Message |
BitJam
Advocate
Joined: 12 Aug 2003
Posts: 2513
Location: Silver City, NM
|
 Posted: Thu Mar 06, 2014 2:29 am Post subject: |
 |
|
| That's the link I posted earlier in this thread. |
|
| Back to top |
|
 |
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Thu Mar 06, 2014 5:22 pm Post subject: |
|
|
Yes, sorry I didn't give proper attribution, but I thought it was obvious since it was only a couple posts up.
And another thing, whether rsync encrypts by ssh or not isn't as important as the fact that you have allowed ssh to the root account.
All this talk about the username being irrelevant or almost irrelevant doesn't take into account that it's a default account, and it's the superuser account, and if you can brute force that you have all rights. So any brute force scheme makes more sense if it throws most of the resources against the root account.
If you set your user so they can only sudo rsync, then that eliminates some of the security woes of the bad guys cracking the unprivileged account. I believe that link shows how. |
|
| Back to top |
|
|
grant123
Veteran
Joined: 23 Mar 2005
Posts: 1099
|
| Posted: Fri Mar 07, 2014 1:28 am Post subject: |
|
|
| What about root SSH access via passworded keys and 'PermitRootLogin without-password'? That must be pretty safe. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Mar 07, 2014 2:08 am Post subject: |
|
|
Look. It's your box, but the doc you were pointed at proves that root access across the wire is unnecessary.
You obviously haven't had a production system owned yet. I have. Several times, fortunately nothing that cost a lot of money to fix. The thing I learned is you always try to minimize the risk.
RSyncing an entire system across the wire, why? What does that get you?
Root access across the wire, it's not necessary. Why? What does that get you?
Defense in depth. Never leave your security to a single layer. If your system can be owned through a single vulnerability in something you know, then that's no good.
So you want to rsync as root. Go ahead, it's your box and hopefully you're not storing any financial information on there. You could get away with it for years, or you could get owned the first day. I've said all I can to point you in a safer direction, it's up to you now.
Have fun. |
|
| Back to top |
|
|
grant123
Veteran
Joined: 23 Mar 2005
Posts: 1099
|
| Posted: Fri Mar 07, 2014 2:32 pm Post subject: |
|
|
| Quote: | | Defense in depth. Never leave your security to a single layer. If your system can be owned through a single vulnerability in something you know, then that's no good. |
So the vulnerability in this case would be someone breaking into my personal system, stealing my private key, and bruteforcing it to get the password?
| Quote: | | hopefully you're not storing any financial information on there |
Nope, nothing like that. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Mar 07, 2014 10:57 pm Post subject: |
|
|
| grant123 wrote: | | Quote: | | Defense in depth. Never leave your security to a single layer. If your system can be owned through a single vulnerability in something you know, then that's no good. |
So the vulnerability in this case would be someone breaking into my personal system, stealing my private key, and bruteforcing it to get the password?
| Quote: | | hopefully you're not storing any financial information on there |
Nope, nothing like that. |
The vulnerability that gets you is the one you don't know, not just the ones you can think of. Getting access to a private key is an obvious one.
Overly authorized accounts making or allowing network connections are vulnerable. Why do you think services change the user to some account that can't even log in? Why go through the trouble, if there were no risk? Why do services chroot into a jail AND change to an unprivileged user who can't log in if there were no risk? |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Mar 07, 2014 11:11 pm Post subject: |
|
|
And what's the deal anyway?
You've been given step-by-step instructions on how to do this without allowing remote root login, and you still want to do it with remote root login? What possible motivation could there be?
I wish you the best of luck. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Mar 08, 2014 8:57 am Post subject: |
|
|
| 1clue wrote: | | If you want to rsync system A's entire contents to system B, then start it from A as root, write it to system B as an unprivileged user into an excluded directory on B which does not exist on A. Then as root on B, sync from that to system B in its original location. |
This is what I meant by "jumping loops": A transfer of data is possible, but not really in an "rsync" way (by "quickly" showing you the new/old/changed files, transferring only new data etc) - more or less you can do only the same as you could do only with tar and scp.
I have to travel a lot and make various changes on various systems, so after a while I have to sync various data of different users (or sometimes global data/config-files) between both directions on several machines - typically, I do not remember which changes I made and want to transfer, so using the mentioned rsync features is really "mandatory".
When syncing, the connection is typically only local, so security is not a concern in this moment (but I think it would be the same for non-local connections since I suppose that ssh can be considered reasonably safe).
I consider this information rather nonsense: If you setup a user who can use "sudo" (at least with the privileges to read/modify all files) without a password you can allow root access as well - the latter has the advantage that ssh easily allows to "block" password access for root (which was the original quesiton of this thread). |
|
| Back to top |
|
|
grant123
Veteran
Joined: 23 Mar 2005
Posts: 1099
|
| Posted: Sat Mar 08, 2014 4:39 pm Post subject: |
|
|
| Quote: | | You've been given step-by-step instructions on how to do this without allowing remote root login, and you still want to do it with remote root login? What possible motivation could there be? |
Simplicity is the motivation. Security is paramount but there is a tradeoff between that and simplicity. I will delve into the sudo stuff but we shouldn't pretend that the tradeoff isn't important. |
|
| Back to top |
|
|
|
Networking & Security
