This document covers the configuration process for


  • gitsrht-periodic: The recommended configuration is */20 * * * * gitsrht-periodic.


Note: If was installed in a package, you may skip this section.

As a repository hosting service, requires a place for storing repositories (we recommend /var/lib/git/). It also requires a git user who has ownership over the repository storage location.


To allow users to upload artifacts to git repositories, an S3-compatible object storage system may be set up and configured (separately from the repository storage) before filling out the S3-related configuration options in your config.ini.

Warning: You must secure the S3 storage to protect from unauthorized downloads of artifacts within private repositories. will stream artifact downloads directly from the S3 storage after confirming authorization, so you simply need to avoid configuring the bucket for public access.
Note: For object storage, we recommend MinIO, a free and open-source S3-compatible storage server.

SSH Dispatch

It is necessary to configure's SSH dispatcher as the system-wide SSH authorization hook. In /etc/ssh/sshd_config, configure gitsrht-dispatch like so:

AuthorizedKeysCommand=/usr/bin/gitsrht-dispatch "%u" "%h" "%t" "%k"
PermitUserEnvironment SRHT_*

sshd will invoke our dispatcher whenever a connection is made to the server to obtain a list of authorized keys for the connecting user. The default behavior is to read the .ssh/authorized_keys file from that user's HOME directory, but the dispatcher can also "dispatch" to other authentication tools for other users. This is used to authorize and perform git operations via the gitsrht-keys and gitsrht-shell. See the [dispatch] section of your configuration for details on how this works and how to configure it for additional services (e.g.

Authorization logs are written to /var/log/gitsrht-dispatch and gitsrht-shell.

If you have any issues with dispatch, please make sure the git user is not locked by setting a password for it, and also make sure you can otherwise SSH into it.

HTTP(S) Cloning does not handle HTTP(S) cloning for you, so you'll need to set it up yourself with your web server. Here's an example Nginx configuration:

location = /authorize {
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;

location ~ ^/([^/]+)/([^/]+)/(HEAD|info/refs|objects/info/.*|git-upload-pack).*$ {
    auth_request /authorize;
    root /var/lib/git;
    fastcgi_pass unix:/run/fcgiwrap.sock;
    fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend;
    fastcgi_param PATH_INFO $uri;
    fastcgi_param GIT_PROJECT_ROOT $document_root;
    fastcgi_param GIT_HTTP_EXPORT_ALL "";
    include fastcgi_params;
    gzip off;
Note: On some systems (e.g. Alpine Linux), `SCRIPT_FILENAME` should be set to `/usr/libexec/git-core/git-http-backend`.

It is important that you set up the /authorize endpoint to enforce the privacy of private repositories.

If you don't have /run/fcgiwrap.sock on your system, you'll need to install the fcgiwrap package.

Note: On some systems, the socket might be called `/run/fcgiwrap.socket`, `/run/fcgiwrap/fcgiwrap.sock`, or something else entirely. Consult your distribution's documentation.

About this wiki

commit a290ce243e74f89fc35cd4e3467a580edbc35399
Author: Drew DeVault <>
Date:   2024-05-27T14:24:11+02:00 add link to joinup chooser
Clone this wiki (read-only) (read/write)