Re: [Savannah-hackers-public] [sr #107077] Setting up bzr+ssh on Savannah.

[Karl Fogel]

>> 1) Reopen SR #107077 (it's currently marked "closed", yet has much
>>    recent discussion and planning).

Done now.
 
>> 2) With bzr developer Robert Collins, write up a plan for exactly how
>>    to provide Bazaar bzr+ssh:// access securely on Savannah.  This
>>    will involve taking various steps mentioned in SR #107077.  Start
>>    at https://savannah.gnu.org/support/?107077#comment20 and read
>>    upwards if you're curious.

Okay, below is an implementation plan.  Robert Collins has helped with
advice on this; I'm CC'ing him here in case I mess anything up.

I'm assuming we already have an id_rsa.pub or id_dsa.pub from every
potential committer, or that we can easily get committers' public keys
by having them submit it through the Savannah web interface.

On bzr.sv.gnu.org:

  1. Create a new group 'bzrusers'.
  
  2. Do 'chgrp -R bzrusers /srv/bzr && chmod -R g+w /srv/bzr'
  
     (/srv/bzr is the top of our Bazaar "shared repository", right?)
  
  3. For each committer Jennifer Random, create a Unix account 'jrandom'
     and put her in the group 'bzrusers'.  Her shell should be /bin/sh
     (not /bin/false), but the account should have no login password --
     i.e., use "*" in the encrypted password field in /etc/shadow or
     whatever.  All authentication will be done via SSH, and we will
     allow only a restricted command set there (see below).
  
  4. In ~jrandom/.ssh/authorized_keys, put this line:
  
     command="/usr/bin/bzr serve --inet --allow-writes --directory=/src/bzr" 
ssh-rsa <<<LONG BASE64 PUBLIC KEY>>> address@hidden
  
     NOTE: everything from "ssh-rsa ..." on is either from id_rsa.pub as
     supplied by jrandom, or is a dedicated-use public key supplied by
     jrandom.  In the latter case, jrandom would have something like
     this in .ssh/config on the client side:
  
     Host bzr.sv.gnu.org
        IdentityFile ~/.ssh/savannah_id_rsa
  
  5. (paranoia) Do 'chmod 600 ~jrandom/.ssh ~jrandom/.ssh/authorized_keys'
  
  6. (paranoia) Make sure that /usr/lib/python2.*/bzrlib/plugins/ is not
     writeable by jrandom -- though it shouldn't matter, since SSH
     access is restricted to bzr only and bzr is restricted to the
     /bzr/srv directory (via the "--directory" option).
  
  7. (paranoia) Make sure ~jrandom/.bazaar/plugins does not exist or is
     not writeable by jrandom.  
  
     NOTE: We may someday put real plugins in there, or make it a
     symlink to a shared plugin directory controlled by the sysadmins.
     But in any case jrandom should not be able to configure it.
  
On the client side:

  Commands like these should now work, assuming /bzr/srv/projectname
  exists and has a 'trunk' branch (e.g., projectname is "emacs"):

  $ bzr branch bzr+ssh://address@hidden/projectname/trunk
  $ cd trunk
  $ echo "Hello, world!" > foo
  $ bzr add foo
  $ bzr commit -m "Add file 'foo'."
  $ bzr push --remember bzr+ssh://address@hidden/projectname/trunk
  Pushed up to revision <<<N>>>.
  $ 

  NOTES:

  If the remote branches were not created with the --no-trees option, or
  'bzr remove-tree' has not been run on them, then the client will get a
  warning like this:

    This transport does not update the working tree of:
    bzr+ssh://address@hidden/projectname/trunk/. See 'bzr help
    working-trees' for more information.

  I assume we configure all our branches on the server to not have
  working trees, so this won't be an issue.

  Also, note that even if jrandom has Unix password-based access on the
  remote server, it will not work with this Bazaar configuration...

  address@hidden's password: *********
  bzr: ERROR: Not a branch: "bzr+ssh://address@hidden/testproj/".

  ...because the key Bazaar line is in ~jrandom/.ssh/authorized_keys, so
  authentication must happen via SSH private/public key.

That's the plan.  It may need to be tweaked, depending on the situation
on bzr.sv.gnu.org, but I think the rough outline is about right.
Comments welcome.  Both Robert and I will be at the GNU hacker meetup in
Boston; we're happy to help make this happen then, if not sooner.

-Karl