The way
.ssh/authorized_keys is typically used is not secure. Because
using it securely is hard, and dumping in passwordless ssh keys is easy. I
spent about 5 hours today locking down my
authorized_keys.
rsync
The only easy case is a rsync of a single directory. Follow these
good instructions.
If you need to rsync multiple separate directories, it's easy to find
several
documents involving a
validate-rsync.sh. Do not use, it is
insecure -- it allows rsync to be
run with any parameters. Including parameters that allow the remote system
to rsync in a new
~/.ssh/authorized_keys. Oops. (You can probably also
trick
validate-rsync.sh into running other arbitrary commands.) To be
secure, you have to check the rsync parameters against some form of
whitelist.
git
Locking down git should be easy. Use
git-shell.
Unless you also want to be able to log in to an interactive shell on the
same account. To do that, you'll need to generate a separate ssh key for
git. Both git servers I use are named
git.*, so I set it up like this in
~/.ssh/config on the client:
Host git.*
IdentityFile ~/.ssh/id_rsa.git
Then on the server, I added the key to
authorized_keys, prefixed with this:
command="perl -e 'exec qw(git-shell -c), $ENV SSH_ORIGINAL_COMMAND '"
(I also tried the simpler
command="git-shell -c $SSH_ORIGINAL_COMMAND"; but
it didn't work with alioth's old version of openssh, and I didn't want
to worry about exposing SSH
ORIGINALCOMMAND to the shell.)
Before arriving at that, I took a detour to
using gitosis.
It can make it impressively easy to manage locked down git over ssh, but
you have to fit how it does things. Including repository layout, and a
dedicated account. So I spent several hours changing my git repo layout. In
the end, I decided gitosis was too complicated and limiting for what I
needed, but I do recommend checking it out.
svn
Like git, this is fairly easy, since svn provides
svnserve. The
svnbook
documents how to use it in .authroized_keys. Basically, just use
command="svnserve -t"
A similar approach as used for git can be used here if you want to have a
dedicated ssh key that causes svnserve to be run.
d-i daily builds
d-i has a
d-i-unpack-helper that can be put in authorized_keys.
unison
Can probably be locked down similarly to rsync, but I haven't tried yet.
duplicity
The only way seems to not use duplicity over ssh at all, and instead use
a different transport.
too hard
What if you want to allow locked down git, and a rsync, and maybe unison
too, all to the same account? You'll end up with some nasty mismash of all
of the above, and there are plenty more things using ssh as a transport
that need other techniques to lock them down.
Until this becomes easier, a majority will just dump passwordless ssh keys
in
~/.ssh/authorized_keys, creating exploitable trust paths that don't
need to exist.
I decided to purchase a three-year on-site warranty extension
with next-business-day response time for one of the Lenovo systems
I administer. I get this kind of extension for most systems that
aren t critical, but whose downtime would be inconvenient.
My understanding of the contract has always been that, assuming
the problem requires on-site service, a technician gets in touch
with you by the end of the next business day to agree on a time for
the on-site visit. The contract does not guarantee that there will
be a technician on-site on the next business day, but for
two or three hundred Euros, that would be too much to ask.
However, it turns out that I assumed too much. First of all,
Lenovo sells you a next-business-day response time
objective , meaning that they aim to respond by the end of
the next business day, but (obviously) can t be held liable if they
fail to do so. Apparently, they don t even have to provide a reason
for missing the objective.
What s even more curious, however, is their interpretation of
response : the term stems from the time when operators would log
calls and technicians then processed the queue. Nowadays, Lenovo
prides itself with skilled technicians resolving more than 30% of
all problems already on the phone , so the technicians log the
calls and then immediately respond to them.
According to Lenovo, it is thus completely acceptable and within
the bounds of the contract if the phone technician logs a call on
Thursday (and thus responds to it righ away), an the on-site
technician calls to arrange for a visit on the following Tuesday,
and the first available slot would be Friday 6 business days
after the call was logged.
I could not find any relevant information about this on their
website, nor can you retrieve the agreement which you had to accept
as part of the warranty registration later.
Of course, I am not surprised by any of this. The world out
there seems to be full of 
Adeodato Sim 
Okay I did thing I considered already for several months - I decided to quit
my current job at 
Yesterday I got a note from the 
![[Photo of Cyclists]](http://mjr.towers.org.uk/writing/reflections/attachments/polbikes.jpg "Bobbies on Bicycles")
I finally sent out a flood of mails to those people that applied for
Travel Sponsorship for this years Debian Conference in Argentina.
We have 58 people who got a position in our sponsorship queue, asking
for nearly 60.000 USD in total. We are not yet sure if we are able to
reimburse all of them, but we will at least try to.
We also have 24 people rejected from this queue and possibly some people
haven’t been able to fill out their settings in our conference
management system correctly/in time. While we are sorry for them, we
can’t do much here.
As well as 
Here's a selection of pictures from a recent visit to the Efteling.
