Modified OpenSSH for VCS services
Pull request Compare This branch is 7 commits behind epriestley:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Patches to OpenSSH to allow it to authorize access to version control systems
(like SVN and Git) in a flexible way. This allows you to run a daemon which
gives users access to application resources without real system accounts,
similar to how GitHub allows access to Git repositories over SSH without
creating real system accounts for each user (instead, users upload public SSH

If you're just using Git and don't have all that many user accounts, Gitosis
is probably a much better solution to this problem (you could also try Gitolite
or Gitorious). sshd-vcs is a much more raw solution; while it is more powerful,
it is far more difficult to set up.

In more detail, the problem this solves is:

  - "Application" is whatever you're building, like GitHub. "Application
    Users" are people who use your application, like GitHub users.
  - "System" is the underlying Lunix system. "System Users" are real user
    accounts that have UIDs.
  - You have an arbitrary number of application users (like GitHub users)
    who need to access some application resource (like Git repositories).
    You don't want to create system accounts for each user. sshd-vcs allows
    all the application users to act as a single system user, while using
    application credentials (instead of system credentials) to authenticate
  - You either want a more flexible configuration than Gitosis provides,
    or want to support something other than git. Gitosis is a much simpler
    solution to this problem if it is suitable for your needs (it should
    be suitable in nearly all cases).

Specifically, there are two new config parameters available:

  - AuthorizedKeysScript: Public keys can now be loaded from an external
    source instead of ~/.ssh/authorized_keys.
  - ForceUser: Ignore the login user and always use a specific account.

Basically this allows you to set up sshd something like this:

  - Write a script which accepts an SSH public key on stdin, and produces
    either a nonzero exit code to deny login, or a zero exit code with
    an optional option string on stdout to accept login. Suppose this script
    is called "".
  - Write a script which accepts a user as argv[1], a command from
    environmental variable SSH_ORIGINAL_COMMAND, and uses stdin/stdout to
    communicate with the remote client. Suppose this script is called
    "". You can adapt something like Gitosis to accomplish this, if
    your backing service is git but you're choosing sshd-vcs for additional
  - Have "" emit something like 'command=" <user>",
    no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty' when it
    finds a valid public key.
  - Set AuthorizedKeysScript to "".
  - Create a real system user account like "git" which all users will act as
    when logged into the system.
  - Set ForceUser to "git".
  - Have application users put their public SSH keys into a database.
  - Now, when users login, sshd invokes "" and sends it the public key
    on stdin. "" checks the database and either sees that the key is
    not present (in which case it exits nonzero), or sees that the key is
    valid and identifies a system user, in which case it emits
    'command=" <appuser>",...' to stdout and exits 0. sshd now invokes
    the command, and puts the user's original command in the environmental
    variable SSH_ORIGINAL_COMMAND. "" runs with the valid user
    in argv[1]. It can now execute Gitosis, or wrap raw git commands, or
    whatever else.

You should run sshd-vcs on port 22 and run a real copy of sshd on some other
port if you need shell access to the box. It is strongly recommended you do not
try to run a copy of sshd-vcs as your real sshd. Instead, run sshd-vcs with
every possible access setting locked down and real sshd elsewhere.

For some very basic examples, see example/.

sshd-vcs is based extensively on prior work: