Backup Central

I've set up an rdiff-backup system for backing up files from 3
machines and I'm very happy with the way the program works. I have a
few questions I'm hoping you guys can help me out with.

Security:

My laptop is one of the systems I want to back up and when I travel it
ends up behind a router I have no control over. Because of this, my
systems push to the backup server instead of the backup server pulling
from them. Because I'm pushing, I can't restrict the public SSH keys
on the backup server to read-only. I think this means that if any of
my private keys are stolen, the thief will have full read/write access
to all files owned by the user "holding" the public SSH key, although
that access will be limited to the rdiff-backup binary. I've prefixed
the public SSH keys on my backup server like this:

command="rdiff-backup
--server",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa ...
root < at > laptop
command="rdiff-backup
--server",from="12.34.56.78",no-port-forwarding,no-X11-forwarding,no-pty
ssh-rsa ... root < at > desktop

Since I don't want to provide root write access with SSH keys, another
drawback of the push configuration is that root ownership is not
preserved in the backups which I imagine will hinder restores. Are
there any other issues to consider when using rdiff-backup in this
way?

Non-Security:

If I deleted a file from one of my systems 61 days ago and today I run
--remove-older-than 60D, will the original file be deleted from the
backup or only the increments?

I'm backing up to a 1TB USB hard drive dedicated to backups. How low
should I set the super-user space reservation on that drive?

I'd like to store an additional copy of the backups on a remote
system. Would it be best to rsync between the USB hard drive and the
remote system?

What happens if a file changes while rdiff-backup is reading it?

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Sun, 14 Aug 2011, Grant wrote:

My laptop is one of the systems I want to back up and when I travel it
ends up behind a router I have no control over. Because of this, my
systems push to the backup server instead of the backup server pulling
from them.

Based on the 'security' classification you gave to this question, I assume
you're not entirely happy with the laptop pushing. I wouldn't be happy
with that either
Since you can't do much anything about those third party routers, I'd say
you should look for other ways do get it working in a way that does make
you happy.

So, try to find some more info about openvpn. If the routers allow ssh
connections to your backup server, they will most likely also allow an
openvpn "tunnel". Using that tunnel, you can instruct the backup server to
run rdiff-backup against your laptop. That way, your backup server will be
pulling data and your laptop only needs to contain the openvpn key. I
guess you could also configure openvpn in such a way that it would require
user input to start the connection.

I'm using openvpn myself for similar tasks, and once setup properly, it
makes life so much easier
(interconnecting distant private networks, where each location is
connected using isp-provided NAT-ing ADSL modems that don't allow the
users to change most of the settings)


Non-Security:

If I deleted a file from one of my systems 61 days ago and today I run
--remove-older-than 60D, will the original file be deleted from the
backup or only the increments?

If you remove all historic data from 60 days back and before, any trace of
the file deleted 61 days ago will be gone.
Since you deleted the file 61 days ago, the file was already deleted from
the backup and is only kept as a (snapshot) increment.
(That is: inside the rdiff-backup-data directory, which is usually
considered to not be part of "the backup".)


I'm backing up to a 1TB USB hard drive dedicated to backups. How low
should I set the super-user space reservation on that drive?

Any percentage you like..
If you run your backups under a normal user account on the backup server
(strongly suggested to do that!) the operating system will honour the
space reservation percentage. Otherwise, it will not.

Side note: file permissions and ownership is preserved in the metadata
files inside the rdiff-backup-data directory at the backup server. No need
to have them synchronized by using the root account on the backup server
to preserve this info. In fact, if your backup server has other
username<->uid mapping than the machines you are backing up, things would
get unexpectedly different anyway.
Restoring a backup (using the root account at the device that is being
restored to!) will automagically restore permissions and ownership.


I'd like to store an additional copy of the backups on a remote
system. Would it be best to rsync between the USB hard drive and the
remote system?

What happens if a file changes while rdiff-backup is reading it?

You could indeed rsync from USB hard drive containing rdiff-backup backup
tree to the remote system. Just make sure you either run rdiff-backup or
rsync at the same time. Running rsync from USB drive to the extra remote
system will not interfere with a running rdiff-backup session, but the
copy on the extra remote system will be uselessly out of sync and not
usable to restore using rdiff-backup.

If a file changes while rdiff-backup is reading it (on the server/laptop
being backed up, naturally), it will detect this when doing the final
checksum, emit a warning, and skip that file. Effectively it will be
treated as unchanged.

This is somethat different from rsync, which will try to recover and retry
to sync the file, but will eventually fail to sync the file if it keeps
changing. Both approaches make sense, it's just a matter of taste


--
Maarten

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Sunday, August 14, 2011, 22:54:18, Maarten Bezemer wrote:

So, try to find some more info about openvpn. If the routers allow ssh
connections to your backup server, they will most likely also allow an
openvpn "tunnel".

This should work with 99.9% of routers: set up the OpenVPN server at
home to listen on port 443 TCP (assuming you don't have HTTPS server
running - though even that could work, OpenVPN allows you to redirect
connections when running in TCP mode; it doesn't matter if the OpenVPN
server is behind a NAT router - just redirect port 443 to it). The
client (your laptop) would then connect to the OpenVPN server, which
most routers will pass, as outbound HTTPS connections are rarely
restricted.

You can then have the rdiff-backup server pull from your laptop using
the IP assigned by OpenVPN (which you can set to a static IP using the
client-config-dir settings).

--
< Jernej Simon�i� ><><><><>< http://eternallybored.org/ >

There are many inside dopes in politics and government.
-- Cohen's Law of Inside Dope


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Sun, 14 Aug 2011, Jernej Simoni wrote:

This should work with 99.9% of routers: set up the OpenVPN server at
home to listen on port 443 TCP (assuming you don't have HTTPS server
running - though even that could work, OpenVPN allows you to redirect
connections when running in TCP mode; it doesn't matter if the OpenVPN
server is behind a NAT router - just redirect port 443 to it). The
client (your laptop) would then connect to the OpenVPN server, which
most routers will pass, as outbound HTTPS connections are rarely
restricted.

But keep in mind that tunneling TCP over TCP (when running openvpn in TCP
mode) might haunt you badly due to tcp timeout/retransmit settings. I
always recommend running openvpn in UDP mode, and let the tunneled TCP
connection do its own timeout/retransmit magic. By default, any tunneled
data is just encapsulated into a UDP packet, and QoS bits should get
copied. Much cleaner than openvpn with TCP, which has to encapsulate the
data in a stream, and will potentially lose the ability to set QoS bits
when data is buffered and resent from a tcp tx queue that keeps growing
and growing due to more data arriving over the tunnel and tunneled
connections reaching tcp retransmit timeouts as well.

In short: try openvpn with udp first, and only go to tcp when all else
fails. In that case, however, using a simple SSH tunnel with -R argument
would be easier. (laptop sshs into backup server using password or
password-protected key; rdiff-backup starts at backup-server connecting to
localhost:tunneledport)


--
Maarten

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Monday, August 15, 2011, 0:19:05, Maarten Bezemer wrote:

But keep in mind that tunneling TCP over TCP (when running openvpn in TCP
mode) might haunt you badly due to tcp timeout/retransmit settings.

I've set up OpenVPN in TCP mode several times for locations that
blocked UDP, and so far never had any problems (including the run on
port 443 trick).

--
< Jernej Simon�i� ><><><><>< http://eternallybored.org/ >

If all you have is a hammer, every problem looks like a nail.
-- Baruch's Observation


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

My laptop is one of the systems I want to back up and when I travel it
ends up behind a router I have no control over.  Because of this, my
systems push to the backup server instead of the backup server pulling
from them.

I'm using openvpn myself for similar tasks, and once setup properly, it
makes life so much easier
(interconnecting distant private networks, where each location is connected
using isp-provided NAT-ing ADSL modems that don't allow the users to change
most of the settings)

That sounds like a great idea. I'll set up openvpn and switch from
pushing to pulling. BTW, is the read-only restriction on the public
SSH keys the only advantage of pulling vs. pushing? Are there any
drawbacks? In a pull arrangement, if the private keys on the backup
server are stolen, the thief would have root read-access on each
system?

I'm backing up to a 1TB USB hard drive dedicated to backups.  How low
should I set the super-user space reservation on that drive?

Any percentage you like..
If you run your backups under a normal user account on the backup server
(strongly suggested to do that!) the operating system will honour the space
reservation percentage. Otherwise, it will not.

Would it be safe to reserve zero space for root on the USB hard drive?
Maybe that reserved space is only necessary on a disk containing an
OS?

I'd like to store an additional copy of the backups on a remote
system.  Would it be best to rsync between the USB hard drive and the
remote system?

You could indeed rsync from USB hard drive containing rdiff-backup backup
tree to the remote system. Just make sure you either run rdiff-backup or
rsync at the same time. Running rsync from USB drive to the extra remote
system will not interfere with a running rdiff-backup session, but the copy
on the extra remote system will be uselessly out of sync and not usable to
restore using rdiff-backup.

Would you use rsync or would you have the remote system described
above act as a second rdiff-backup server and run the entire backup
process a second time?

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

In short: try openvpn with udp first, and only go to tcp when all else
fails. In that case, however, using a simple SSH tunnel with -R argument
would be easier. (laptop sshs into backup server using password or
password-protected key; rdiff-backup starts at backup-server connecting to
localhost:tunneledport)

You're saying openvpn with UDP would be best, then SSH -R, then
openvpn with TCP?

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Sun, 14 Aug 2011, Grant wrote:

That sounds like a great idea. I'll set up openvpn and switch from
pushing to pulling. BTW, is the read-only restriction on the public
SSH keys the only advantage of pulling vs. pushing? Are there any
drawbacks? In a pull arrangement, if the private keys on the backup
server are stolen, the thief would have root read-access on each
system?

If someone steals the private keys on the backup server, they already have
access to all your files. Although I admit there is a subtle difference
between 'all your base are belong to us' and actually using those keys to
plant malware on your laptop, but you will be screwed either way.
That's the reason why I keep my backup server unreachable from the outside
world.. not running any services on public IP address.


Would it be safe to reserve zero space for root on the USB hard drive?
Maybe that reserved space is only necessary on a disk containing an
OS?

0% would be 'safe', if rdiff-backup would be the only process writing to
the USB drive. Reserved space is primarily meant for OS disks such that
root still has the ability to login and move stuff around when non-root
users/processes made a mess and filled the entire disk.

However, it is still good to reserve some 2 or 3 % of your 1TB drive. Or
even go with the default which is usually 5%. If you are running out of
space and need to regress a failed backup due to "no disk space", you can
use tune2fs or other filesystem's relatives to create some more room to do
a proper cleanup.
(Reserved space is live-tunable on most file systems. If it is not, you
could set it to 0% and simply create a large "placeholder" file, and
deleting the placeholder file in case you need more space to regress.)



Would you use rsync or would you have the remote system described
above act as a second rdiff-backup server and run the entire backup
process a second time?

Using rdiff-backup to copy an rdiff-backup repository wouldn't be a good
idea. Using rdiff-backup against the original system (your laptop, etc)
might also not be what you want. So, I think using rsync to keep a copy of
the rdiff-backup tree would be the best way to go.


As for you other email:
You're saying openvpn with UDP would be best, then SSH -R, then
openvpn with TCP?

Yes. With openvpn/udp I usually get the most reliable and fast results.
Using ssh with a -R tunnel or using openvpn/tcp shouldn't be much of a
difference wrt performance, but ssh is usually considered to be easier to
setup.
Especially because you only need 1 connection to be tunneled, and you
don't need the advanced networking and routing stuff.
But, in the end, it's your call... it's all free software


--
Maarten

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

That sounds like a great idea.  I'll set up openvpn and switch from
pushing to pulling.  BTW, is the read-only restriction on the public
SSH keys the only advantage of pulling vs. pushing?  Are there any
drawbacks?  In a pull arrangement, if the private keys on the backup
server are stolen, the thief would have root read-access on each
system?

If someone steals the private keys on the backup server, they already have
access to all your files. Although I admit there is a subtle difference
between 'all your base are belong to us' and actually using those keys to
plant malware on your laptop, but you will be screwed either way.
That's the reason why I keep my backup server unreachable from the outside
world.. not running any services on public IP address.

I don't quite follow. You're saying it doesn't matter that the thief
has root read access on each backed-up system via the SSH keys because
he would already be able to read all of the important files from each
of those systems via the backups on the compromised backup server?

I realized today that since the backup server needs root access on
each of the machines, I won't be able to disallow root logins. Is
that correct? If so, isn't that a major drawback to pulling?

Would it be safe to reserve zero space for root on the USB hard drive?
Maybe that reserved space is only necessary on a disk containing an
OS?

0% would be 'safe', if rdiff-backup would be the only process writing to the
USB drive. Reserved space is primarily meant for OS disks such that root
still has the ability to login and move stuff around when non-root
users/processes made a mess and filled the entire disk.

However, it is still good to reserve some 2 or 3 % of your 1TB drive. Or
even go with the default which is usually 5%. If you are running out of
space and need to regress a failed backup due to "no disk space", you can
use tune2fs or other filesystem's relatives to create some more room to do a
proper cleanup.

Is it necessary to reserve 20GB on a 1TB disk? If the OS is not on
the USB backup drive, is there any scenario under which I would need
space reserved for root on that disk? I would think free space on the
OS disk would be all that's necessary if the USB drive fills up.

Would you use rsync or would you have the remote system described
above act as a second rdiff-backup server and run the entire backup
process a second time?

Using rdiff-backup to copy an rdiff-backup repository wouldn't be a good
idea. Using rdiff-backup against the original system (your laptop, etc)
might also not be what you want. So, I think using rsync to keep a copy of
the rdiff-backup tree would be the best way to go.

I tried to set this up today but I ran into a problem. My backup
server backs up its own files to the USB drive. If that operation is
conducted as a normal user, it can't read all of the necessary files.
If that operation is conducted as root, the backed-up files are
written as root and the remote system can't read them via rsync unless
I allow root logins.

I also had a hard time restricting the SSH key on the backup server to
the rsync command and read-only. Can that be done?

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Mon, 15 Aug 2011, Grant wrote:

If someone steals the private keys on the backup server, they already have
access to all your files. Although I admit there is a subtle difference
between 'all your base are belong to us' and actually using those keys to
plant malware on your laptop, but you will be screwed either way.
That's the reason why I keep my backup server unreachable from the outside
world.. not running any services on public IP address.

I don't quite follow. You're saying it doesn't matter that the thief
has root read access on each backed-up system via the SSH keys because
he would already be able to read all of the important files from each
of those systems via the backups on the compromised backup server?

If someone has found a way to gain access to the private keys that should
only be present on your backup server, then all the data on your backup
server should be considered compromised. That could very well include
sensitive files that are copies of sensitive files on your 'real' systems.
Of course, having access to these private keys could also give an attacker
access to any file currently on the 'real' systems, but that type of
staged attacks is not very common. (At least not yet...)


I realized today that since the backup server needs root access on
each of the machines, I won't be able to disallow root logins. Is
that correct? If so, isn't that a major drawback to pulling?

You can disallow root logins using password authentication, and set
PermitRootLogin without-password
in /etc/ssh/sshd_config. That would be secure against any dictionary
attack launched against the root account.

And, looking at the whole subject from a different angle: pushing also has
the large drawback that in case your laptop is stolen/lost/whatever, and
you use an ssh key for rdiff-backup to connect to your backup server, you
risk not only losing your 'real' systems, but the backup server can also
be compromised it an attacker starts using that key.

Both types of private key abuse could possible be mitigated by using
passphrase-protected private keys. Then you're back at the 'default' risk
of keyloggers intercepting these passphrases...

Bottomline: you have to define your trust levels


Is it necessary to reserve 20GB on a 1TB disk? If the OS is not on
the USB backup drive, is there any scenario under which I would need
space reserved for root on that disk? I would think free space on the
OS disk would be all that's necessary if the USB drive fills up.

If you want to recover from a backup that failed half-way through due to a
Disk Full situation, you need even more disk space to regress to a sane
state. You could do that by temporarily reducing the reserved-for-root
percentage. Another way could be to just create a few GB of placeholder
files you could delete on these occasions. That's up to you to decide.


I tried to set this up today but I ran into a problem. My backup
server backs up its own files to the USB drive. If that operation is
conducted as a normal user, it can't read all of the necessary files.
If that operation is conducted as root, the backed-up files are
written as root and the remote system can't read them via rsync unless
I allow root logins.

Try doing the local operation through the localhost network


I also had a hard time restricting the SSH key on the backup server to
the rsync command and read-only. Can that be done?

I know there have been some issues regarding rdiff-backups 'restrict read
only' switch, but as far as I know, these should be solved. Not using them
myself, so not entirely sure.
Restricting a key to multiple commands would be a harder thing to do..
probably better to just create two (different!) keys and define each one
with a different "command=...." in the authorized_keys file.


HTH..

--
Maarten

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

If someone has found a way to gain access to the private keys that should
only be present on your backup server, then all the data on your backup
server should be considered compromised. That could very well include
sensitive files that are copies of sensitive files on your 'real' systems.
Of course, having access to these private keys could also give an attacker
access to any file currently on the 'real' systems, but that type of staged
attacks is not very common. (At least not yet...)

Yeah, I guess it's between allowing root read access of each system if
the backup server is compromised (pull), or allowing read/write access
of only the backups on the backup server if one of the systems is
compromised (push).

I realized today that since the backup server needs root access on
each of the machines, I won't be able to disallow root logins.  Is
that correct?  If so, isn't that a major drawback to pulling?

You can disallow root logins using password authentication, and set
PermitRootLogin without-password
in /etc/ssh/sshd_config. That would be secure against any dictionary attack
launched against the root account.

Good point. Although it isn't surprising, I didn't know sshd_config
allowed that sort of control.

And, looking at the whole subject from a different angle: pushing also has
the large drawback that in case your laptop is stolen/lost/whatever, and you
use an ssh key for rdiff-backup to connect to your backup server, you risk
not only losing your 'real' systems, but the backup server can also be
compromised it an attacker starts using that key.

If I were to set up a separate user for each pushed backup and one of
the systems were compromised, only the compromised system's backups
would be accessible to the attacker (read/write unfortunately).

Both types of private key abuse could possible be mitigated by using
passphrase-protected private keys. Then you're back at the 'default' risk of
keyloggers intercepting these passphrases...

That would be more secure, but I'm trying to set up unattended backups.

Is it necessary to reserve 20GB on a 1TB disk?  If the OS is not on
the USB backup drive, is there any scenario under which I would need
space reserved for root on that disk?  I would think free space on the
OS disk would be all that's necessary if the USB drive fills up.

If you want to recover from a backup that failed half-way through due to a
Disk Full situation, you need even more disk space to regress to a sane
state. You could do that by temporarily reducing the reserved-for-root
percentage. Another way could be to just create a few GB of placeholder
files you could delete on these occasions. That's up to you to decide.

I suppose I may as well just leave it at 5%.

I tried to set this up today but I ran into a problem.  My backup
server backs up its own files to the USB drive.  If that operation is
conducted as a normal user, it can't read all of the necessary files.
If that operation is conducted as root, the backed-up files are
written as root and the remote system can't read them via rsync unless
I allow root logins.

Try doing the local operation through the localhost network

I don't think I follow (again). The backup server drops its own
important files onto the USB hard drive that is directly attached to
it. Anyway, that problem would be solved if I used your
'PermitRootLogin without-password' advice above.

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On 18/08/11 22:47, Grant wrote:

And, looking at the whole subject from a different angle: pushing also has
the large drawback that in case your laptop is stolen/lost/whatever, and you
use an ssh key for rdiff-backup to connect to your backup server, you risk
not only losing your 'real' systems, but the backup server can also be
compromised it an attacker starts using that key.
If I were to set up a separate user for each pushed backup and one of
the systems were compromised, only the compromised system's backups
would be accessible to the attacker (read/write unfortunately).

Practically this seems to me a pretty good solution. Push your backup
from your laptop to a dedicated user on the (GNU/Linux) backup server,
ensuring that its users cannot access (read or write) other users' data:

To ensure privacy for any new users on the backup server, in
/etc/adduser.conf add/alter:
DIR_MODE=0700

For existing users on the backup server, run:
sudo chmod 700 /home/*

When you create a user on the backup server, don't set a password i.e.
login is only by public/private key authentication. Use a dedicated
private key on the laptop for the backup, and put its public key on the
backup server at (and only at) /home/[user]/.ssh/authorized_keys.

You need to be happy that there is nothing readable (or writeable) by a
non-privileged user on the backup server that you would not want a
hacker to see e.g. at /var/ or /opt/. For tighter security on the backup
server you can limit the user to running a single command e.g.
http://www.cmdln.org/2008/02/11/restricting-ssh-commands/.

If the laptop is stolen, remove the corresponding public key from the
backup server so that the laptop can no longer get access. And even if
the thief moved fast enough to get into the backup server before you
could remove the public key, she could only access the backup history
for that laptop, and she has the laptop's data already...

Dominic

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On 2011-08-18 22:25, Maarten Bezemer wrote:

On Mon, 15 Aug 2011, Grant wrote:

[snip]

I realized today that since the backup server needs root access on
each of the machines, I won't be able to disallow root logins. Is
that correct? If so, isn't that a major drawback to pulling?

You can disallow root logins using password authentication, and set
PermitRootLogin without-password in /etc/ssh/sshd_config. That would
be secure against any dictionary attack launched against the root
account.

And, looking at the whole subject from a different angle: pushing
also has the large drawback that in case your laptop is
stolen/lost/whatever, and you use an ssh key for rdiff-backup to
connect to your backup server, you risk not only losing your 'real'
systems, but the backup server can also be compromised it an attacker
starts using that key.

Both types of private key abuse could possible be mitigated by using
passphrase-protected private keys. Then you're back at the 'default'
risk of keyloggers intercepting these passphrases...

There is a third solution, designed specifically for that kind of
problem. You can put a command= option in front of your key in the
authorized_keys file to restrict the usage of the key to a specific [set
of] command. See AUTHORIZED_KEYS FILE FORMAT in "man sshd".

N.

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Fri, 19 Aug 2011, Nicolas Jungers wrote:

There is a third solution, designed specifically for that kind of
problem. You can put a command= option in front of your key in the
authorized_keys file to restrict the usage of the key to a specific [set of]
command. See AUTHORIZED_KEYS FILE FORMAT in "man sshd".

OP mentioned having problems with the command= option...
But if you can get that to work properly (and restrict it to read-only
access), that would even be preferable to push-style, since compromising
the backup server would then at most give the attacker read access to the
'laptop', for which the data was already on the backup server.. so no real
gain for an attacker.

Push-style "would only have the risk of accessing the laptop's backup on
the backup server", but for me, the risk of losing a backup when my laptop
is hacked/stolen/lost is simply unacceptable. If one doesn't mind losing
her backups when the primary device is compromised, then she shouldn't
bother backing it up in the first place.


--
Maarten

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Thu, 18 Aug 2011, Grant wrote:

If I were to set up a separate user for each pushed backup and one of
the systems were compromised, only the compromised system's backups
would be accessible to the attacker (read/write unfortunately).

No. It would indeed be read/write which is a no-go for most serious backup
systems (lose the primary, and all you have left is a compromised backup,
potentially no backup at all). And another risk would be that the attacker
finds some way to elevate her privileges on the backup server due to some
but in rdiff-backup, python or something similar. In which case the entire
backup server would be compromised.

I tried to set this up today but I ran into a problem.  My backup
server backs up its own files to the USB drive.  If that operation is
conducted as a normal user, it can't read all of the necessary files.
If that operation is conducted as root, the backed-up files are
written as root and the remote system can't read them via rsync unless
I allow root logins.

Try doing the local operation through the localhost network

I don't think I follow (again). The backup server drops its own
important files onto the USB hard drive that is directly attached to
it. Anyway, that problem would be solved if I used your
'PermitRootLogin without-password' advice above.

You said you backup the backup server's own files to the USB drive. When
doing that with rdiff-backup running as root, the backup will also have
file permissions and ownership preserved (mostly). When you run that
rdiff-backup process as a normal user (backup side) to back up files from
root < at > localhost (source side), just pretending that it is a remote host,
then the backup tree will be accessible by non-root rsync user.


--
Maarten
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki