David Kempe wrote:
we have solved similar problems where we had no control over some of
the lower layers, by implementing a openvpn tunnel. SSH over openvpn
seems to improve in reliability a little. I know it sounds whack, but
it works.
If you have a VPN, there's no point to running SSH and thus getting two
layers of encryption and authentication -- it makes sense just to
replace SSH with netcat. I've done exactly that, as follows.
On the server, I'm using runit with ipsvd and the following run script:
---- snip run
#!/bin/bash
exec 2>&1
if [ instruct.d -nt instruct.cdb ] ; then
ipsvd-cdb instruct.cdb $(mktemp instruct.cdb.tmp-XXXXXX) instruct.d
setfacl -m u:backup:r instruct.cdb
fi
exec tcpsvd -vv -u backup -p -C 1 -c 400 -x instruct.cdb 10.1.128.1
10873 ./rdiff-backup-server
---- end snip
---- snip rdiff-backup-server
#!/bin/sh
if [ -z "$TCPREMOTEHOST" ] ; then
echo "$TCPLOCALIP not resolved to a hostname; exiting" >&2
exit 1
fi
DATAPATH="/path/to/data/$TCPREMOTEHOST"
mkdir "$DATAPATH"
exec rdiff-backup \
--server \
--restrict "$DATAPATH" \
--force-path-prefix "$DATAPATH" \
$*
---- end snip
...where instruct.cdb identifies systems coming over the VPN as good and
everyone else as bad.
This isolates individual machines so that they can only see their own
backed-up content (one system can't restore data backed up by a
different system) and can use an absolute path for backups and restores
(rather than using a path that includes their hostname or which has
other knowledge of the directory structure on the server).
The clients then invoke rdiff-backup as follows:
rdiff-backup --remote-schema 'netcat %s 10873' <other args>
...and there we go! (Obviously, I'm using GNU netcat).
