diff --git a/doc/0-INSTALL.mkd b/doc/0-INSTALL.mkd
index 22832a2..8c0f2f4 100644
--- a/doc/0-INSTALL.mkd
+++ b/doc/0-INSTALL.mkd
@@ -13,6 +13,7 @@ In this document:
       * <a href="#root_method_directly_on_the_server_manually_with_root_access">(root method) directly on the server, manually, with root access</a>
       * <a href="#non_root_method_directly_on_the_server_manually_without_root_access">(non-root method) directly on the server, manually, without root access</a>
       * <a href="#from_client_method_install_from_the_client_to_the_server">(from-client method) install from the client to the server</a>
+  * <a href="#URLs_for_gitolite_managed_repos">URLs for gitolite-managed repos</a>
   * <a href="#special_cases_multiple_gitolite_servers">special cases -- multiple gitolite servers</a>
       * <a href="#package_method_and_root_method">package method and root method</a>
       * <a href="#from_client_method">from-client method</a>
@@ -165,6 +166,21 @@ documentation.
 This method is verbosely documented in [doc/7-install-transcript.mkd][doc7],
 including *outputs* of the commands concerned.
 
+<a name="URLs_for_gitolite_managed_repos"></a>
+
+### URLs for gitolite-managed repos
+
+The URL for normal users (i.e., users other than the admin) is always of the
+form "git@server:reponame".  So, for instance, `git clone git@server:testing`
+gets any valid user a copy of the "testing" repo.
+
+In the first 3 install methods, the admin user will also use the same URL
+format, like `git clone git@server:gitolite-admin`.
+
+However, in the fourth ("from-client") method, the admin user needs a
+different URL (`gitolite:reponame`) to gain access to the gitolite
+repositories.  Check [here][twokeys] for why.
+
 <a name="special_cases_multiple_gitolite_servers"></a>
 
 ### special cases -- multiple gitolite servers
@@ -264,4 +280,4 @@ uninstalling gitolite is described in great detail in
 [doc7]: http://github.com/sitaramc/gitolite/blob/pu/doc/7-install-transcript.mkd
 [doc9unin]: http://github.com/sitaramc/gitolite/blob/pu/doc/9-uninstall.mkd
 [doc9ssh]: http://github.com/sitaramc/gitolite/blob/pu/doc/9-ssh-tips.mkd
-
+[twokeys]: http://github.com/sitaramc/gitolite/blob/pu/doc/6-ssh-troubleshooting.mkd#why_two_keys_on_client
diff --git a/doc/6-ssh-troubleshooting.mkd b/doc/6-ssh-troubleshooting.mkd
index 8fd4edd..39ba275 100644
--- a/doc/6-ssh-troubleshooting.mkd
+++ b/doc/6-ssh-troubleshooting.mkd
@@ -377,53 +377,13 @@ them; the ssh server will always (*always*) pick the first one in sequence
 when the key is offered by the ssh client.
 
 So the next question is usually "I have other ways to get a shell on that
-account, so why do I need a key for shell access at all?"
+account (like `su - git` from some other account), so why do I need a key for
+shell access at all?"
 
 The answer to this is that the "easy install" script, being written for the
-most general case, needs shell access via ssh to do its stuff.
-
-If you really, really, want to get rid of the extra key, here's a transcript
-that should have enough info to get you going (but it helps to know ssh well):
-
-  * on "sitaram" user, on my workstation
-
-        cd ~/.ssh
-        cp id_rsa sitaram
-        cp id_rsa.pub sitaram.pub
-        cd ~/gitolite-clone
-        src/gl-easy-install -q git my.git.server sitaram
-
-    that last command produces something like the following:
-
-        you are upgrading from     (unknown)     to v0.80-6-gdde8c4e
-        setting up keypair...
-            ...reusing /home/sitaram/.ssh/sitaram.pub...
-        creating gitolite para in ~/.ssh/config...
-        finding/creating gitolite rc...
-        installing/upgrading...
-        Pseudo-terminal will not be allocated because stdin is not a terminal.
-        [master (root-commit) e717a89] start
-         2 files changed, 11 insertions(+), 0 deletions(-)
-         create mode 100644 conf/gitolite.conf
-         create mode 100644 keydir/sitaram.pub
-        cloning gitolite-admin repo...
-        Initialized empty Git repository in /home/sitaram/gitolite-admin/.git/
-        fatal: 'gitolite-admin.git' does not appear to be a git repository
-        fatal: The remote end hung up unexpectedly
-
-    notice that the final step (the clone of the newly created gitolite-admin
-    repo) failed, as expected
-
-  * now log on to the git hosting account (`git@my.git.server` in this
-    example), edit `~/.ssh/authorized_keys`, and delete the line with the
-    first occurrence of your key (this should be *before* the `# gitolite
-    start` line)
-
-  * now go back to your workstation and
-
-        git clone git@my.git.server:gitolite-admin
-
-That should do it.
+most general case, needs shell access via ssh to do its stuff.  If you have
+access otherwise, you really should use one of the other 3 install methods to
+install gitolite.  Please see the [install doc][install] for details.
 
 <a name="some_other_tips_and_tricks"></a>
 
@@ -494,3 +454,4 @@ bigger problems than gitolite install not working!)]
 
 [doc0]: http://github.com/sitaramc/gitolite/blob/pu/doc/0-INSTALL.mkd
 [doc9gas]: http://github.com/sitaramc/gitolite/blob/pu/doc/9-gitolite-and-ssh.mkd
+[install]: http://github.com/sitaramc/gitolite/blob/pu/doc/0-INSTALL.mkd