[mirror-admin] push mirroring - who owns the SSH keys?

[Maurice Massar]

hi,

let me add something from the side of mirror-admins who receive
ssh-trigers (in my case: for debian* and ubuntu*).

On Sat, Jun 20, 2009 at 09:15:17AM -0700, J.H. wrote:
> 1) It adds an additional user to the mirror machines, this could be
> problematic from a policy perspective, [...]

There is no requirement to use an additional user. I just add the public
key to ~/.ssh/authorized_keys of the mirror-maintenance-user, prepended
with a force-command and a bunch of other options, and I'm done. From
the point of view of my script, there is no difference if it is called
via cron or ssh.

> and should the private keys become known it poses certain security risks
> for the remote mirrors. [...]

I'm aware of 2 risks:

1) someone gets hold of the private key
=> they can trigger useless runs of my mirror script

I don't care about this. By agreeing to get pushed by anything else but
cron, I've handed out some control already.


2) in addition to 1), there is an bug in ssh exploitable by an
   authenticated user even with all possible key-restriction in
   place.

That will be a problem.

I feel safe enough by just watching out for ssh security updates.
Decide yourself.

> 3) SSH provides no queuing mechanisms, and as we've run into similar
> issues with queuing and such (with respect to rsyncFilter) there might
> be better alternatives.  This is particularly bad if there's a transient
> error to the master servers, that does not affect the local geographic
> users.

True, the code sending the triggers will need to do queuing. If this is
centralized in MM, it should be possible to work out. On the receiving
side of things, queuing can be implemented by the mirror script. You're
probably aware of ftp://ftp.kernel.org/pub/site/sample_mirror_script.pl
already doing this, and I've based my own script on this (thanks btw!).

I've extended it a bit, to even handle stuff like "@ERROR: max
connections (40) reached" (by scheduling another run of the script
via "/usr/bin/at now + 30 minute"), mailing me a diff of the rsync motd
whenever something changes, sending a note if rsycing took to long,
or did an error-exit. OTOH, it is using a single queue for all things to
mirror (at most one rsync running), which was needed on the old machine
back then when I wrote that script. It does not support evaluating
${SSH_ORIGINAL_COMMAND} yet nor using different rsync options.. but
if anyones interested: http://ftp.uni-kl.de/pub/tmp/mirror-master


> I'm not saying that push mirroring is bad, it has some advantages
> over pull mirroring, but using SSH as your trigger mechanism has some
> hefty downsides.  When we (kernel.org) were looking into providing
> push mirroring we considered ssh, but ultimately went with e-mail as
> the trigger mechanism.  It queues both remotely and locally, can be gpg
> signed if your worried about authenticity, doesn't force an additional
> user to be created / exist and I would guess that setting up, even a
> machine specific e-mail address alias, has a lower barrier to entry than
> creating a user account.  Some thoughts to consider.

For me, receiving mail is a bit more involved. First, I need to setup
an MTA which actually listens to *:25 (instead of localhost:25 only),
and then I need to get a single email address routed to this box which
is deprecated according to site policy (granted, I've written this
policy *eg*). It is more simple if mail reception is already enabled on
the machine hosting the mirror. For ssh triggers it is adding a single
line to a file in the homedir of the mirror-user. IF inbound ssh is
allowed to the machine at all.


Anyway: MM could support both mechanisms, if someone writes the code (-;

cu
Maurice Massar

--