Other Git "server" via SSH

[kpedersen]

Hello all,

With Git, you basically have 3 choices for a server:

• Git protocol (similar to svnserve but with no authentication or encryption)
• HTTP(s)/CGI/smart/dumb/webdav
• SSH

Personally I am not entirely happy with any of them (Git protocol has no authentication, HTTP(s) needs central certificate authorities which is a bad idea, SSH seems overly powerful and exposing it to anything other than full user access is a bad idea). However I feel that the SSH approach is the least bad.

I have the following as my (simplified) custom Git user shell:

#!/bin/sh

set -e

unsafe="$2"

repo_dir="/git"
repos="$(ls "${repo_dir}")"

for repo in ${repos}; do
  str="git-upload-pack '${repo}'"

  if [ "${str}" = "${unsafe}" ]; then
    exec git-upload-pack "${repo_dir}/${repo}"
  fi

  str="git-receive-pack '${repo}'"

  if [ "${str}" = "${unsafe}" ]; then
    exec git-receive-pack "${repo_dir}/${repo}"
  fi
done

exit 1

It is possibly a little overly paranoid but also saves me from having to parse the potentially unsafe remote input or audit the git-shell which is too large for what it achieves.

I have the following in my sshd_config and this is where my question begins. Since a semi-recent update, we now have a new option DisableForwarding which I believe is a pseudonym for disabling X11Forwarding, AllowTcpForwarding, AllowStreamLocalForwarding (also new) and AllowAgentForwarding. However I notice that the example config for anoncvs doesn't make use of this. Basically I just want to make sure my existing configs are still secure with the latest versions of OpenSSH.

Match User git
        X11Forwarding no
        AllowTcpForwarding no
        AllowStreamLocalForwarding no

        AllowAgentForwarding no
        DisableForwarding yes
        PermitTTY no

If I removed the last 3 entries, what would be the worst a malicious attacker could do (also considering my custom git shell)?

Many thanks!

 

[astyle]

It sounds like DisableForwarding is a synonym for the 4 options above it... And based on that, I'd think that the line with DisableForwarding yes can be safely commented out.

I've seen cases where flag redundancy increases verbosity of debugging output, but when it comes to security, redundancy (esp. with synonyms) can make it harder to debug your setup. YMMV...

 

[kpedersen]

I've seen cases where flag redundancy increases verbosity of debugging output, but when it comes to security, redundancy (esp. with synonyms) can make it harder to debug your setup. YMMV...

Agreed. I find the Perl-style approach of "loads of ways to do the same thing" makes things a little messy for security.

I can't help but feel this seems like an intermediate config solution before an overhaul but I could be wrong.