git.roojs.org Git - web.mtrack/blob - help/SSH

   1 '''AT THIS TIME I SUGGEST THAT YOU ONLY ENABLE THIS FOR SITES USING CONTROLLED HTTP AUTHENTICATION, NOT OPENID'''
   2
   3  = Notes on setting up SSH with mtrack. =
   4
   5 $MTRACK is the path to your mtrack installation.
   6
   7 Create a user account using your system adduser or useradd tool.
   8 If you're on OSX, you have to perform the creation manually (see below).
   9
  10 The username you pick will be included in the repo URLs that your
  11 contributors will use, so pick something appropriate.
  12
  13 Make sure that the primary group of the user matches that of your webserver,
  14 so that both the mtrack web application and the server side SCM tools can
  15 both access the repositories.
  16
  17 I've picked ''code'' as the username, and have set the home directory
  18 to be in my mtrack instance vardir, $MTRACK/var/codehome.
  19
  20  == OSX ==
  21
  22 On OSX:  manually reate a user.  Make sure that PrimaryGroupID matches your
  23 webserver.
  24
  25 {{{
  26 sudo -s
  27 dscl . -create /Users/code
  28 dscl . -create /Users/code UserShell $MTRACK/bin/codeshell
  29 dscl . -create /Users/code RealName "SSH wrapper for mtrack"
  30 dscl . -create /Users/code UniqueID 600
  31 dscl . -create /Users/code PrimaryGroupID 20
  32 dscl . -create /Users/code NFSHomeDirectory $MTRACK/var/codehome
  33 dscl . -create /Users/code Password '*'
  34 }}}
  35
  36  == Other Unix ==
  37
  38 Make sure that you set the password to '*' so that regular password based
  39 logins are not allowed for this user.  Also make sure that you set the shell to
  40 $MTRACK/bin/codeshell so that the possible set of commands is restricted to
  41 just the configured SCM tools (hg, git, svn).
  42
  43  == Next step ==
  44
  45 Depending on your system, you may need to create the home directory.
  46 You will also need to create the .ssh directory.
  47
  48 {{{
  49 mkdir -p $MTRACK/var/codehome/.ssh
  50 chown code:staff $MTRACK/var/codehome
  51 }}}
  52
  53  == Mercurial Trust ==
  54
  55 The commit hooks won't operate for repos created by the web server when pushed
  56 to over SSH, unless you tell Mercurial to trust the web server user.
  57
  58 You can do this by creating an .hgrc in the home directory of your "code" user.
  59 Here, "_www" is the username of my web server (OS/X).
  60
  61 These are the contents of {{{$MTRACK/var/codehome/.hgrc}}}:
  62
  63 {{{
  64 [trusted]
  65 users = _www
  66 }}}
  67
  68  == Config File ==
  69
  70 There are two setting that need to be placed in your config.ini file.  Both are
  71 required.  The first is the serverurl, which is the user@host which your users
  72 will use to access your server.  This should be the public name or IP of the
  73 system.  The second is the location of the authorized_keys2 file for your
  74 "code" user.  This must be the full path to the file.
  75
  76 {{{
  77 [repos]
  78 serverurl = "code@example.com"
  79 authorized_keys2 = "/Users/wez/Sites/mtrack/var/codehome/.ssh/authorized_keys2"
  80 }}}
  81
  82 The mtrack repo browser will use the serverurl to display the command that will
  83 be used to check out the code.  For example, the following commands are used to
  84 access the "wez/merc", "wez/git" and "wez/svn" repos, which were created in the
  85 code browser as mercurial, git and subversion repositories, respectively.
  86
  87 {{{
  88 $ hg clone ssh://code@example.com/wez/merc
  89 $ git clone code@example.com:wez/git
  90 $ svn checkout svn+ssh://code@example.com/wez/svn/BRANCHNAME
  91 }}}
  92
  93  == SSH Keys ==
  94
  95 Each user can supply their own SSH keys by clicking on their username and
  96 then the "Edit my details" button.
  97
  98 With SSH key(s) in the system, the next step is to configure the "code" user to see them.
  99
 100 In your crontab, set up a job to run as the "code" user.  This can run as frequently as you like--the longer the interval between runs, the longer it will take for modified SSH keys to take effect.
 101
 102 {{{
 103 0,15,30,45 * * * * su code -c "php $MTRACK/bin/make-authorized-keys.php" >/dev/null 2>/dev/null
 104 }}}
 105
 106 This script will pull out the key information from the user data in the mtrack
 107 database and generate an authorized_keys2 file that routes access via the
 108 "codeshell" script.
 109
 110 The effect of this is that your users will now be able to access your system
 111 over SSH and will be able to run hg, git or svn in a mode that only allows them
 112 to operate on repositories contained in var/repos.
 113
 114  == On Security ==
 115
 116 How secure is this?  At the time of writing, this configuration has the
 117 following implications:
 118
 119  * It creates a new user that accepts public-key authentication only over ssh
 120  * Any authenticated mtrack user can add their ssh keys to the allowed set
 121  * Any repos created by mtrack are thus accessible (read/write) to any authenticated mtrack user
 122
 123 '''IMPORTANT''': if you have enabled OpenID login, this means that ANY entity
 124 with an OpenID can add ssh keys and gain read/write access to all of the repos
 125 created by mtrack, but not gain full shell access.
 126
 127