How do programs like guitarolite work?

Question

I'm curious how programs like gitolit work, specifically how they interact with the SSH protocol to provide an individual experience. Can someone provide an example of how I could accomplish something like the following and where I could learn more about this topic?

→ ssh [e-mail] PTY allocation request failed on channel 0 Hi <username>! You've successfully authenticated, but GitHub does not provide shell access. Connection to github.com closed. 

Question: My main language is JavaScript. Is it possible to accomplish what I want with NodeJS?

Answer 1

Gitolit itself is an authorization that ssh does not need.
He only needs to know who is calling him to allow or not allow this person git commands.

SSH is used for authentication (but you can also use Http Apache for authentication)

The way gitolite is called by ssh is explained in " Gitolite and ssh " and uses the ssh mechanism to force the command :

~/.ssh/authorized_keys (on gitolite ssh server) looks like this:

 command="[path]/gitolite-shell sitaram",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA18S2t... command="[path]/gitolite-shell usertwo",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArXtCT... 

First, it turns out which of the public keys in this file corresponds to the incoming input. Once a match is found, it will execute the command indicated on this line ; for example, if I log in, it will work [path]/gitolite-shell sitaram .
So, the first thing to note is that such users do not get "shell access", which is good!

( forced command = no interactive shell session : it will provide only a limited shell that runs only one script, always the same)

However, before running the sshd command, it sets an environment variable called SSH_ORIGINAL_COMMAND that contains the actual git command that your workstation sent.
This is the command that would be run if you did not have the command= part in the authorized key file.

When the gitolite-shell gains control, it looks at the first argument (" sitaram ", " usertwo ", etc.) to determine who you are. He then looks at the SSH_ORIGINAL_COMMAND variable to find out which repository you want to receive and whether you are reading or writing.

Now that the user has the user, repository and access to requests (read / write) , gitolite looks at its configuration file and allows or denies the request.

The fact that authorized_keys calls a perl script ( gitolite-shell ) is because Gitolite is written in Perl. <br> This can very well trigger a javascript program.

---

If your ssh on GitHub without any command, you get a welcome message, for example, your mention in your question.
Gitolite displays a similar message, as described in the print_version() function of the info script command :

 sub print_version { chomp( my $hn = `hostname -s 2>/dev/null || hostname` ); my $gv = substr( `git --version`, 12 ); $ENV{GL_USER} or _die "GL_USER not set"; print "hello $ENV{GL_USER}, this is " . ($ENV{USER} || "httpd") . "\@$hn running gitolite3 " . version() . " on git $gv\n"; } 

The message looks like this:

 hello admin, this is git@server running gitolite3 v3.0-12-ge0ed141 on git 1.7.3.4 

---

at the end of 2013, the Gitolit documentation now includes this diagram, in which all fragments are summarized:

Answer 2

Note that sshd performs a linear scan of the ~ / .ssh / authorized_keys file. When you get about 3,000 keys, people whose keys appear later in the file begin to notice a lag - it starts more than a network lag :-)

This is one of the reasons why github has its own patched version of sshd. They have too many users to be able to manage regular sshd!

Answer 3

The main steps:

• Check the public key of a user trying to log in
• Match the public key with an access control list

In other words, in order for these things to work, you must obtain public keys from users and then generate a list (file, database, etc.) that associates the key with the user and permissions.