deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

easy install: dont allow root, plus warn about shell access using the given key

Browse source 
- refuse to install to root
  - when a pubkey is being used that was not freshly created by
    ourselves, warn the user that this key can not be used to get shell
    access to the server.  Prevents some corner cases of people being
    locked out...

Also, change the final message to be even more clear that this is all on
the workstation, not the server
This commit is contained in:
Sitaram Chamarty 2009-11-26 12:13:42 +05:30
parent 9a85f5d0d6
commit a02a48e8f5
2 changed files with 18 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/6-ssh-troubleshooting.mkd
View file

@ -91,7 +91,7 @@ Here's how it all hangs together.
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:
look like this:
command="[some path]src/gl-auth-command sitaram",[some restrictions] ssh-rsa AAAAB3NzaC[snip]s18OnB42oQ== sitaram@sita-lt
@ -146,7 +146,7 @@ Here's how it all hangs together.
but git does not support putting an alternate keypair in the URL.
Luckily, ssh has a very convenient way of capturing all the mundane
Luckily, ssh has a very convenient way of capturing all the connection
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):

25
src/gl-easy-install
View file

@ -162,6 +162,7 @@ basic_sanity() {
echo $user | perl -lne 'exit 1 if /[^a-zA-Z0-9._-]/' ||
die "user '$user' invalid"
[[ "$user" == "root" ]] && die I refuse to install to root
echo $admin_name | perl -lne 'exit 1 if /[^a-zA-Z0-9._-]/' ||
die "admin_name '$admin_name' invalid"
@ -220,7 +221,7 @@ setup_local_ssh() {
if [[ -f "$HOME/.ssh/$admin_name.pub" ]]
then
prompt " ...reusing $HOME/.ssh/$admin_name.pub..." "$v_reuse_pubkey"
prompt "" "$v_reuse_pubkey"
else
ssh-keygen -t rsa -f "$HOME/.ssh/$admin_name" || die "ssh-keygen failed for some reason..."
fi
@ -467,8 +468,14 @@ This makes using passphrases very convenient.
"
v_reuse_pubkey="
Hmmm... pubkey \$HOME/.ssh/\$admin_name.pub exists; should I just re-use it?
Be sure you remember the passphrase, if you gave one when you created it!
Hmmm... pubkey \$HOME/.ssh/\$admin_name.pub exists; should I just (re-)use it?
IMPORTANT: once the install completes, *this* key can no longer be used to get
a command line on the server -- it will be used by gitolite, for git access
only. If that is a problem, please ABORT now.
doc/6-ssh-troubleshooting.mkd will explain what is happening here, if you need
more info.
"
v_ssh_add="
@ -554,16 +561,16 @@ it elsewhere later if you wish to.
"
tail="
All done!
NOTE: All the below stuff is on your *workstation*. You shoud not, normally,
have to do anything directly on your server to administer/use gitolite.
The admin repo is currently cloned at ~/gitolite-admin; you can clone it
anywhere you like. To administer gitolite, make changes to the config file
(config/gitolite.conf) and/or the pubkeys (in subdirectory 'keydir') in any
The admin repo is currently cloned at ~/gitolite-admin. You can reclone it
anywhere else if you wish. To administer gitolite, make changes to the config
file (conf/gitolite.conf) and/or the pubkeys (in subdirectory 'keydir') in any
clone, then git add, git commit, and git push.
ADDING REPOS: Edit the config file to give *some* user access to the repo.
When you push, an empty repo will be created on the server, which authorised
users can then clone from, or push to.
When you push, an empty repo will be created on the server.
ADDING USERS: copy their pubkey as keydir/<username>.pub, add it, commit and
push.