(password access) make the hostkey thing less of a problem...

...for the code, not for the admin ;-)

OK that sounds nasty but really it's not that bad.  We're replacing some
code with a one-time step for the admin which is also likely to be more
future-proof.

idea credit: Teemu

contrib/real-users/gl-shell-setup

@@ -75,11 +75,6 @@ then
     # passing the username whose key it is as argument 1.
     cat .ssh/id_rsa.pub | su -l -c "$0 $user" $hosting_user
 
-    # finally, as $user (alice) ssh to the hosting_user once so that the
-    # hostkey checking gets done and you get the correct hostkey in
-    # ~user/.ssh/known_hosts
-    su -c "ssh -o StrictHostKeyChecking=no $hosting_user@localhost info" - $user
-
     exit 0
 
 else

contrib/real-users/password-access.mkd

@@ -88,12 +88,6 @@ these pesky ssh keys.
     expand, setperms, etc.), but considering that an ADC could be called
     *anything*, a general solution is impossible.</font>
 
-  * If you server's host key changes, you may have to manually fix up all the
-    host keys in all the user's `~/.ssh/known_hosts` files.  Not too difficult
-    if you're sure they all have just the one host key, but if they have
-    multiple, you have to carefully delete and replace just the one line that
-    pertains to localhost.  Scripts to do this cleanly are welcome...
-
 <a name="_what_the_2_scripts_actually_do"></a>
 
 ### what the 2 scripts actually do
@@ -121,6 +115,9 @@ these pesky ssh keys.
 
 Here's how to set this up.  First, the **one-time** tasks:
 
+  * Do this first, or you'll forget :-)  Add the host key for 'localhost' to
+    `/etc/ssh/ssh_known_hosts`.  And if it ever changes, update it.
+
   * Install gitolite as normal, if not already installed.  This will require
     you to use ssh keys for your (admin's) own access, but I assume that's ok.