I am curious as to how programs such as gitolite work -- specifically how do they interact with the SSH protocol to provide a tailored experience. Can somebody provide an example of how I might accomplish something like the following and where I might learn more about this topic?
→ ssh [email protected]
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.
A side question: my primary language is JavaScript. Is it possible to accomplish what I want with NodeJS?
gitolite in itself is an authorization layer which doesn't need ssh.
It only needs to know who is calling it, in order to authorize or not that person to do git commands.
SSH is used for authentication (but you can use an Http Apache for authentication as well, for instance)
The way gitolite is called by ssh is explained in "Gitolite and ssh", and uses the ssh mechanism forced command:
The ~/.ssh/authorized_keys
(on the gitolite ssh server) looks like:
command="[path]/gitolite-shell sitaram",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA18S2t...
command="[path]/gitolite-shell usertwo",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArXtCT...
First, it finds out which of the public keys in this file match the incoming login. Once the match has been found, it will run the command given on that line; e.g., if I logged in, it would run
[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 only provide a restricted shell, executing only one script, always the same)
Before running the command, however,
sshd
sets up an environment variable calledSSH_ORIGINAL_COMMAND
which contains the actualgit
command that your workstation sent out.
This is the command that would have run if you did not have thecommand=
part in the authorized keys file.When
gitolite-shell
gets control, it looks at the first argument ("sitaram
", "usertwo
", etc) to determine who you are. It then looks at theSSH_ORIGINAL_COMMAND
variable to find out which repository you want to access, and whether you're reading or writing.Now that it has a user, repository, and access requested (read/write), gitolite looks at its config file, and either allows or rejects the request.
The fact that the authorized_keys
calls a perl script (gitolite-shell
) is because Gitolite is written in perl.
It could very well call a javascript program.
If your ssh on GitHub without any command, you get a greeting message, like your mention in your question.
Gitolite displays a similar message, as detailed in the print_version()
function of the info
command script:
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:
hello admin, this is git@server running gitolite3 v3.0-12-ge0ed141 on git 1.7.3.4
The late 2013 Gitolite documentation now includes that diagram which summarizes all the pieces: