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
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
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
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'
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
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,
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'
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
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
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
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,
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
12 matches
Mail list logo
