1. 27
  1. 10

    Hey all, this is a project I’ve been working on and finally decided it was ready enough to show it to the public. The idea was just to build an SSH server for hosting repos which can be configured using git to show that something can be built that’s pretty solid and doesn’t depend on openssh. I’ve got a few more tweaks to make (namely following something similar to what gitolite does where a repo can only be used if it’s defined in the config).

    It’s based on my past work on the gliderlabs/ssh library, the Gitea SSH server, and some experiments with git2go.

    1. 2

      This is exactly what I’m looking for, thanks! If you need a help, please create issues with the need help label, I’ll help!

      1. 2

        I added a few issues if you’re interested in helping out. Right now my main goal is to add more tests, but there’s some functionality around user config files and org config files that’s currently missing.

    2. 3

      Off topic - I see you have some involvement with base16:


      I use that via Hugo => Hyde with 2 of my sites:


      so thanks!

      1. 3

        Nice! Yeah, I’ve been involved in base16 for a while. I actually maintain the base16-emacs themes and base16-builder-go because I like the idea of that project quite a bit.

        I also do a little bit of work with prezto, but as I don’t use that much any more, I haven’t been putting in as much time there.

        It’s always nice to hear about people using stuff I work on in the wild, even indirectly :)

      2. 2

        This sounds perfect for me, I’ve always felt like my Gitea installation was overkill. I love the automatic repo creation. I’m having a bit of trouble getting it to run though:

        GITDIR_BASE_DIR=/tmp/git ./go-git-dir

        This gives an error ‘Users directory does not exist’ before exiting.

        1. 2

          I added back implicit repo creation under an option (implicit_repos under options in config.yml). There’s been a pretty big rewrite and the code has been cleaned up substantially as well.

          Hope this works for you! Let me know if you have any serious issues.

          1. 1

            Thank you so much, I’ve been too busy to try just yet, but I’m definitely going to replace my Gitea installation with this. I’ll be sure to let you know if there are any troubles!

            1. 2

              No worries! It’s gone through a few big rewrites and cleanups in the last week or so… but it’s getting closer to the point where I’d call it stable.

              Just pushed about 1k lines of tests which validate a TON of things related to permissions… and I’ve got one more idea for cleaning up the code.

              Thanks for following up! Definitely let me know if you have any issues.

          2. 2

            I actually moved to a slightly more explicit definition of repos in config.yml, but it’s still super lightweight (this lets the server be a little bit more picky with path definitions since I really don’t want someone cloning something to be able to escape the git dir). Maybe automatic creation could be an option to enable?

            There’s a bit of a chicken vs the egg on initial setup - I’d be open to suggestions on how to fix that (maybe a simple command to do it). Easiest way to fix that is manually cloning /tmp/git/admin/admin and making a user in users/whoever.yml, adding that user to the admins group in config.yml and then pushing. After it’s running, you should be able to clone ssh://git@localhost:2222/admin and push to that.

            1. 1

              Thanks, I understand now. I had it in my head that I was supposed to create a ‘users’ directory directly under the base dir (I didn’t realise it was for config). But reading it again it all makes sense now. I love the project, keep it up. The automatic repo creation as an option would be nice, although I’m happy either way as it isn’t too difficult to add repos to the config either.

          3. 1

            Does it only differ from regular ssh git repos in that the server doesn’t need openssh installed?

            1. 8

              The setup for most traditional setups is pretty complicated because it involves sharing an openssh instance, creating a git user to allow the user to log in, as well as a method of automatically generating (or hooking into) the authorized_keys file. The actual permission checking is traditionally done with a separate shell program. This is a lot of small pieces and if any one of them does something wrong, it’s easy for a user to get access to your server. There was a bug with bash a few years back where if a user could ssh in to your server, they could get a shell - stuff like this makes piggy backing off openssh really scarry. I think it makes more sense to keep users separate from local unix accounts.

              Also, because the ssh server and git server are coupled together, you can start doing interesting things - allow users to log in with their actual username, build custom commands to list repos the user has access to, maybe even enable 2fa.