Woclema, now with valid Atom/XML
17 November 2008 13:58:39
my software, woclema
The latest version of Woclema
finally produces XML that validates against Atom DTD. The bad news is
that the old feed will now have an invalid ID (in theory and practice).
If you're reading this post with a feed reader, you probably already
wondered why you're seeing all the old posts too. That's why. Anyway,
if I get to choose between "broken now" and "broken
forever" it's fairly easy decision. Especially because I think
Woclema has somewhat limited target audience.
Permalink | Comments (0)
Using separate RSA-key with OpenSSH for unattended backups
17 November 2008 10:25:20
for future reference
What an ignorant slob I've been. I've used RSA/DSA keys for
passwordless logins with SSH for ages, but I could never figure out a
way to use the method for backups. Creating a key without a passkey
sounded like a bad idea because what good would the one with a passkey
then do? As result, I always had to manually run the backup script.
Today, finally, I came across the solution.
When I upgraded my home server earlier this year I also set up a RAID-1
array as a backup disk. The other hosts on my intranet could finally
make remote backups to centralised place instead of using each others'
disks. At first I used rsync to backup the files. While this method
worked just fine it did have a couple of limitations. First of all the
backup didn't necessarily match the backup source. A file removed
locally was never deleted from the backup. Secondly and more
importantly, using rsync for backups didn't protect from infamous SUE,
aka. stupid user error. For example if I overwrite an important file
and then run the backup script, there was no way to recover the file.
I soon started looking for an alternative method.
I browsed through many of the backup related packages in Debian
repository. Some couldn't deal with backups over networks and many
couldn't create incremental backups. Some simply looked like I'd rather
not touch them. There was one particular package, rdiff-backup, which
looked promising but which would require the same version running at
both ends. You can only guess what that meant with the server running
Debian stable and the others running more-or-less up-to-date Debian
unstable.
After a few months there was an article about rdiff-backup on Debian Package of the Day. After
reading the article I was sold -- regardless of the version
incompatibility this was the tool I wanted to use. Luckily enough it
was trivial to recompile the version on stable for unstable. I switched
to rdiff-backup the very same day and didn't look back. Still, I would
be running the backups manually once a day.
When I started the backup script this morning I started to wonder if
there really was an easier way. A quick search with Google revealed a
configuration option for OpenSSH previously unknown to me:
command="foo". This little option for
.ssh/authorized_keys defines what command is used instead of
given command when the key is used for authentication. This combined
with separate passkeyless RSA key and an entry in .ssh/config
makes it unbearably easy to use rdiff-backup for unattended backups
without allowing the key to be used for anything else. To further limit
misuse of the key, rdiff-backup can be restricted to given path with
--restrict option.
To summarise.
- .ssh/authorized_keys
-
The following line should be a single line, just like other
entries in your authorized_keys.
command="rdiff-backup --server --restrict /raid/wnd",from="kikai.katei.fi",
no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC1[...] wnd-backup@kikai
- .ssh/config
-
Host chikan-backup
Hostname chikan
IdentityFile ~/.ssh/backup.id_rsa
- rdiff-backup
-
rdiff-backup /home/wnd chikan-backup::/raid/wnd
Permalink | Comments (0)