doc/6: no idea how but this ended up with CRLF line endings (ugh!)
This commit is contained in:
Sitaram Chamarty
parent
8eefc036e0
commit
98124596ed
|
|
@ -1,135 +1,135 @@
|
|||
# more complex ssh setups
|
||||
|
||||
What do you need to know in order to create more complex ssh setups (for
|
||||
instance if you have *two* gitolite servers you are administering)? Once more
|
||||
unto the breach, here's more ssh magic!
|
||||
|
||||
In this document:
|
||||
|
||||
* files on client
|
||||
* files on the server
|
||||
* sanity checks
|
||||
* two gitolite servers to manage?
|
||||
|
||||
### files on client
|
||||
|
||||
* default keypair; used to get shell access to servers. You would have
|
||||
copied this pubkey to the gitolite server in order to log in without a
|
||||
password. (On Linux systems you may have used `ssh-copy-id` to do that).
|
||||
You would have done this *before* you ran the easy install script, because
|
||||
otherwise easy install won't run!
|
||||
|
||||
~/.ssh/id_rsa
|
||||
~/.ssh/id_rsa.pub
|
||||
|
||||
* gitolite keypair; the "sitaram" in this is the 3rd argument to the
|
||||
`src/00-easy-install.sh` command you ran; the easy install script does the
|
||||
rest
|
||||
|
||||
~/.ssh/sitaram
|
||||
~/.ssh/sitaram.pub
|
||||
|
||||
### files on the server
|
||||
|
||||
* the authkeys file; this contains one line containing the pubkey of each
|
||||
user who is permitted to login without a password.
|
||||
|
||||
Pubkey lines that give shell access look like this:
|
||||
|
||||
ssh-rsa AAAAB3NzaC[snip]uPjrUiAUew== /home/sitaram/.ssh/id_rsa
|
||||
|
||||
On a typical server there will be only one or two of these lines.
|
||||
|
||||
Note that the last bit (`/home/sitaram/.ssh/id_rsa`) is purely a *comment*
|
||||
field and can be anything. Also, the actual lines are much longer, about
|
||||
400 characters; I snipped 'em in the middle, as you can see.
|
||||
|
||||
In contrast, pubkey lines that give access to git repos hosted by gitolite
|
||||
looks like this:
|
||||
|
||||
command="[some path]src/gl-auth-command sitaram",[some restrictions] ssh-rsa AAAAB3NzaC[snip]s18OnB42oQ== sitaram@sita-lt
|
||||
|
||||
You will have many more of these lines -- one for every pubkey file in
|
||||
`keydir/` of your gitolite-admin repo, with the corresponding username in
|
||||
place of "sitaram" in the example above.
|
||||
|
||||
The "command=" at the beginning ensures that when someone with the
|
||||
corresponding private key logs in, they don't get a shell. Instead, the
|
||||
`gl-auth-command` program is run, and (in this example) is given the
|
||||
argument `sitaram`. This is how gitolite is invoked, (and is told the
|
||||
user logging in is "sitaram").
|
||||
|
||||
* config file; this file has an entry for gitolite access:
|
||||
|
||||
~/.ssh/config
|
||||
|
||||
Let's step back a bit. Normally, you might expect to access gitolite
|
||||
repos like this:
|
||||
|
||||
ssh://git@server/reponame.git
|
||||
|
||||
But this won't work, because this ends up using the *default* keypair
|
||||
(normally), which gives you a command line. Which means it won't invoke
|
||||
the `gl-auth-command` program at all, and so none of gitolite's access
|
||||
control will work.
|
||||
|
||||
You need to force ssh to use the *other* keypair when performing a git
|
||||
operation. With just ssh, that would be
|
||||
|
||||
ssh -i ~/.ssh/sitaram git@server
|
||||
|
||||
but git does not support putting an alternate keypair in the URL.
|
||||
|
||||
Luckily, ssh has a very convenient way of capturing all the mundane
|
||||
information (username, hostname, port number (if it's not the default 22),
|
||||
and keypair to be used) in one "paragraph". This is what the para looks
|
||||
like for us (the easy install script puts it there the first time):
|
||||
|
||||
host gitolite
|
||||
user git
|
||||
hostname server
|
||||
identityfile ~/.ssh/sitaram
|
||||
|
||||
(The "gitolite" can be anything you want of course; it's like an alias for
|
||||
all the stuff below it). This ensures that typing
|
||||
|
||||
ssh gitolite
|
||||
|
||||
is equivalent to
|
||||
|
||||
ssh -i ~/.ssh/sitaram git@server
|
||||
|
||||
and therefore this:
|
||||
|
||||
git clone gitolite:reponame.git
|
||||
|
||||
now works as expected, invoking the special keypair instead of the default
|
||||
one.
|
||||
|
||||
### sanity checks
|
||||
|
||||
* `ssh gitolite` should get you the `SSH_ORIGINAL_COMMAND` error. If you
|
||||
get a command line, something is wrong
|
||||
|
||||
* conversely, `ssh git@server` should get you a command line
|
||||
|
||||
* the "origin" URL in any clones should look like `gitolite:reponame.git`
|
||||
instead of something more complex
|
||||
|
||||
### two gitolite servers to manage?
|
||||
|
||||
* they can have the same key; no harm there (example, sitaram.pub)
|
||||
|
||||
* instead of just one ssh/config para, you now have two (assuming that the
|
||||
remote user on both machines is called "git"):
|
||||
|
||||
host gitolite
|
||||
user git
|
||||
hostname server
|
||||
identityfile ~/.ssh/sitaram
|
||||
|
||||
host gitolite2
|
||||
user git
|
||||
hostname server2
|
||||
identityfile ~/.ssh/sitaram
|
||||
|
||||
# more complex ssh setups
|
||||
|
||||
What do you need to know in order to create more complex ssh setups (for
|
||||
instance if you have *two* gitolite servers you are administering)? Once more
|
||||
unto the breach, here's more ssh magic!
|
||||
|
||||
In this document:
|
||||
|
||||
* files on client
|
||||
* files on the server
|
||||
* sanity checks
|
||||
* two gitolite servers to manage?
|
||||
|
||||
### files on client
|
||||
|
||||
* default keypair; used to get shell access to servers. You would have
|
||||
copied this pubkey to the gitolite server in order to log in without a
|
||||
password. (On Linux systems you may have used `ssh-copy-id` to do that).
|
||||
You would have done this *before* you ran the easy install script, because
|
||||
otherwise easy install won't run!
|
||||
|
||||
~/.ssh/id_rsa
|
||||
~/.ssh/id_rsa.pub
|
||||
|
||||
* gitolite keypair; the "sitaram" in this is the 3rd argument to the
|
||||
`src/00-easy-install.sh` command you ran; the easy install script does the
|
||||
rest
|
||||
|
||||
~/.ssh/sitaram
|
||||
~/.ssh/sitaram.pub
|
||||
|
||||
### files on the server
|
||||
|
||||
* the authkeys file; this contains one line containing the pubkey of each
|
||||
user who is permitted to login without a password.
|
||||
|
||||
Pubkey lines that give shell access look like this:
|
||||
|
||||
ssh-rsa AAAAB3NzaC[snip]uPjrUiAUew== /home/sitaram/.ssh/id_rsa
|
||||
|
||||
On a typical server there will be only one or two of these lines.
|
||||
|
||||
Note that the last bit (`/home/sitaram/.ssh/id_rsa`) is purely a *comment*
|
||||
field and can be anything. Also, the actual lines are much longer, about
|
||||
400 characters; I snipped 'em in the middle, as you can see.
|
||||
|
||||
In contrast, pubkey lines that give access to git repos hosted by gitolite
|
||||
looks like this:
|
||||
|
||||
command="[some path]src/gl-auth-command sitaram",[some restrictions] ssh-rsa AAAAB3NzaC[snip]s18OnB42oQ== sitaram@sita-lt
|
||||
|
||||
You will have many more of these lines -- one for every pubkey file in
|
||||
`keydir/` of your gitolite-admin repo, with the corresponding username in
|
||||
place of "sitaram" in the example above.
|
||||
|
||||
The "command=" at the beginning ensures that when someone with the
|
||||
corresponding private key logs in, they don't get a shell. Instead, the
|
||||
`gl-auth-command` program is run, and (in this example) is given the
|
||||
argument `sitaram`. This is how gitolite is invoked, (and is told the
|
||||
user logging in is "sitaram").
|
||||
|
||||
* config file; this file has an entry for gitolite access:
|
||||
|
||||
~/.ssh/config
|
||||
|
||||
Let's step back a bit. Normally, you might expect to access gitolite
|
||||
repos like this:
|
||||
|
||||
ssh://git@server/reponame.git
|
||||
|
||||
But this won't work, because this ends up using the *default* keypair
|
||||
(normally), which gives you a command line. Which means it won't invoke
|
||||
the `gl-auth-command` program at all, and so none of gitolite's access
|
||||
control will work.
|
||||
|
||||
You need to force ssh to use the *other* keypair when performing a git
|
||||
operation. With just ssh, that would be
|
||||
|
||||
ssh -i ~/.ssh/sitaram git@server
|
||||
|
||||
but git does not support putting an alternate keypair in the URL.
|
||||
|
||||
Luckily, ssh has a very convenient way of capturing all the mundane
|
||||
information (username, hostname, port number (if it's not the default 22),
|
||||
and keypair to be used) in one "paragraph". This is what the para looks
|
||||
like for us (the easy install script puts it there the first time):
|
||||
|
||||
host gitolite
|
||||
user git
|
||||
hostname server
|
||||
identityfile ~/.ssh/sitaram
|
||||
|
||||
(The "gitolite" can be anything you want of course; it's like an alias for
|
||||
all the stuff below it). This ensures that typing
|
||||
|
||||
ssh gitolite
|
||||
|
||||
is equivalent to
|
||||
|
||||
ssh -i ~/.ssh/sitaram git@server
|
||||
|
||||
and therefore this:
|
||||
|
||||
git clone gitolite:reponame.git
|
||||
|
||||
now works as expected, invoking the special keypair instead of the default
|
||||
one.
|
||||
|
||||
### sanity checks
|
||||
|
||||
* `ssh gitolite` should get you the `SSH_ORIGINAL_COMMAND` error. If you
|
||||
get a command line, something is wrong
|
||||
|
||||
* conversely, `ssh git@server` should get you a command line
|
||||
|
||||
* the "origin" URL in any clones should look like `gitolite:reponame.git`
|
||||
instead of something more complex
|
||||
|
||||
### two gitolite servers to manage?
|
||||
|
||||
* they can have the same key; no harm there (example, sitaram.pub)
|
||||
|
||||
* instead of just one ssh/config para, you now have two (assuming that the
|
||||
remote user on both machines is called "git"):
|
||||
|
||||
host gitolite
|
||||
user git
|
||||
hostname server
|
||||
identityfile ~/.ssh/sitaram
|
||||
|
||||
host gitolite2
|
||||
user git
|
||||
hostname server2
|
||||
identityfile ~/.ssh/sitaram
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue