Current state of the art in sharing repositories via SSH

[Matt Mackall]

On Wed, 2011-06-29 at 12:47 +0100, Tom Anderson wrote:
> On 28 June 2011 20:15, Matt Mackall <mpm at selenic.com> wrote:
> > On Tue, 2011-06-28 at 19:40 +0100, Tom Anderson wrote:
> >> It seems a shame that the ACL extension can't be used with a shared
> >> account.
> >
> > As it happens, Mercurial (and Python) will honor the LOGNAME environment
> > variable here today:
> >
> > $ LOGNAME=foo python -c 'import getpass; print getpass.getuser()'
> > foo
> 
> Aha! That makes life very considerably simpler, thanks.
> 
> I've actually just got a shared login working on a local machine with
> the ACL extension and a minimal amount of setup.
> 
> (1) Change /etc/ssh/sshd_config to add:
> 
> PermitUserEnvironment yes
> 
> Which enables environment option processing in the authorized_keys file.
> 
> (2) Added an entry to authorized_keys like:
> 
> environment="LOGNAME=Bob",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding
> ssh-rsa AAAAB3NzaC1yc2EAAAA...
> 
> And i can now do pushes operations as Bob!
> 
> This is not actually suitable for real use, though, as i can still do
> anything else via ssh. It needs to have a command= to lock that down,
> similar to the ones used by other methods. So, instead:
> 
> command="/home/hg/bin/hgsu.sh
> Bob",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding
> ssh-rsa AAAAB3NzaC1yc2EAAAA...
> 
> Then in ~hg/bin/hgsu.sh:
> 
> #! /bin/bash -eu
> export LOGNAME=$1
> set -- $SSH_ORIGINAL_COMMAND
> [[ $# -eq 5 ]]
> [[ "$1" == "hg" ]]
> [[ "$2" == "-R" ]]
> [[ -d "$3/.hg" ]]
> [[ "$4" == "serve" ]]
> [[ "$5" == "--stdio" ]]
> HG="$1"
> shift
> exec "$HG" "$@"
> 
> And there we have it. A shared SSH login which uses the ACL extension.
> 
> That script could be improved in a few ways. It could somehow check
> that the target repository has ACLs enabled, so that users can't touch
> unsecured repositories. Or it could check that the repository was on a
> master whitelist of exported repositories. If it rejects a connection,
> rather than simply bombing out, it could write to stderr (for the
> client) and syslog (for the admin) to say why.
> 
> Does anyone see any problems with this?
> 
> If i polished this up a bit, would it be worth adding to the wiki page
> for the AclExtension and SharedSSH?

Sounds good to me.

-- 
Mathematics is the supreme nostalgia of our time.