deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
gitolite/contrib/real-users/password-access.mkd

109 lines
4 KiB
Markdown
Raw Normal View History

MASSIVE set of changes to documents! I got tired of being told "TL;DR". Now the online versions of most documents fit on a page or two, or at least most of them do. The rest has been split out (and you can see the links to the split out sections right where the text is in the raw Markdown). This is much more pleasant to read, and I've improved the linking so it's much less effort for me to keep the links correct.
2011-11-01 06:03:20 +01:00
# F=password_access password access to gitolite
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
MASSIVE set of changes to documents! I got tired of being told "TL;DR". Now the online versions of most documents fit on a page or two, or at least most of them do. The rest has been split out (and you can see the links to the split out sections right where the text is in the raw Markdown). This is much more pleasant to read, and I've improved the linking so it's much less effort for me to keep the links correct.
2011-11-01 06:03:20 +01:00
(a.k.a: turning real users into gitolite users)
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
MASSIVE set of changes to documents! I got tired of being told "TL;DR". Now the online versions of most documents fit on a page or two, or at least most of them do. The rest has been split out (and you can see the links to the split out sections right where the text is in the raw Markdown). This is much more pleasant to read, and I've improved the linking so it's much less effort for me to keep the links correct.
2011-11-01 06:03:20 +01:00
## problems
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
This document solves several different problems. But first some names:
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
* `alice`: our user
* `server1`: a server on which alice has a shell account or the admin is
willing to give her one
* `git@server2`: the gitolite host (user@server). Server2 may be, but need
not be, the same as server1.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
The problems it solves are:
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
1. Alice doesn't like ssh keys and wants to stick to password access (which
won't work with gitolite!), and she has or can get a real (unix) userid on
server1.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
2. Alice is outside your corporate environment and needs to get in to server2
via server1.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
It does this by making `alice@server1` act like a "proxy" for `git@server2`.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
## what the 2 scripts actually do
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
* `gl-shell` will become the login shell for these users on server1. This
shell will forward git clone/fetch/push requests to "git" on server2.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
This redirection is so transparent that I had to explicitly code a message
("forwarding to git@server") to make troubleshooting easier.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
* `gl-shell-setup` sets things up. It needs to be run on server1, where it
changes the user's shell to `gl-shell` (full path), then sets up an RSA
key if needed.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
## instructions
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
### server setup
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
**Server1**:
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
* Add the host key for server2 to `/etc/ssh/ssh_known_hosts` on server1.
And if it ever changes, update it.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
ssh-keyscan -t rsa,dsa server2 >> /etc/ssh/ssh_known_hosts
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
* You will need to copy the 2 scripts supplied (in contrib/real-users) to
"/usr/local/bin" on server1 and customise them -- i.e., edit the files and
change stuff in the section clearly-marked "site-local changes".
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
**NOTE** on fixing the "chsh" function: this is OS-dependent. Use
whatever command the OS on server1 requires for this to work. The
supplied command is good for Fedora. (Server2's OS does not matter for
this customisation, even though the script is needed there also).
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
**Server2**: We assume gitolite is already installed on server2.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
### per-user setup
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
There are 2 types of users.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
1. Alice uses a password to access server1, or Alice uses a pubkey to access
server1 but does not use an agent or enable agent forwarding.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
* login as root on server 1.
* make sure a file called 'alice.pub' does NOT exist in the current
directory.
* run `gl-shell-setup alice`. This will create a file called
'alice.pub' (since it does not exist).
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
2. alice uses a pubkey to access server1, and does agent forwarding.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
* login as root on server 1.
* ask the user for the pubkey she uses or get it from the
`authorized_keys` file in her `$HOME/.ssh` on server1. Copy it as
'alice.pub' in the current directory.
* run `gl-shell-setup alice`. (It will not create the pub file, since
it already exists).
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
You can do this for several users in one shot, and collect all the the
pubkeys.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
Once you have collected all of them, send them to server2 or to someone who
has push rights to the admin repo.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
## some hints, notes and caveats
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
This doesn't mean all your users have to be like this. You can have normal
users also. In fact, you can have users who give you a pub key from their
workstation the normal way, as well as use this method. (I strongly suggest
that all such keys be placed in `keydir/indirect/` instead of in `keydir/`).
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
### security and trust discussion
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
For type 1 users, a default key *pair* (i.e., *including* a private key) must
be generated on server1 and given to the gitolite admin for inclusion as the
user's key for gitolite.
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
This means that the user must implicitly trust server1's administrators, since
they can impersonate her to server2. (If server1 and server2 are the same
machine or have the same administrators, this does not matter).
password access to gitolite using real users
2011-09-13 11:41:51 +02:00
(password access) backward compat breakage for gl-shell-setup; read below gl-shell-setup has a "run as hosting user" piece that basically automates the adding of the user's (new) key to the admin repo. This is now gone. (It's not that hard to automate yourself if you want to do it anyway, using gl-admin-push). I did this because I needed to allow someone in through a gateway, and realised that that has the exact same needs. So the whole scheme has been changed to treat the proxy and the gitolite host as being two different servers. At that point it became cumbersome to do the second bit, and I left it out. Other changes: - you can define exceptions for the default shell in gl-shell - the doc has been simplified.
2011-11-15 12:47:16 +01:00
For a type 2 user, no keys need to be generated, and this type of user need
not trust server1 at all. In fact, she's only using this method due to
firewall issues, and the only thing that gl-shell-setup is doing is to run
'chsh'.
Reference in a new issue Copy permalink